Imagine being called into a room where the air is thick enough to cut. You walk out of your typical workday straight into a wall of lost hope. Perplexed and total inner surrender expressing faces look at you. From the part of the desperate lament you could understand, you rhyme together:
- someone wanted a project
- the implementation was provided with personnel and budget
- the implementation unfortunately failed
- you have to help
Now good advice is expensive, because you do not assume yourself to be smarter than all those who have worked on this issue so far. The first thing to do is to understand what happened. But that is sometimes easier said than done.
Like a good pathologist
First, take a good look around. By definition, a project is a focused, one-time endeavor – and thus cannot be implemented in minutes, nor can it be salvaged in minutes. So first, take the time to dissect the issue to get to the bottom of the problems. The small introductory section is ideal for this purpose. It lists all the necessary requirements that can contribute to the success of a project.
Since it has already been written above WHAT everything has been done (and the list is obviously complete and final for all time), you can therefore concentrate on HOW it has been done. In this way, you should discover relatively quickly the stumbling blocks that have doomed your predecessors.
Who is actually this „someone“?
Who actually had this idea? Behind this seemingly simple question lies the web of stakeholders in the project. Something is to be implemented, and the topic has been addressed. For the success of the project, however, it is quite crucial by whom it was supported. For a larger project (for smaller topics you would not have been brought in at all) in a company, at least three levels should be involved in the support:
- Functional: technical experts / the team … goes through the problem in depth and provides analysis material and as-is processes.
- Operational: middle management … looks at other projects in terms of content and budget (internal benchmark)
- Administrative: Top management … finds the project to be in line with the strategy (external benchmark)
If several departments are affected (e.g. logistics, accounting and purchasing), it is strongly recommended to include all of these departments, at least functionally and operationally. If the opportunity arises, you are also welcome to contact the representatives in management or the board of directors. In an emergency, it never hurts to have the support of the highest possible management levels.
If not all levels are aware of the issue – or worse – are aware of the issue but do not support it, then you have already discovered the first problem. However, if the support is there when you arrive, there is nothing left for you to do but read on.
A „project“
Let’s call this part „I’ll think of something, that will make things better“. Normally, a concrete problem is to be solved, which can present itself in various forms. Now this sounds comparatively theoretical, instead you can also insert „we are building a house“.
Abstractly, the requesters have a target state in mind (house is there), from which the actual state differs (house is not there). To close this gap, a project is needed. The project in turn needs beside the main goal „house is there“ some subgoals, e.g.
- within 1 year (Time)
- with not more than 500.000 € (Budget)
- with 250 sqm floor space and full basement (Scope)
- the neighbors should like us after the construction (Change)
It is important that objectives, requirements, framework conditions and planning premises are adequately documented and made transparent as part of the decision-making process.
Don’t forget the project itself. How high are organizational and technical complexities to be assessed? Is strong resistance to be expected? Try to get a sense of the nature of the project to better frame it as a whole. What you find here is best written down in a results document you keep.
If, in addition to the benevolent support of senior management, all of this has already been described, planned and signed off in detail, take a look at the implementation status.
Quo vadis project?
„Failed“ is such a harsh word – and you should ask how people come to that conclusion. Projects often don’t reach the end (in which case the project would still be running), or they don’t achieve all their goals (so they are at least partially successful). When management talks about a failed project, they usually have a fresh start in mind. In such cases, it may be sufficient to plan a new start for a few weeks, give the child a different name, and then continue the work in a structured manner. In other cases, achieving the goal in the current setup is either pointless (shifting the goal) or impossible (very large adjustments necessary, requiring a redefinition). You find out all these things by determining the current status.
So now it’s all about measurement. So after working through the first section, there is a plan, and it is very likely that activities have at least been started. So nothing is easier than putting one over the other and determining the degree of accomplishment, right? While the goal „house is there“ is quite easy to measure by sighting, the sub-goals are already more difficult to verify. Each of these sub-goals has indicators that need to be observed during the status determination process. Here are some examples:
- Time … project start, time and activity planning, milestones
- Budget … internal and external performance records, invoices, commitments, forecast
- Scope … requirements, solution description, quality, scope
A great opportunity to identify omissions in the project is to look for (and not find) this type of documentation. If anything comes up here, make a note of it.
Fireside chats
Now that you’ve spent a while poring over old documents, it’s off to the project team at the latest. If you have the opportunity (not in all projects are those involved still available / willing to talk), grab the following colleagues for input on the state of play:
- Project manager … helpful for information about the team, the management, the project, the progress
- Specialist team … helpful for background on the quality of the solution, cooperation between the areas, concrete problems
- Management … helpful to understand how the project is perceived in the organization, if there are opponents
The good ones in the potty
Even during the interviews, you always diligently write down what seems relevant to you. Gradually, you will get an impression of where the shoe pinches. Keep in mind that there is a difference between perceived and actual problems. Listen between the lines, and if nothing else, ask lots of questions.
You absolutely must be inquisitive at this stage (without being rude, of course). If you encounter excessive rejection despite asking appropriate questions, this should make you suspicious. There was a reason for the failure, and you have set out to find and eliminate it. Normally, this is not possible without digging a little deeper here and there.
However, hold off on jumping to conclusions or making accusations. Should you identify one or more problem factors (which is likely) that can be clearly attributed to one person/area (which is rare), you will need clean tactics for documentation and communication to avoid burning the organization for all subsequent recovery activities.
If you have publicly crucified an area, it will only protect itself more in the future and stifle any further initiative in that direction in formalisms. Seek consensus when there is one to be found. Counter-actions (e.g. about escalation even before the project starts) may be necessary, but are rare.
Sisiphus
Of course, status determination is again about document analysis. Depending on the phase of the project, there are more or less documents that need to be looked through. In particular, look at
- All projects: Status reports, steering committee minutes
- early design: requirements
- Design: Design documentation
- Build: Implementation logs
- Build: Test planning and test protocols
- Cutover: open point lists and incidents
This will give you the documented impression of the project status. If the documents do not match the descriptions at all (e.g. because everything documented is green, or because the documentation lags far behind the actual project), you may have found another cause for failure.
Phoenix
As an emergency physician on duty, you naturally not only have the well-being of the patient in mind, but also the goodwill of your clients. Especially on large projects, make sure you regularly update management on progress.
Always take it easy
Before you do each, review the content and wording of your deliverables. It always helps to dig for root causes, but it doesn’t help anyone to nail them to the cafeteria wall afterwards. Critically re-read each of your statuses: is the necessary level of transparency in place, or has it been exceeded? What details are necessary to make a fresh start on the one hand, and to give everyone involved the feeling that it will work on the other? A rule of thumb: if you name names, 95% of the time there is too much detail.
So communicate with tact, without losing sight of the moment when clear words are needed.
There will certainly be a part of your notes that you don’t want to share with others and therefore rather file separately. The – proofread – results should be written down, and ideally handed over to your client in two aggregations:
- a slide set of no more than 10 slides on the project, your analyses and conclusions
- a detailed assessment document with the relevant background information.
You can use the latter to record your thoughts and findings right from the start. If there is a possibility, look over the contents with the involved areas before communicating the intermediate and final statuses and seek agreement. Representatives from middle management, for example, are good for this (should you report to top management). You don’t have to get every formulation signed off, but it helps if you get another opinion and, if necessary, know the criticisms of your results.
Ready, set, ..
Depending on the work order, replanning may well be part of the job. You now know where the rabbit was in the hare. Check if there was a mistake in scope, time or money. There may also have been problems with documentation, organization or management support.
So under the big goal „House is here“ write the sub-goals that have now been rearranged. If you have to reschedule time, scope and budget, be sure to involve the departments involved until a coordinated plan is reached. Even if the colleagues involved are exactly the same ones who planned back then, they too are now smarter about failure.
The result will only sometimes surprise your clients, most of the time they will already expect major adjustments (otherwise they wouldn’t have hired you). But even if they are shocked by the realistic planning you have now worked out: negotiate about the scope if necessary, but it does not change, never negotiate about budget or time. The information you provide is weighed and agreed upon, and any change to it torpedoes your colleagues‘ professional judgment (again?). Keeping a plan high even if the decision makers demand „more for less“ is the first step towards a successful reboot.
Last but not least: You are there to help. If you are unsure, take it one step at a time. No emergency physician has fallen from the sky, and no one can expect miracles from you. However, you have already gained a lot with a structured and transparent approach, so don’t let yourself get rattled even in stormy conversations.
Good luck with that,
