lessons learned – Page 3 – Henning Zeumer Projektmanagement

An experienced Project Manager doesn’t make a Project Doctor

It takes more than an experienced project manager to rescue a troubled project:

What’s most scarce at a project recovery is time. The Project Doctor must be able to ramp up extremely short-term. Affinity and understanding of the project context is key, industry expertise not necessarily. There are always nearly the same mistakes happening in all industries…
Project recovery is for absolute hands in the project management subject. They need deepest methodologic competence far beyond normal project management, i.e. not only knowledge but comprehension, and safe application of project and programme management and agile methods.
To quickly find effective measures for recovery it takes much experience in rescuing distressed projects: proficient identification of the main reasons and corresponding adequate measures.
At troubled projects often nerves are strained. To succeed the Project Doctor must bring along high leadership skills, knowledge of human nature and much empathy in Stakeholder Management.
This also involves distinct conflict resolution, moderation and mediation abilities.
Sometimes the devil or the agreement is in the detail. That’s why a good legal appreciation for contract set up and interpretation in the cultural context is an important asset for a Project Doctor and his client.
Projects in distress often require changes in many areas. Therefore a Project Doctor who is also an expert in Change, Supplier, Contract, and Claim Management is an advantage.
And finally a Project Doctor need a “solid back“, independence and readiness for confrontation. He must not fear “high-ups”.

You already lost enough money in your troubled project. Do it right this time, and acquire help from a real project recovery expert! He will always be more economical than a cheap solution…

Portfolio without Management creates disappointing Results

“But we do have a Portfolio Management!” recently claimed a CIO, who couldn’t understand why his projects permanently struggled from resource issues. Definitely: Portfolio Management (PPM) serves to utilize scarce resources – probably the usual case – at a maximum of business benefits. Benefits are measured by the contribution to achieve (strategic) business goals. But PPM is not a tool but a transparent and consistent process by which the portfolio is managed (which can be supported by a tool). And this needs to be consequently applied if it is to help !

I’d like to show three missed prerequisites as reasons why in my example here the PPM was to fail:

Who wants to meet objectives needs to have such ! And they need to be harmonically coordinated, e.g. with a Balanced Scorecard or categories like long-term (such as growth, market position etc.) and short-term goals (e.g. innovation, market entry etc.) and sustainability. If strategic objectives compete or even contradict the portfolio will not be efficient, and also will not achieve it’s targets effectively.
Prioritize – and keep with it ! Following the priorities the resources are to be assigned to the projects, not opportunistic or because someone is yelling louder. That doesn’t mean it would be impossible to change priorities due to better insight, but changing direction frequently doesn’t help achieving targets.
Never do more than you can ! Those are doing right who do the yearly planning for the project pipeline by matching the planned capacities with the desired projects’ efforts in sequence of their priority. But if you find you also urgently need X, Y and Z to be done (on top), and you add further initiatives during the course of the year, you will overwhelm your organization’s capabilities and capacity for suffering. And you don’t need to wonder why not more but less than planned is finished…

I wish that more managers in the C-Suite would self-limit their “flexibility” and “autonomy of decision” in favor of comprehensible decision processes and a realistic discipline of expectations, thus increasing their business results effectively and efficient by a structured PPM. And by the way they will strengthen their employees’ motivation and significantly improve projects’ results (time, cost, quality, business benefits).

Programme Managers need Grip on Reality

Keep close contact to project managers, even to the work floor. Do not only concentrate on communicating upwards! Your program marketing is better if you can tell stories of it. If you are not inside the program you will lose oversight, get unconfident with the status, start beating subordinates without reason, and even loose rapport at your superiors.

Why not short-time working in projects?!

When budget cuts risk forcing you to set your project on hold it is considerable to continue with reduced scope or speed rather than to roll off a good team. To save expenses part-time resources continuing on low effort may be preferable over a complete freeze and ramping up new resources when the project resumes.

Proper Scope Definition is the Base of Project Success

Many projects are sick before they even begin. The cause often is an improper, indistinct clarification of what has to be done. Particularly in many cases the translation from business requirements into technical specifications is a weak point.

To understand the scope right you need to be clear about all stakeholders involved. Conduct thorough stakeholder analysis to assess interests, influences and requirements. Sometimes the scope needs to be developed iteratively from project definition/charter, e.g. by an agile approach or in design workshops.

Describe scope and requirements result-/deliverable-oriented and unmistakably, not descriptive. Define and agree to measurable success criteria. Generally you should ensure requirements’ sign-off before starting development to avoid later discussions on scope.

Only when your scope is “properly” clarified you can plan the execution “properly” and realistically!

Subdivide/show progress by multiple delivery sub-units fit to formal approval underway.

Always assess what you do, what you think you should do, and what your stakeholders think you should do!

Clear Talks

Project managers’ communication shouldn’t be honest only, but also clear and unmistakably.

How often did I experience uncomfortable messages or tasks brought to colleagues or superiors ponderously and with nice, ornate words. In the end everybody had understood something different, later discussions ended up in finger pointing but not in solutions.

Bad news are best communicated as they are, good ones by the way as well. At clear talks it is important that it is not offending but stays objective. To show a solution or forecast after the facts makes even a Hiob message more bearable, and the consequences get clearer.

An example: Sales had promised the blue out of the sky, not feasible by the project team. I did the maths with the Key Account and suggested to him to choose whether going back to the customer now with good arguments to re-negotiate, or later when the customer’s lever gets increasingly longer. And see, the customer was open to good arguments and preferred a successful project over an unrealistic price…

Project Engineer or Double Head ?

Going by the book each project should have one project lead superior to all other project functions. But I have seen many projects, especially in the technical area, where the project lead was mainly competently leading in professional matters but wasn’t sufficiently qualified as a project manager. Usually the consequence is delivering a good quality but missing the schedule and cost targets.

In complex projects however even a good and experienced project manager can focus his attention either on his job or obtain the technical leadership, otherwise he always is in a role and time conflict. Dependent on where he has his core competence the other area will suffer, especially in case of distress, where he – quite human – will concentrate on what he knows best.

In such projects I have good experience with distributing responsibilities on multiple shoulders. It is important for both “heads” to have an affinity and understanding for the respective other function, but not to have sound expertise in it. Each one provides his core competences to the joint endeavor, ideally on eye level, and the decisions are made dependent on the kind of question (professional or management) in bilateral coordination at the respective lead.

Similar to executing development, construction, assembly etc. of multiple projects often with the same teams in parallel, a Project Management Office can collectively execute repetitive tasks in multiple projects on the project management side as a shared service to support the double head. Or it can even have responsibility for management tasks, e.g. risk and document management, or the commercial part. That frees up space for taking care intensively and generates synergies from learning and cost effects.

Honesty is the Best Policy – and the Fastest

There are most probably lots of situations where you as a PM would like to make the progress or status or forecast look a little nicer, especially if you’re an employee and with regard to your boss and your career. This is how I sometimes feel, too, but I meanwhile prefer to take the liberty to keep to the truth, even if it is cruel.

Whitewashing or making figures seem better than they are namely only adjourns the issues, but a resolution doesn’t get easier that way. Rather the opposite applies, because if there is no problem you probably will not receive any support hence. Yes, right: You are indeed allowed to ask questions or for help. And the earlier you start tackling an issue the more and mostly as well the faster and cheaper options you have – that’s by the way also the case with distressed projects and their recovery!

And at last: If you pin point bad performance, a delayed status, increasing cost or risk you always will look better by your pro-active approach and maybe by your roping in the situation, as if you need to admit faults and omissions later!