In our teams in Reaktor, there are a lot of cases where a person might have enjoyed a project at some point, but doesn’t enjoy it anymore for example six months or twelve months later. It seemed that a project that had started as a great, fun adventure often turned into a boring grind, chaotic circus or meaningless chase of the next shiny thing.
For some reason though, the same isn’t true for everyone in the same team at the same time. Quite contrary, some people might have not enjoyed the project that had felt like unclear mess in the beginning, but now when the first version was out, ensuring quality, responding to customer needs and scaling the capacity up started to feel meaningful and fulfilling to them.
We realized that there are very different phases to a project lifecycle, and therefore there are also differences in which phase suits the personality, style, values and needs of different people.
Understanding different needs in different phases of the project has increased the happiness of people participating the project, as we are able to find better project matches to different personalities. Realizing that there has been a shift in the project phase helps to accept why the work feels different than before.
We created a model of different project phases to emphasize this and started to use it in discussions about what is currently needed in a specific project.
We call the model “The lifecycle of a project”.
Lifecycle consists of six distinct phases, with different types of tasks, different types of goals, and different requirements regarding e.g. quality.
The curves in the diagram describe different teams in the same project. At least in our case, there were couple of key points in the lifecycle that co-incided with lot of changes to the project personnel. First one was when moving from MVP to industrial phase, and another one when shifting from stable to maintenance phase.
Below are the descriptions of each phase as we saw them.
Entry Phase
Goal in this phase: unknown
Entry phase is when we start to look for a project. What is the goal? What could be done in this area? Is here some potential value?
This phase requires creating ideas, looking for values, creating concepts, doing early drafts. It’s well suited for pioneer-type of personalities who enjoy finding something completely novel.
Case example: an airline company thinks that the inflight entertainment (IFE) systems on planes could be better, but it’s unclear how. A concept designer and a business designer are assigned to investigate the possibilities.
MVP Phase
Goal in this phase: clear and specific
MVP (Minimum Viable Product) phase is when we have decided on the project and assign a team to produce the first working version to be released. Goal is set, usually boundaries like budget and schedule are known and some kind of a deadline exists.
This is a greenfield type of phase, where people get to create new stuff. Often there are not yet existing customers and sometimes no previous version of the product or service, so the dependencies are minimal. This is a great phase for people who want to be in a tight knit team focusing on a single goal, fast moving work with still lot of unknown and things to find out. Lot of experimenting, crafting prototypes, testing and piloting stuff. Quality needs to be sufficient, but it doesn’t make sense to produce too good quality either, because it would go to waste if the proto/pilot would ultimately be tossed away.
Case example: the airline company decides that completely new IFE system will be made from scratch, and installed to a single airplane for a try-out. A team of coders, ux designer, visual designer and hw engineers are given the task to create and implement it.
Industrial Phase
Goal in this phase: multiple goals of different nature
In Industrial phase the product or service is running and used by first customers. More features are needed, quality needs to be improved, bugs need to be fixed, customer requests need to be answered and service needs to be scaled up to serve more customers. Finding new users and customers is often one focus area.
This phase of a project is usually the most fuzzy. There are lots of different kinds of tasks to do; still lots of feature building and improving the usability of the product, but also lot of non-functional stuff: working on scalability, ensuring robustness, paying back some technical debt e.g. in form of code quality, fixing smaller and bigger bugs, working on customer requests. Sometimes a decision is needed, will we continue on the MVP version, or do we need to for example for quality reasons to replace the initial version with one built again from scratch. This phase requires different types of personalities, and finding a right type of role for them. Some like interacting with clients, some like the challenge of scalability and stability, some prefer focusing on creating new features.
Case example: IFE works on one plane, so now we need to figure out how it will be updated with new features, and how it will be installed to and maintained in 300 other planes. Improvements need to be made and remaining features that were left out from MVP need to be done. More people with different skills are added to the project.
Stable Phase
Goal in this phase: multiple minor goals, no goal at all or unclear what the goal is
In stable phase, things are not moving so much anymore. Major problems are solved, product or service runs mostly smoothly, there are more existing than incoming users or customers. It’s difficult to find a single, meaningful big goal to aim for and instead the targets are smaller and often very practical in nature (e.g. lower the number of bugs or reduce the response time to customer requests).
This phase feels quiet and even boring compared to all the previous phases. The hustle and bustle has slowed down and the pressure of deadlines has eased. There are no major problems left to solve anymore, and work has found its steady 9-to-5 type of predictable rhythm. Same core skills of product development are still needed as before, but challenges are not necessarily so intriguing anymore. There are still some further improvements to make, but mostly the focus is in running operations smoothly. Typically some kind of an organizational hand-over happens in this phase, for example moving the product from responsibility of an R&D organization to an IT or operations organization. This phase suits people who prefer steady and predictable work environment to exciting and unknown.
Case example: The new IFE system is now installed in the whole airplane fleet. Occasional bugs need to be fixed, and additions to contents of IFE managed. New people need to be educated to maintain and update the system, so that the original R&D team can focus on next new project.
Maintenance phase
Goal: Reducing costs, ramping down
In maintenance phase, not much new stuff is done anymore. New version of the product might already be on its way, user base might be shrinking and it doesn’t make sense to invest in the product or service a lot anymore.
In this phase, the goal is to keep the thing running with the minimum effort and only fix the most critical problems. Usually there are some specialists that can still be alerted to work on the product, but it’s mostly in the hands of a maintenance or operations team that takes care of several products in similar phase. Nature of work is similar to stable phase.
Case example: the IFE system has run it’s course, and new hardware and software are being developed. Content is still updated, but new versions are only brought in if something breaks.
Exit phase
Goal: Removing product or service from use
In exit phase, it’s about replacing the product or service with the new one or just removing it completely. Some clean up is needed, customers need to be informed, and some kind of a readiness for unexpected consequences needs to be in place.
Case example: installations of new IFE system have started, engineers are installing them and getting rid of the old one. Maintenance team is still answering the needs of those planes that still have the old system.
Summary
It makes sense to understand in which lifecycle phase the project is and when is it moving to a new phase. It helps to understand the ensuing shift in the mood of the project and to respond to the turbulence it causes for the project and it’s participants. Better managing of the lifecycle phase shifts leads to better results and to happier people.
Coach Jarkko 