Actually it is easy to remedy projects in distress. Because the causes are usually as trivial as the resolutions for the Project Recovery.
The Classic
A project quarrels with the departments involved about resources. It needs skilled people with good knowledge on the topic, but the line needs these, too, and is not willing to dedicate them except (if at all) some who are on the bench anyway – a classic. In the end both are loosing because it will not work as planned that way. Sounds logical, doesn’t it? The solution: The departments do desire something from the project. So put them into the driver seat, make them “Product Owners”, take them into the responsibility !
Often the problems are at hand, but the customer is defending the resolution.
A project in Public Administration was about 6 weeks before it’s Go-live. That had been postponed several times already (total project duration 1 ½ years so far), and the budget was exceeded by far. Already at the first talks upfront in a video call I heard that project roles and responsibilities were not clear yet, the IT supplier did not deliver to whatever planning, and that the Go-live must happen now by any means. Well, I think I have an idea…
Ironically enough they played very budget sensible due to strict release processes etc., and they decided for a “cheaper” solution for the Project Recovery. If only it weren’t tax funds again, I wouldn’t have cared!
Apropos budget – another example:
A big energy company planned a business critical project (I knew it would be a program for the Project Recovery) to implement very specific software. For that there are not too many project managers with an adequate experience available out there, but I had done that two times before successfully. However the daily rate budgeted for project management did fit for average skilled project managers without special knowhow, and they were not willing to “needlessly” increase the budget. At the moment of this decision they de facto increased the project budget needlessly and significantly…
That means I can’t rescue not every project or safeguard it from distress, in particular if I’m not allowed to. This category also applies to two more cases. Here however I had already some time to prepare recovery measures.
(Survival) critical measures cancelled due to resource bottlenecks
At the first one the management and a little group of engaged people compiled a huge catalogue of ideas how to establish our AfterSales with lots of customer benefits in a mature market to intensify this profitable business, and protect and increase market share. All were clear that this was, though technologically leading, without alternative to stay market relevant in a few years. I defined these ideas to initiatives and projects, and structured them sequenced and correlating as a program. Some of them we even started to execute.
Then some of the managing directors in some emerging markets considered that they were doing quite well as is, and that they had too few resources. Budgets were cut; the company was too “lean” to execute the projects. Project Recovery would mean here: You should sharpen the saw in summer to go to the woods before onset of winter, or you will have to leave chances at hand.
Being not able (or willing) to understand, and desiring too much in one chunk
In the second case we talked about a engineering company’s business unit running out of rudder (organizational as well as financial). They wanted to place new and future promising products in the market based on a few contracts with pilot customers. But R+D and customer projects went quite unsynchronized, followed by long delays on committed milestones, and the risk of high liquidate damages, cancelled series orders, and the loss of market advantages. We simply had too few resources for increasing (on top of the pilots) customer projects, and development projects did not keep pace – using the same resources – with their delivery. The cause-effect-mechanism is clear, isn’t it?!
So I started for Project Recovery as the business unit’s programme manager to establish structure, tools, and processes to control resources, interdependencies, joint risk, and communication between the involved parties and stakeholders – following the motto “to build a fence before catching the chickens”. Also we implemented some circles with my moderation to better coordinate the customer and R&D projects. Recruiting was getting up to speed, and for software development which repeatedly trashed our milestones I was planning project reviews.
Then my contract wasn’t renewed. The unit lead had not understood, what I did, what programme management meant, and what was necessary to do, rather was focused on the external picture towards the C-level than to the program’s content, and may be saw a competition in my activity which I could not dispel. Despite we already were completely overloaded, she accepted, while complaining the resource situation to the management, three more customer projects she “could not let go”, hoping she could generate nicer figures for the business unit. I cross my fingers for my colleagues…
Each consultation only can be as good as the consultee is allowing
Sometimes it just comes with too much transparency, uncomfortable truths and or unpleasant Must Dos – especially if things are that obvious and trivial. Life definitely writes the best stories to tell. But there are also the good examples without resistance to take advice and learn. And these are the cases that take companies and employees further without any feeling to throw good money after bad.
Learn more about Project Recovery…