Projects and Pitfalls

All projects and programs start with hope and expectation. Business leaders will have been through countless presentations showing all the benefits they’ll get once everything is live. The incremental income from new websites, the FTE efficiencies of implementing a new ERP or unleashing marketing with a new CDP.

We’ve all been there. Right through the initial scoping, identifying the key features of your MVP, the RFP process, the initial scoring of effort and getting the business case signed off. Going live, measuring the first days’ and week’s KPIs, and seeing the performance you’d expected (and hoped for) is one of the best feelings in the job; however go live isn't always on the day you’d planned, the benefits come through later than expected and not without blood, sweat, tears and sometimes a bit of blame thrown in for good measure.

I want to look at why this happens and how to prepare for it, even avoid it, and above that how to make sure that nobody gets that heart in the mouth moment when you realise that something was missed, not factored in properly, that moment when you just think, how the flip did I/we miss that? How do I tell the exec that they wont get a feature they expected, or the project will need more time, more money, more resource or all 3!

These moments are tough, if nothing else to help build resilience, but they also provide a learning opportunity.  Whenever this happens, even if the business has just moved on I try to do some root cause analysis and if there is something I could of avoided; I vow to never make that mistake again. 

The causes for this type of situation, in my experience comes down to a few small areas.

Requirements. When a project is in kick off mode there will be requirements coming in from everywhere and every one. The steering committee will have their view, department heads, investors everyone contributes. You'll try to pair these down and agree an MVP. The product will get built, it will look great and do everything it should. And they will say something like "It looks great. could you show me how to match of the payments to the invoices on a single screen, just how the old system did". At that moment you'll remember the importance of engaged and accountable SMEs. From then on, you make sure that there are end users involved ion the project from day one. The question for the SMEs- What does the system do today? Do you use that feature? and What could be better? If they use it now, it must stay, if they have it but don't use it, it should go, if it’s new, (make sure they will use it) and build it.

Though SMEs are part of the projects rulebook, its not as easy to as it sounds. How do you convince a line manager let someone leave their BAU work (and the project needs someone who is experienced, can communicate well, understands multiple roles in their team)? Ideally the project sells itself, the vision of the future where the team is more efficient and more productive, because starting a project without the SMEs is a risk, and one that should be called out and documented.

Cone of uncertainty. There are other challenges that projects face. Unknown, unknowns and the cone of uncertainty for example, it is hard to know how long something will take before you start. There is always pressure to deliver quickly but by setting an unachievable go live date really helps nobody. I've seen projects start with 10, 20% contingency and find that gone in the first few weeks. In an ideal work there would be a pre-go live phase for the project where the key output was the plan. That plan needs to be agreed in terms of the scope, the dev time, the testing time and the refactoring and it needs to include the rollout and training plans. By focusing on the unknowns you can narrow the cone of uncertainty and by setting a first milestone of providing the detailed timeline the stakeholders can be better prepared.

Testing. Testing often gets squeezed when plans start moving right but that is a big risk, particularly to the quality of the product you go live with. I would even advocate for more testing. In a recent project the client didn't have a dedicated testing team. What we decided to do to mitigate this was to ask all of the users to help. We agreed with the exec that all staff would be given 2 hours to test, we set up an all hands teams meeting and off the 300 staff managed to get 150 people testing at the same time. Each person wen through the BAU tasks, and although the testing wasn't as deep as it would be with a testing team we covered hundreds of test cases and got a good view of the issues. I don't think this could replace formal testing but it compliments it well, and if testing does get squeezed it can offer some mitigation.