How late is too late to change project methodology on a failing project
Anonymous
Working on a major ERP implementation that has been running for around 18 months. There is an operational deadline 4 weeks from now, but there is still a vast amount of work to be done (probably 3 months or more).
I joined 4 weeks ago, and am thinking of proposing a switch to an agile way of working to recover the project and blaze through a significant amount of work that HAS to be done before the deadline - thankfully it seems that some "less important" stuff can be postponed until after the deadline and a small amount may be de-scoped altogether - the organisation has never tried Agile.
R.G.
Saving Changes...
Sort By:
Elizabeth HarrinDirector| RebelsGuideToPM.comLondon, England, United Kingdom
I think it depends on how long it will take to train everyone in the new ways of working. If you think you can slip in Agile methods without too much training or culture change, then go for it. If it's going to take you a few months to get the processes to bed in, then you'll need to take that into account when you rebaseline the project schedule. Saving Changes...
A major change in methodology for the whole project at this stage would be quite risky- especially with the training & culture change implications that Elizabeth has pointed out. I'd put together a rescue plan with it as one of the main options and see what the board/sponsor think. Saving Changes...
Imran ManirSenior Project ManagerBurton On Trent, United Kingdom
I'd focus on identifying what will prevent you from delivering to plan. Then propose how you will prioritizing what NEEDS to be delivered in 4 weeks and options to deliver this, along with your recommendation.
I'd also review the remaining scope, prioritize into different iterations accordingly, again with recommended option for delivering this.
Given you're 4 weeks away on a project that's been running for 18 months, I'd also highlight what's gone wrong and what you'll be doing to ensure the same actions are not repeated.
Agree with Tim and Elizabeth on on the risks around introducing Agile in at this stage. However, would be worth understanding what the driver behind the operational deadline is and the flexibility around this. Saving Changes...
Imran ManirSenior Project ManagerBurton On Trent, United Kingdom
In terms of the question "How late is too late to change project methodology on a failing project". My own view is that it depends on the impact of introducing the methodology and whether the benefits of doing so, outweigh the associated time, cost, effort and risk.
Needless to say, another consideration would be the level of risk the organisation is prepared to expose itself to. Saving Changes...
Wayne MackRetired| RetiredSouth Riding, Va, United States
Agile is not a silver bullet. If there are 4 weeks remaining, but 12 weeks (3 months) of work remaining, agile will not magically enable the develop team to do 3 times the work.
There are several options, but frankness with the project sponsor and stakeholders is required. The project will not finish ontime with all desired scope.
One can cut scope and meet the deadline. If the project has been in waterfall, this would probably mean stopping all development today and devote the final 4 weeks to test and break fix.
One can deliver all scope, but extend the deadline. BOne should be very conservative in setting a new deadline - one does not want to come back and ask for even more time.
One can both cut scope and extend the deadline. I would recommend first follow the approach in the first option and freeze development, stabilize, and thenround out the feature set.
There good reasons to use agile, but expecting the development team to "blaze through a significant amount of work" because of agile is not one of them. This project needs to be replanned. Completing the project using agile might be useful in demonstrating progress to the stakeholders, but it will not turn the development team into supermen and I am guessing that at this stage of the project, the development team is probably already working exceedingly hard. Saving Changes...
Bernard GorePortfolio, Programme & Project Professional| NZ PoliceWellington, New Zealand
On a general case, it is NEVER too late to change. I've been brought in a number of times to rescue failing projects, and if you can see that the methodology is not working, and a change has a reasonable chance, then try it.
However be VERY careful that this is the right thing to do - too often a change in methodology is acover for more serious problems, and Agile is especially used in this way - and often what is proposed as a change to Agile is no such thing - rather than really using an Agile methodology it is an excuse for "lax" approach to try to bundle stuff through to some sort of state that can be claimed as a success.
I have seen a late shift to Agile work - but only because a strong PM who truly understood what Agile really involves (i.e. Me) made sure this was done right and there were enough key players involved who understood enough and were willing to help do this right.
If the organisation doesn't have the experience, and doesn't have a strong PM with expertise in Agile, experience of such a shift and project rescue, then I'd say resist it - de-scope or delay the items you can and do a rapid re-plan - that is more than enough to keep you busy and is likely the best route to succesful delivery. Saving Changes...
RG:
What does the sponsor want to do and what was promised to the stakeholders?
I assume you are the new PM? If so, regroup with the team; identify the major issues, review historical documents, risk logs etc and get a good sense of what went wrong and why.
Once you have a firm grasp of the situation; make a proposal using the triple constraint and go in with a solution/recommendation in mind with strong reasoning behind changing the methodology.
Good luck! Let us know the outcome; we can all learn some lessons. Saving Changes...
Wai Mun KooPMO Director| Intergraph PP&MSingapore, Singapore
There have to be some reasons why a project is running late. I suggest you focus your effort in finding out what are your problem(s) and the root cause(s) first before making the corrective actions to improve the situation. Is the project methodology the root cause? Or is it that the project is not following the methodology at all? Experience tells me that the latter is usually the case. A methodology, after all, is an approach of doing things, although it might not be the best approach, it usually can't get too wrong.
So, instead of spending all your effort into introducing a new methodology which could potentially introduce additional risks to the project as highlighted in some of the comments below, why not focus your effort to find out the root cause(s) first? Saving Changes...
