The Scenario
A project manager is working on a project to develop a product/service in the retail domain. Two of its company’s competitors are also competing to get the product/service out on the market as soon as possible. Clearly, the first entrant would have a significant advantage.
The originally planned project duration was 8 months. The project is in its fifth month. The project performance report clearly indicates that the team is behind the plan by 5 weeks, driven by frequent scope changes, scope creep, inaccurate estimation, and inconsistent stakeholder requirements. The team is not able to recover this negative variance as they go along. On top of this, the project team believes that it would need an extra two weeks to fix some of the quality issues currently plaguing the project. Overall, the project needs about 2 months more.
Would you label this project as ‘Troubled’?
Before committing either a ‘Yes’ or ‘No’, it is important to understand the premise on which one would make a decision here.
As a project manager, one should be aware of the critical success factor for the project. What is that one thing that is critical and non-negotiable from a project perspective?
In the above case, it is clear that Go-To-Market or ‘Time’ was the critical success factor. Based on the data available, we should call this a troubled project as there is no hope for the project to be delivered within the original timelines. Some of the other indications of a troubled project may include –
• The product/service has more than ‘acceptable’ defects
• Validity of assumptions
• The team is working overtime for a fairly long period of time
• Lack of customer confidence about the outcome of the project
• Team frustration due to multiple and disparate systems deployed at enterprises
• The project team and the customer’s team playing blame games and…
• …Many more
By the way, critical success factors are usually unique to projects even if they are delivered to the same client.
Now…Recovering Troubled Projects
Resisting the inevitable intense pressure to ‘fix the project’ immediately, it is recommended that the project manager considers the following –
• Ask an important question – Do you really need to recover the project? In the current globalized scenario, due to various reasons, a project may not be relevant beyond a specific timeframe. If so, it may be better off to kill the project rather than pursuing further.
• Diagnose the project to unearth issues and root causes. Some of them may include too many scope changes or creep, inaccurate estimates, significant cost overruns, poor quality etc.
• Perform an Impact Analysis of scope, time, cost, etc., by objectively quantifying the impact. This is important for the sponsor/client to clearly understand how much more the project might cost. It also helps the sponsor/client to prioritize aspects that ‘really’ needs recovery.
• Create a ‘Recovery Charter’ for the project.
• Communicate to all concerned the process of Project Recovery
• Set, monitor, and influence expectations with key stakeholders
• Go through the steps of Plan–Execute–Monitor & Control–Close like in a normal project.
It is not a surprise to observe that it would still be ‘another’ project. However, it has some additional flavors such as –
o Rigorous/detailed planning
o Close monitoring & control by way of tighter stage gate reviews, milestones, change requests, etc.
o An extra sense of urgency by everyone on the project
o Enhanced level of performance discipline
o Effective communication
o Strong focus on issues and risks
o Greater integration between Performing Organization and Client Management
While working on a project to be ‘recovered’, it is important for the project manager not to panic. This is the time to draw on the collective experience everyone aided by global good practices. The project manager will surely succeed if s/he applies discipline, clear communication, and leadership in this endeavor.
The management could, on its part, ensure to have an ‘Integrated Project Management System’ in place which takes care of duplicated efforts, multiple data-entry points, unwanted data extraction/analysis, etc.
On hindsight, do we need projects to get into trouble before we become disciplined in managing them? Else, we might just be doing our bit to increase the rate of project failures as reported by PMI in their 2016 Pulse of the Profession!
