Why the initialization phase is so underrated

24. January 2023

Reading time: 6 minutes

"The distance does not matter. Only the first step is important."
Marquise du Deffand

Projects are classically divided into the phases initialization, planning, execution and completion. In addition, there is a phase that encompasses everything: Monitoring and Controlling.

When I ask my customers, business partners, or people in my personal environment what the most critical or most important phase of a project is, I usually get the answer: the execution - because this is where everything comes together, the implementation takes place, tests are made, and so on. There is absolutely no denying that. But what if I told you that initialization is the most important phase in a project? Would you agree with me?

In my experience, the initialization phase in projects is often underrated. Let me explain why it makes sense to invest appropriate time and effort here: Many issues that are often challenging during implementation, such as the risks, the scope of communication, or the management of difficult stakeholders, can be mitigated or even completely bypassed with good preparation.

Why project initialization often fails

Let's imagine that a project manager has conducted the kick-off in which she has presented the project plan, the work packages, their timing and dependencies, and the communication plan. So far, everything seems to be in order, but then it is time for the discussion:

1. The Application Manager, however, has now submitted vacation for the installation day at short notice and his substitute is not available either.
2. The Business in turn can only test if the installation has been performed beforehand.
3. The Quality Manager wants more time for her review and final approval of the documentation.
4. The Process Owner, contrary to the communication plan, would like to be informed on a weekly basis.

What went wrong? Let's first draw on theory: the kick-off represents the conclusion of the initialization phase and should cover all relevant topics so that the entire project team has an overview of what needs to be done, when, by whom and how (including communication channels, dependencies and risks). The Project Charter should serve as input, which in turn provides the basis/justification why the project is being carried out. At the end of the phase, the feasibility as well as the basis for the project should have been put to the test so that a decision can be brought about as to whether the project will really be carried out - if so, the initialization is concluded with the said kick-off.

If we take the theory literally, what the project manager has delivered in the above example might be sufficient. Nevertheless, there are already discrepancies at the beginning, which would expand as the project progresses if they are not caught immediately. From this we can conclude: it takes more than theory teaches us.

What theory does not teach us

Let's look at the concerns step by step:

1. The Application Manager is on vacation at short notice, his substitute is not available on the installation day. This can be attributed to a lack of communication on the part of the application manager on one hand, but also to a possible lack of transparency prior to the kick-off with regard to planning or an insufficient definition of the communication channels on the other hand.
2. The Business can only test if the installation has been performed before. Here, either the dependency was not clearly agreed upon in advance or the assumptions that led to the planning were not documented. For example, this documentation could look like this: "The application manager has a substitution" or "We assume that the installation date must take place on [date] because [...]".
3. The Quality Manager wants more time for her review and final approval. Depending on the situation, this can be broken down to either unrealistic expectations (for example, if the deadline is very tight due to regulatory requirements, a longer timeframe is sometimes difficult to achieve) or to the point described above: the lack of transparency on planning and/or undocumented assumptions.
4. The Process Owner would like to be informed on a weekly basis. Again, this point can be attributed to the issues of unrealistic expectations or lack of transparency/communication. Depending on the project duration, content, etc., it is not realistic that every stakeholder can be informed personally every week. This has to be made transparent accordingly and alternatives have to be shown.

These few examples alone already show that the initialization phase is much more than simply: "We start the project with a few cornerstones."

According to reports - including from the supplier of project management software Asana and also from ProjectManagement.com - three of the most common reasons for project failure are:

1. Unrealistic expectations
2. Lack of communication
3. Lack of transparency

Does this sound familiar to you, or do you find it reflected in the points described above? In my experience, these issues are also difficult to rectify in the course of the project, which is why it is all the more important to lay the appropriate foundations in the initialization phase.

How to set up projects the right way

From experience, many project members (not necessarily the project management) and extended stakeholders regard the initialization phase rather as a discovery phase, in which it is mainly a matter of getting to know each other and agreeing on who and what is needed and who will be finished with their tasks by when. Besides, everyone would like to get started right away and often does not see the benefit that a clean project plan offers to everyone. I cannot blame them, because everyone has a lot to do, a lot of meetings and a lot of activities.

From this point of view, the project manager can conclude that no one would mind if, for example, communication (the number of meetings, frequency of status reports and other topics) or arrangements for absences were made lean. This, in summary, brings me to the points which I consider important for the success of the project within the initialization:

Critical success factors in the initialization of projects

Stakeholder management: Even before the project enters the planning or implementation phase, it is important to talk to all potential stakeholders in person if possible. This applies above all to the central stakeholders according to the stakeholder map/list, although stakeholders with little "power" and "interest" should not be disregarded.

Face-to-face conversations help to assess or recognize dependencies, skills, and know-how levels and inconsistencies at the outset, and then to take these into account accordingly in the communication plan, the planning in general, and the allocation of work packages.

Risk management is an often underestimated point, especially for small projects. As a project manager, you should think about these as early as possible and show them transparently, no matter how small they may seem. Over the course of the project, these should also be reviewed again and again via riskolog.

This point allows risks and measures to mitigate them to be planned from the outset. This makes it possible to react to emerging issues in Monitoring & Controlling at an early stage and then to plan for them or take measures accordingly. At the same time, it is also possible to refer to the risk log at the end and clearly show what may have occurred anyway and why.

Initial planning: With regard to the first planning, it is already very important that everyone knows when the respective activity is to be carried out by whom and with which dependencies. Here, absences, substitution arrangements and the like are to be discussed and planned accordingly.

Absences in particular are not always noted in the calendars of the stakeholders at an early stage. Sometimes the implementation of the project does not take place until next year or in a few months, which is why many have not yet thought about vacations at the time of project planning.

Assumptions: Documenting assumptions (e.g. in the project management plan), on which the initial planning is already based, helps to deal with changes to the original framework conditions from the very beginning and to show the contingencies.

Not absolutely every detail has been clarified by the time of the kick-off, or there are also points that "slip away" (since we are all only human, input can also be forgotten in prior agreements). The documentation helps to show, for example, the assumed effort or circumstances and also supports the coordination of timelines as well as the identification of different scenarios in the execution of the project.

Expectation management is a point which is not considered in project management theory. It is more about the interpersonal or organizational points that cannot be directly assigned to a deliverable. The topic of communication also plays a major role here. The central question to stakeholders is: "What are your general expectations of the project, the project team or the project management?

Some examples: The query of attendances, i.e. when the project team should be on site or also in which times the stakeholders expect an availability/response, the presentations of the status report or generally the preference of diagrams and/or text form as well as also the best communication channels. Do they always want to be in CC or prefer to be updated once bundled in a meeting? These are all expectations that can be queried and taken into account in advance, which in turn contributes to the success of the project.

Thus, in addition to the theory outlined above, the initialization phase is about talking to all stakeholders as far as possible, defining expectations from both sides, and making and documenting risks and assumptions in order to create a firm basis. In short, it's about defining the framework conditions as far as possible. This phase always reminds me of the saying, "There is no second chance for a first impression." Exactly the same applies in project management.

Author
Julia Heumos
Julia's consultancy focus lies on establishing effective organizations, developing high-performance teams and strengthening their results orientation. In doing so, she leads programs and projects to success and drives the digital transformation of her clients.