Should all projects follow a recognised methodology? Having recently become a Prince2 practitioner, I was convinced that yes, they should. And, as the saying goes, if all you have is a hammer then everything looks like a nail, in the blinkered view I had at the time I was sure that the project methodology of choice in Coastal Housing’s IT department should be Prince2… why not?
When we recently started to think about replacing our on-premise PBX/ISDN telephony system with a hosted/SIP solution, I was naturally eager to adopt Prince2 methodology for the project. I was going to put together an in-depth PID, determine roles, lay out a detailed timeline of dependencies, stages and boundaries, produce clear project product descriptions and so on, referring over and again to the weighty, sticky-note littered, ink-defaced manual I’d proudly managed (no pun intended) to bring back from the excellent course. Because it was excellent. I wanted to go into super verbose-mode, producing documents, spreadsheets, diagrams and yet more documents, all evidencing that Prince2 was the correct approach because, hey, look at all this evidence! I knew that Prince2 can be tailored, I knew that a PID can be one sheet of paper and so on, but what I didn’t know, and this was essential, was that I was putting the cart before the horse before we had even begun, or rather, the methodology before what mattered, and what mattered was to first ask: should all projects follow a recognised methodology?
When our head of IT, Shane Griffiths, suggested that we should use the services of Vanguard, our ‘systems thinking’ partner, to help us shape the project, I was thrown (which was not entirely surprising, given that I was putting the cart before the horse). But he was right to do so. I’m not for one moment suggesting Prince2 isn’t fit for purpose. What I am suggesting though, is the need to be clear on purpose and then find and do what fits. I know this now and it’s deeply changed my view of how to approach projects.
Rather than labour through an albeit reassuring methodology whether it suited our needs or not, we experimented with some simple activities and went from there. We ran a Mind Map workshop with users, guided by Vanguard; we distributed a survey with just one killer question (what does a perfect telephony system look like?); and asked representatives from all departments to write a ‘what matters’ statement. The purpose became crystal clear, all without IT doing much at all. Vanguard then guided us through an exercise in which we envisioned, individually, all the steps involved in the work and then compared notes. This led to an elegant timeline of important dates, constraints, actions, ownerships and an approximate buffer for absorbing any changes.
And that was it – everything we needed to make the project a success, and all it took was a couple of days. So much for my hammer. As Vanguard said at the time, “When you have clarity of ‘what matters’ and ‘purpose’, elegant and simple solutions present themselves. The difficulty is that these elegant and simple solutions often challenge the accepted approaches. As such, it’s vital to test the assumptions behind these accepted approaches.”
The materials gathered were then worked into what became the RfP which, because all of the preliminary work that had been done (and most of it by our end-users), was an absolute pleasure to produce. How often can you say that? Our intention evolved from being as informative as possible into being as open as possible, producing a document that put the burden, for want of a better word, on the supplier to demonstrate that their solution was right for us and was fit for our purpose. We constructed simple, open questions and compiled them into the themes that emerged from the Mind Map. For example, under the theme ‘The system tells me what I want to know’, we asked questions such as ‘How do users see and manage their telephony information?’ and ‘How are contact directories maintained?’. And under the theme ‘The system works wherever I am’, we asked ‘How is access from anywhere achieved?’ and ‘How does using the service differ across the varying methods of access?’. The structure just fell into place, effortlessly.
By leaving our position open, aside from stipulating that the system should be hosted, potential suppliers were tasked with being curious about our setup, to ask us more questions than we asked them, to tell us what matters about their platform to us, rather than us ask them. What better way to gauge a supplier’s hunger for a contract than to be vague, non-prescriptive and ambiguous? Also, we suggested that suppliers visit us but we didn’t insist on it. Again, this proved to be an invaluable strategy; if you don’t visit and ask all the questions you need to, how can you be sure that you’ll be fit for our purpose? I can say here with confidence that if we hadn’t experimented first, we wouldn’t have arrived at this approach. Again, so much for my hammer.
As for the suppliers who did visit, each had something very positive to say about the documentation we provided. Some said it was refreshing to not be forced into recommending specific, limited solutions due to over-prescriptive requirements. Others said that because we asked open questions, they felt liberated and passionate about demonstrating that their solution was right for us; one even said that the RfP was the best they’d ever seen. Proof that simple, collective activities can work more effectively than formal, burdensome procedures? I’m not saying that, had I gone full Prince2 and produced a user benefits-based RfP, heavy with detail, descriptions and demands, we wouldn’t have had an adequate response, but I am saying that simply asking the business ‘what matters?’ and laying this out in a straightforward manner gave the documentation a quality that clearly evidenced that the process had been, dare I say it, fun. Our end-users had fun in the workshops; the IT department had fun translating their handwritten Mind Map into a Visio diagram, and consequently both the project team and visiting suppliers had fun engaging with each other to ascertain if their solution satisfied our purpose. It was fun to watch suppliers think, to perceive their cogs whirring, to observe their creativity, liberated from the weight of prescriptive chains. It was fun to reflect afterwards on who asked what, and who didn’t. The whole experience felt light and enjoyable – two words one would hardly associate with project management.
The proposals we received reflected the liberated creativity we observed, making it very hard for us to arrive at a shortlist, so if there’s one downside to how we approached the project, it’s that!
Once we select a successful supplier, it might be the case that it’s appropriate to adopt a formal methodology, to align with the supplier’s requirements, but now that I carry a light toolkit around my waist instead of a heavy hammer in my hand, I’ll need some convincing.
Mark Elias is the IT infrastructure manager for Coastal Housing Group.
