Any project’s lifecycle — planetary model
Many people are now thinking about developing their own product, application, information system, or, talking in general, about implementing some project. The modern world not only encourages innovations but also eagerly demands them.
Custom solutions and projects are developed and implemented in any, even a small company. And although the development of any project by a team that understands the subject area is more or less painless, teams face specific difficulties at some stages. Moreover, the most inconspicuous and dangerous lie in organizing a project team rather than technical or domain-specific ones.
Such difficulties are based on the fact that different priorities are related to different project phases. The team focus should constantly shift. Because of that, it is crucial to identify the boundaries between the stages of the project and understand what “rules” operate on different ones so as not to act blindly and receive a result and not “experience.”
I tried to consolidate my experience of more than 50 projects from different areas over the past years. Moreover, many of them have not reached their end, which, if appropriately considered, makes this experience more valuable than successful ones. I tried to make these conclusions not subject-specific but more general, which will expand their area of applicability as I believe.
Planetary Model
I suggest considering the project as a planet. Each layer represents a separate phase of the project life cycle, with its own physic characteristics. Moreover, the boundaries of project phases are determined only logically, as layers of the planet. In practice, there is a particular “interference” of the rules operating at neighboring levels. This analogy and interpretation should help in understanding what I want to describe.
The key idea — The planet core
Just like the planets’, the project’s core is the place with the highest temperature. During the formation of the project idea, the “degree” of involvement and motivation of the project participants is the highest. Changes at this level are of low cost, and the speed of decisions made is very high.
However, these same characteristics are also the cause of one of the main dangers of this phase — the time trap. Many projects remained at the Idea level for so long that they simply burned out the energy from all participants and did not start. There are so many such projects that it is impossible to give even approximate statistics. Moreover, such an outcome harms not only the project itself. The negative impact extends to the entire company as a whole — the more projects that have not begun, the fewer participants who still believe in something. Thus, there is a general burnout of the company’s employees.
At this stage, among other things, it is essential to understand the following:
- A person who can make informed decisions about what to do and what not
and
- A person who will do what is necessary at any cost
… are either two different people, or one, but at two different periods. It is vital to separate these two activities as they are mutually exclusive. At this stage, it is more effective to focus only on identifying the main goals. You cannot burden the creative process with the difficulties of implementation. Based on my experience, for many tasks that seem unrealistic in the first place, solutions appear out of nowhere at the design and implementation stage. The main thing is to be sure that it is indispensable. Therefore, we focus only on what we need and not on how we achieve it.
At this stage, there is no need to think through all the little things. It is much more effective to define high-level expectations and define “success criteria.” These should be some objective indicators that can be measured and do not depend on someone’s mood. Moreover, within the first phase, there is no need to define specific values of these parameters, a certain level of approximation or even absence is expected. The main thing is to determine what exactly to measure.
The temperature of motivation will drop with each new phase as the project progresses. Therefore it will be highly beneficial if a consensus in understanding the project’s primary goals is reached by the whole team. One way to do that is to list all project features and the reasons they are included in a project. From one side, such a simple test will not pass empty ideas that only seem exciting and, in fact, do not bring any benefit. And secondly, in this way, you can enlist the team’s support for a long time if only everyone understands and agrees with why each part of the project is being done.
Project planning — The mantle
The design phase is often underestimated. It is difficult to “sell” project development costs to management because it looks like a waste of extra time = money. However, when executed correctly, this stage allows not only to contain costs but also, in some cases, to reduce them. It all depends only on how carefully the design (planning) is carried out.
However, it should also be noted that not all projects can be subject to detailed planning. Some can only be worked out at the top level. However, even this level of accuracy should not be neglected.
So, the first thing to focus on is to define the project’s boundaries. One of the biggest reasons for project failure is when a team tries to do everything at once. Then the project becomes unmanageable, leading to unpleasant consequences that extend beyond one project — to the entire company. At the idea stage, we determined what was included in the project, now it is time to outline what is not. I do not mean to literally describe the entire scope of work that will not be performed. I’m talking about defining the comprehensive scope project that clarifies what exactly will be implemented, avoiding the possibility of double interpretation and speculation on the scope of work. This will serve as a reference in controversial moments during the implementation phase.
You also need to understand that it is much more beneficial to get a small project earlier than a more extensive project but much much later. In my practice, there have been cases when the legislation covering the project scope was changing so often that it was impossible to carry out careful planning.
This concept is called MVP — a minimum viable product. The general idea of this approach is to include only those works that cannot be excluded and that are useful. It is essential to understand that the first launch of any project is already the most expensive from the organizational point of view. That is, for each project, even in a highly change-oriented environment, the second launch of the same amount of work would be significantly faster and cost less. Therefore, MVP allows you to minimize this negative effect while increasing the chances of success for the project as a whole.
The vast majority of project teams, especially beginners, suffer from that amount of unknown. They don’t know what to start from and how to build their process. As for me, whenever I got into situations with many unknowns, I started with what is known.
For example, in one project where we worked on the processes of a large terminal, we knew for sure only one primary production process. So, we visualized it in the form of a diagram. And when we interviewed representatives of business units, we showed this diagram and asked how their work affects this process, or is affected by this process. Thus, we understood where the work of other departments intersected with the primary process and built a comprehensive picture of the company’s process map.
You can start at least with a description of the project. Then, add what is already known. It may be existing processes or some kind of standards that cannot be avoided. As a result, you will get a picture showing the gaps in the project and which need to be clarified shortly.
It is crucial at this stage to have a picture of what could go wrong. For example, employees will not accept new requirements. Or, for instance, at some point, somebody will have to work in two information systems at the same time. All these risks should be collected in one place. Then they need to be completed with the information of the likeliness, possible impact, and what it depends on.
Such a list will make it possible to understand what amounts and funds need to be allocated for some possible events. But, most importantly, it will help draw up an action plan to prevent such situations. It will allow appointing a responsible person for each risk who will monitor the status and prevent harmful events. Again, from experience, it is much cheaper to prevent an incident in the overwhelming majority of cases.
As a priority at this stage, the team needs to focus on minimizing the blind spots for the project. That is, to reduce the degree of the unknown in the project. Chances are that some components of the idea will be revised at this stage. However, if the project turned in a completely different direction, there is a significant risk of failure of the project later since the participants “didn’t sign up for this.”
The expected outcome of this phase is an implementation plan. It should not only describe what work and how it will be carried out. The most important part of any plan is to outline what is expected of everyone and what each one is responsible for. Employees’ initiative should always be welcomed, but it is vital that the employee always understands his part in the whole project and sees the picture globally.
I would like to cite the study results, which have already become a rumor, but the message is still relevant. The study analyzed two construction companies for the reasons for the success of one of them. And it turned out that in a lagging company, for example, the bricklayers, when they were asked what they were doing, answered: — “We are laying bricks.” And in a successful company, the bricklayers answered: — “We are building a building.” Thus, the key to the project’s success is when all participants see the global picture.
Project’s implementation — The crust
By analogy with the planet’s crust, the implementation of the project is the place where the temperature is significantly lower (that is, motivation). It is also in a more solid state, meaning that the changes are more critical. And, perhaps most importantly, it is this part located in the harshest environment — the project begins to be criticized from outside.
Resistance to change — when employees whose processes are affected during projects has been and always will be. Nevertheless, it is also essential to understand that employees go to the other extreme as soon the point of resistance is passed. They begin to add work to the project — to find new ways to optimize and improve. In general, they go way beyond the agreed-upon scope of the project. We call this effect — “Appetite comes with eating.”
Considering that not everyone participates in the project and understands its scope, therefore is not guided by the MVP principles, this “appetite” creates pressure on the project team from other employees. This pressure needs to be taken away from the project team, for instance — by setting up a “Proposal Journal” or even developing an appropriate process.
One of the hidden dangers at the stage of project implementation, despite its controversy, is the team’s unwillingness to complete the project. Often, especially for beginners, a subconscious fear is formed, which prevents them from taking steps towards the project’s closure. In addition to what was described in the previous paragraph, a situation may well develop when some do not want to end, and others are afraid of it.
The visualizing tools for the project’s progress may come in handy for this. Some kind of diagram depicting the progress against the timeline. Along with direct question about steps need to be done in terms of closure asked regularly.
Another thing, which is not obvious is that the end of the whole work is not the project’s launch date. What it really is — is the end of a period of the project’s support. Yes, regardless of whether you are implementing changes to operational activities or a new application for customers, you have to guide all changes for some time. Even if you work out the guidelines and instructions in detail, people will still have questions that need to be answered and situations in which they need help.
Not everything new is caught by everyone immediately. Each person is different in the way that they tolerate changes in day-to-day activities. Therefore, someone will need help, and someone will try to sabotage the changes. All you need is to be ready for this in advance.
At the end of this phase, you need to review the goals and reasons set at the beginning of the project to determine the project’s overall success. It may not be one hundred percent. In such a case, if the project plans to develop further, the unattainable goals must be recalled again for the next iteration, having previously analyzed the reasons for the failure. Nevertheless, even in this case, the project (or this iteration) is considered complete. Since it is harmful to make it a norm that some projects are hanging for an unlimited time. Such gestalts prevent the project team from fully working on the following tasks.
Interpretation of the result — The atmosphere
Even though the project has already been launched and is working, the work has not yet been completed. There still is another very important stage, which in most cases is ignored.
The last layer of the planet is the atmosphere. For a project, this is the interpretation phase. Here, as during the transition between other layers, the project team’s focus changes significantly. During interpretation, all that remains is to observe how the results of your project are actually used.
It is essential to understand that no matter how much time you spend on the development and design of the project, its results will always be used by employees or clients as it is more convenient and profitable for them. For example, if you introduced any new processes or tools to control work discipline during the project, they will try to hack them and use loopholes for their own purposes. This does not always have a negative connotation — sometimes, people just try to make their work easier.
Another thing to understand is that “not everything you implement will be used.” For example, in applications, about 50% of functions are rarely used or not used at all. This is often due to the interface’s inconvenience or unclear where or how to use it. The same is with the processes — some are simply stopped being used because they are too bureaucratic.
In the end, all that remains is to observe how the results of your project pass the reality test. It is necessary to identify the reasons for the misinterpretation, draw conclusions, and document them for use in the next iteration or in another project.
Project management is an example of extraordinary activity. It is impossible to prescribe any template rules applicable to all projects. However, there are many similarities between an application development project and, for example, an enterprise restructuring project. It is very important to understand what pitfalls are there at each stage.
The proper mindset of the project team allows to successfully adapt to changes in the environment during the transition from one phase to the next and focus on what is really relevant and practical at each moment in time. This not only allows to increase the chances of a single project for success. It also increases the confidence level with which the company will face new challenges in the modern world.
