The majority of large change programs or projects will reach a cost and/or time overrun down the line.
All seasoned project owners and managers know this and plan for it. They will add some slack in the timeline, there will be dedicate buffer in the budget etc. If you are one of those who run large change programs for a living, you probably do Montecarlo simulations in your spare time – as the crazy project nerd you are.
However, at some point, going over budget or postponing launch dates will become unacceptable for the key stakeholders. AND If the project is big enough the «key stakeholders» are the Board and the CEO/CFO.
Likewise, large projects running over several years will be exposed to sufficiently large external forces that require a change of project scope. This might impact the urgency or the focus of the original business case – if revenues are falling drastically, cost reductions might be much more important than the original feature oriented scope.
So even if there is a genuine will to take some risk and reduce quality expectations (the only levers left when cost and time are exhausted), there will be only two viable options on offer – reduce the scope or stop the whole ting.
Now, you might be tempted to go with the second option. Stopping sounds great! You can get some well earned vacay, and perhaps even catch up on the webinars on Cloud-something-or-other you have been postponing for 5 years.
Not happening. Too many stakeholders with – well – a stake to fall upon or even worse: lose face. There is even a term for this behaviour. There are real and painful financial consequences. Stock market frowns. Media writes about you – and not in a positive way. If you spot the scope challenges early, you may be able to maximize value; but if you wait too long you will have to look for whatever is salvageable; including the wording on your own epitath.
Therefore – running a project that needs to complete the whole initial scope in order to be completed successfully without full rollback will most likely fail spectacularily – one way or the other. The following is a summary of how I usually approach this, or wish I did in the past…
Acknowledge and accept complexity and continuous change
Probabably the most essential way out of all mess is to acknowledge that there is no end to change in your technical ecosystem. There will never be some amazing nirvana state where everything is DONE. You will always live with different generations of patterns, technology and organizational capabilities. Everything is in some way «legacy».
Managing a hetereogenous topology is at the core of all of your operations; in the past, now and in the future. How you manage your architecture and your investments must deal with these facts of life; not try to enforce an impossible state of perfection.
Invest (time, money, resources) in actually managing the scope across heterogeneous landscape
Quite surprisingly, many large projects seem to fail already from the getgo in this area. It never seizes to amaze me that so many projects that have spent years getting all analysis, business case and commercial processes through the system, seem to ignore the need for some form of ramp-up and initiation. Including practicalities on managing scope across different teams and if necessary – vendors.
On the other end of the scale you have the Excel-fetishists who think 3672 requirements in a massive, shared spreadsheet implies that they are «managing the scope» in a good way.
You need to make sure your plan caters for setting all this up. Don’t just leave it to your PMO to make an advanced spreadsheet by Friday and then check the «completed» box. You will need to agree on a lot of stuff – level of detail and break-down hierarchy (epics – stories – tasks seem to be dominating these days, but there is probably something new and shiny I haven’t heard about), ownership, coordination and meeting places, reporting, dashboards and automation, exception handling and yes – scope change. How is this reflected in the day-to-day work in your teams or vendor interfaces?
I still haven’t seen any magical solutions for scope management in large projects, but the features in integrated tool suites like Atlassisan are fairly strong. They give better overall transparency and places ownership where the work is actually done; moreso than traditional project management tools that tend to be more top-down. The dashboards with right use of plug-ins are pretty cool as well. There is also an added bonus if you can get a strained line org on your side by funding some long needed uplifts in tooling, and sponsor editorial staff for your wikis and jiras and stuff. Most IT people see the need for this kind of tooling, but tend to struggle to get the priority to set it up properly and manage the content in a good way.
And then there is the communication aspect of scope management. It should be fairly easy for stakeholders to understand at least the epics in your scope, and you should avoid internal lingo that is only known to the guys working with the technical details.
There is a lot of best practises out there in this area, but it seems not to be that often visited by very senior project and program managers.
Acknowledge that there are different cultures and Way of Work
A part of the complexity in a heterogenous landscape is refleted in the Way of Work, and how changes to systems are made (or not made, in some instances). You will find everything from:
- Autonomous development teams with a strong ownership to their own backlog, goals and progress
- Systems with this one guy that just fixes stuff
- Outsourced services with strict 2004 style change management processes and yearly release-cycles
- Systems no one has touched in 10 years
- Completely new stuff that still awaits permanent staffing and people are still on training classes
This means that even if you have this great Jira-rig in place, a lot of the required changes will never be triggered and completed by something assigned in Jira… You will need to work with the impacted areas, understand their way of work, and adjust methods and co-working – on both sides.
Beware of the chicken game
Problably the main cause for the long overdue realization that there is a need to reduce scope, comes from different parties being very reluctant to be the first to admit that they won’t make it. You’re there in a status meeting, everyone reports green, and no one wants to be the first to raise their hand (or change the color of the status-thingy in the Powerpoint report to red). This is particularily the case with vendors – even worse if there are multiple ones – and penalties looming.
There are a couple of ways to avoid this, ommitting the obivious one of avoiding the massive scope and «deliver all or fail»-trap in the first place. Basically it is about a combination of trust and mutual transparency, and making sure contracts are not set up to encourage the wrong behaviour. If your contract is full of huge milestones where payments are due, and an associated penalty regime, your vendors would never raise their hands and admit some kind of trouble, if they have the slightest inkling it is a problem shared with others – including you as the client. Usually you end up with the problem anyway.
The combination of fixed price, waterfall, a massive scope and many dependencies is a commercial set-up for total failure. Even if you think you did a great deal when signing.
Convince your key stakeholders that there is no shame in rethinking project approach
Finally – if you have reached the point in time that everyone admits that something drastic has to be done, it is probably not sufficent to address the scope. You will most likely need a more fundamental rethinking of how you approach your deliveries and what methodology you use.
In order to avoid the same happening again a year down the line, you will need to embrace frequent deliveries, a more benefit driven approach etc. Basically modernizing and structuring your way of work; not only the scope. You need a time-out.
The business case associated with such a time-out is probably very good, if your controller is on board with the math. Revisit your methodology and tooling. Look into your project set-up and roles. Renegotiate (or terminate) your contracts. Convince your vendors that changing the fundamentals of the contract to deliver step-wise and have more flexibility to change scope as you learn and the world changes is so much better than calling both parties’ legal departments. The amount of wrong choices going forward is proportional to the number of ties on both sides of the table in these kinds of disputes.
Project owners, project managers, vendors, executive consultants – you will all have to digest a couple of camels in order for at least something to succeed. Just get over it; and then get to it.
Oh yeah, and kick the executive consultants to the curve. They probably got you in this mess in the first place.
The Good, the Bad and the Pragmatist 