Project start, on your marks, ready

6:30. The alarm goes off. You jump up, grab your briefcase and the car keys. Before the morning traffic jam, you want to make it to the office today. “The early bird catches the worm,” they say. As soon as you arrive at the office, you start your computer and get your first coffee in the kitchen. But when you look in the mirror, you realise: Shit! How could this happen? You still have your pyjamas on! You forgot to get dressed before you stormed out of your apartment.

Of course, things like that don’t happen in real life. But maybe you have searched in vain for your sports shoes in your gym bag? Or your toothbrush when travelling? Or the directions to an event or a hotel? Such things happen relatively often in private life. And at work too. Figuratively speaking, many projects even start in pyjamas.

Practically all project management methods describe activities and/or processes for an “optimal” project start. PRINCE2 even defines two processes: “Preparing a project” and “Initiating a project”. When preparing a project, it should be possible to estimate with little effort whether a project idea is worthwhile at all and whether there is a corresponding business case for it. The initiation phase then creates a solid basis for the project, in which the project manager creates the internal procedures for e.g. the project plan and the communication plan. At least that is what theory says.​

The reality at the project start

In daily business practice, completely different approaches can be observed. Organisations feel driven by customers and market expectations. From the point of view of IT departments and their projects, these are the business departments that want to have implemented requirements yesterday if possible. Here are two short examples from my practice:

1. A development project at an automotive supplier

In the development project, the aim was to get a consortium under “one hat”. The project manager did not want to create a central project planning or establish a project controlling with a corresponding progress measurement. Progress was measured exclusively on the basis of the reported times of the individual partners. Progress was not measured on the basis of work packages. There was also no steering board with various stakeholders, so there were two main problem areas in the development project:

• Progress control was practically impossible
• The right contacts were lacking for upcoming decisions and necessary escalations, as there were no clear roles and responsibilities

2. Implementation of software for process control in a health care company

In this project, both the project manager and the client were faced with a finished fact. The software to be introduced for future process control had already been selected. The service provider was determined and the contracts were signed. What was not clear were the technical processes to be developed, which still had to be stored in the software, i.e.

• the form of cooperation with the service provider
• the scope of the project – this changed in the first two months, so that a local implementation project became a worldwide roll-out

The departments were naturally overburdened with the procedure and the process design. Then it turned out that the service provider did not have the necessary resources to adapt the software. And then there were internal squabbles with parts of the management. So there were three main problem areas during the software implementation:

• The key members of the project management team were not involved in the key decisions at the start of the project, such as selecting the software and the service provider
• The cooperation with the service provider was not defined and agreed
• For the client, a methodical approach seemed rather obstructive at the beginning

In both projects the starting line had already been crossed. The problems that arose during the project did not arise during the project but were the direct result of failures at the beginning of the project. Just like in “real life” these failures caught up with us quickly. You probably know the one or other example where mistakes made at the beginning of the project became big problems in the course of the project, don’t you?

The core areas at the beginning of the project

For more than 20 years I have been working as a project manager. In my experience, every project manager or client of a project should try to consider three core areas at the beginning of a project:

1. Order clarification
2. Responsibilities
3. Project vision

Why are these 3 topics so important?

1. Order clarification

Order clarification is an essential part of project planning. As a project manager, you must understand the expectations of the customer or client. It is important to know whether there is a specification or just vague ideas that need to be implemented. In the first case, criteria for acceptance can be defined. If there are only vague ideas, it is important to agree with the client or customer how the project team will arrive at the specification. This may mean that you have to allow time for the planning phase to gather exactly this information. If you miss this step, it is quite possible that you will not meet the expectations of the client and that there will be many discussions about the actual project.

2. Responsibilities

An essential success factor for a good project start is the definition of roles and responsibilities. This applies both to the service providers and to your own project team. For you as project manager it is particularly important that you clarify your responsibilities with the client. For example, which content/technical decisions you are allowed to make yourself, what influence you have on the budget and at which points you need the competence of the steering board or client.

From my experience, I can say that the steering board, with the client at the top, plays an essential role in the success of the project. PRINCE2 describes the client or project sponsor as “ultimately responsible” for the project. He is responsible for the success of the project because of his decision-making authority – not the project manager. The project manager has the central responsibility for the day-to-day business – planning, delegating, monitoring and controlling. However, he does not make fundamental decisions. This responsibility lies with higher-level management.

3. Project vision

“If you want to build a ship, don’t call the people together to collect wood, distribute tasks and divide the work, but teach them the longing for the big, wide sea.” This quote by Antoine de Saint-Exupéry (1900-44) may sound a bit trite, but it describes a very important factor for modern project management: the project vision. Most project managers want motivated project staff and not work robots. Therefore it is also important to take employees along, motivate them and give them a view of the “big picture”. This gives you a common framework for your project. Even if it is not always easy to formulate a project vision for each project in day-to-day business, it is very valuable and worth the effort.

Conclusion

In many projects that are driven by specialist departments and where there is a great deal of pressure for success and time, the third and fourth steps are often taken before the first. Usually it is very costly and difficult to correct mistakes in the course of the project, whose causes lie in the poorly or not at all planned project start. Therefore, project organisations must learn to consider the project start – the first steps and decisions of a project – as an elementary criterion for the success of the project. They must pay as much attention to this part of the project as to the actual project implementation. Otherwise, one day you will be standing in the company kitchen with your pyjamas.

Notes:

Steffen Wendel has published another post in the t2informatik Blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.