Home › Downloads › Moving to project mode: seven steps, in order
Many companies say they work in project mode. Fewer are aware of what that mode requires: who decides, who arbitrates, where the information lives. Here are the seven steps we follow, in the order in which they matter.
Project mode brings together, around a shared objective, people from different professions and departments. Done well, it breaks down silos and engages teams. Done badly, it adds meetings to an organisation that has not changed. The difference almost always comes down to the order in which the steps were taken.
1. Start from the core businesses, not the organisation chart
The first step is to analyse the core businesses and skills that keep the company running. The organisation chart will come afterwards. Take a young company whose headcount grew from six to around fifty people in a few years. It had created various departments as it grew: sales, technical, IT… As it developed, it responded to customer requests without asking what its real core businesses were. The analysis revealed two main core businesses, software publishing and integration, and made it possible to redesign the departments. Refocused on these points, the organisation chart became compatible with project mode.
2. Write down the roles, especially the temporary ones
A permanent position is fairly easy to describe. A temporary function, such as project manager, much less so. For each one, you need to write down who the person reports to, what they must achieve and how they communicate with their line management. Four roles carry most of the weight. The department head manages the workload and skills of their team. The sponsor appoints the project managers. The project manager runs the project day to day and is accountable for the conformity of the result. The coordinator manages the project portfolio, sets priorities and arbitrates conflicts between project managers and department heads.
Then comes staffing, the most delicate step: a manager who feels downgraded will hold everything else back. Human resources must be involved from the outset.
3. Identify resistance before it sets in
Every level has its objections. The department head refuses to let anyone look into their department. The project manager doubts that the teams can work together. Staff no longer know whether to follow their manager or their project manager. Only a precise inventory of this resistance makes it possible to prepare the answers. The enthusiastic move forward as soon as they have a roadmap. The indifferent need to see what they gain from it, the fearful to see that the method frames the effort rather than adding to it. From opponents, ask for solutions. Once convinced, they often become the best champions of change. Change management starts at the launch of the project.
4. Put all projects in a single portfolio
The idea is to list current and upcoming projects, then apply the same rules to all of them. Many departmental activities lend themselves to it: a marketing campaign, a response to a tender, a software roll-out. Then comes the rule that prevents daily conflicts. The same person often works both for their department and for a project. When a departmental task is critical, a month-end close for example, it takes priority, then the person returns to their project tasks. Written down once and for all, this rule no longer has to be justified every time.
5. Build a shared project culture
This culture rests on six principles: a common vocabulary, a common project management method, trained teams, standard documents such as the specifications, shared tracking tools and standard reporting. They only work together: anyone can then move from one project to another without relearning the rules.
6. Share the documentation
Documentation for all projects goes into a shared space, with a standard filing structure and a template for each stage. This is often the least popular step. In the young company from step 1, some people initially refused to share their documents. Introducing ready-to-use templates and being able to find everything in one place won most of them over. For the rest, a check of the files left on individual workstations was enough.
7. Choose the tool on how it will be used
A project management tool should be judged first on three uses. The project manager must see the phases, the tasks and the people assigned, whatever their department. The department head must see everyone’s workload, across all projects. Everyone must be able to store and find project documents in one place. Messaging, shared calendars, dashboards and timesheets come next, depending on the context. A feature-rich tool that nobody uses delivers nothing: better a simple tool that the whole team adopts.
Why this order
The first three steps concern the organisation and the people, the next four the rules and the tools. Starting with the tool remains the most common temptation. It is also the most costly: without written roles or an arbitration rule, the tool only makes visible conflicts that nobody has the authority to resolve.
This article updates a document published in 2017, itself drawn from the book “Manager par les projets” by Jacques Nicolle and Vincent Protat, co-founders of NetsFive, and the lawyer Jean-Jacques Raynel.
Published by NetsFive.