Implementation of PMS: Choose Projects and Select Managers

This article will discuss how to properly approach project management system software (PMS) implementation and roll-out. Before go live of a PMS, it’s testing on specific projects is necessary. General requirements for configuration and processes will not be enough here. To better adapt the developed software solutions, it is crucial to understand in detail the structure and algorithms of management processes, which is possible only concerning a specific project and when several managers are included in the team.

But let’s go in one by one order.

Formation of the Project?Team

Through trial and error, I concluded that the optimal implementation of a project management software solution would be the presence of two or three managers (and two or three projects, respectively). Taking less than two project managers into the team will increase the risks because managers can leave the company at any time or simply move to another position. Plus, there is a high probability that one of them will not be active enough. This can be disastrous for the project: enthusiasts who will promote the software solutions implemented on the pilots are needed here.

However, it is essential not to exaggerate the number of project managers. If there are more of them than I indicated above, this will increase the complexity of implementing PMS. It will be more challenging to agree on schedules, and the number of questions on the project that require in detail analysis will increase. But we remember that to achieve the project’s goals, it is necessary to develop a standard, universal solution.

And do not forget one crucial thing: if the project goes beyond the schedule and becomes too specific, the rest of the team may lose interest in it and motivation. What are the risks associated with it? I think it is not necessary to explain.

Selecting a Project?Manager

The main criterion for choosing a project manager is his general interest in implementing PMS. The manager must be loyal to the idea of introducing innovations. It’s terrible if the project manager perceives them as an additional burden. But if he had previously tried to set up a project management system, for example, using Excel tables, I think this is the candidate you need.

A good manager should generally understand project management and, use it in practice, be open and flexible. A person who cannot perceive someone else’s opinion will not fit here.

What else? Your manager should not be overloaded. Otherwise, it is possible that the PMS will not be used, to its full potential, as the project manager will drop out of regular meetings (usually one or two meetings per week).

It is better to make the project manager someone who has worked in the company for at least two years. Such a person understands business processes from the inside, clearly sees their details, and feels confident in the role of a manager.

It is crucial to choose the appropriate models if you have projects of different types (for example, integration, service, etc.). It is necessary to exclude cases in which managers with different specializations get projects of the same kind. This is done to be more widespread and accounts for all types of projects.

Project Selection

The first thing to look at when choosing a project is at what stage of implementation the project is currently in. The project’s initial phase is unsuitable since the basic processes have not yet been debugged. At the very beginning, the workflows on the project are not yet too structured and focused on immersion in the process, not on control and execution. It is difficult to put such a project into a software management system; it still lacks content and information. It isn’t easy to test the capabilities of the system on it since its primary function is most fully revealed at the stages of detailed planning and implementation.

Projects at the final stage (no more than two months before completion) will also not work, and here’s why. Suppose the project you are taking as a pilot ends before implementing your project management software solution. In that case, the motivation of the project manager will be shallow. He simply does not have time to implement most of the changes. Therefore, choose such a project, so there is enough time to implement PMS.

The stage of designing and configuring a project management software system before launching usually takes two to three months, so you should look for a project at least five months from completion.

The best option would be the first third or the middle of the project implementation. At this stage, it is already structured, the ways of its implementation are clear, and the project has formulated goals. In the later stages of implementation, for this reason, conflicts between processes, tools, and management approaches may occur, which will slow down the implementation.

At an early stage of the project implementation, its project management structure is formed; for example, it is determined how minutes of meeting are written, how meetings are organized and held, and what tools are used. The PMS must be organically combined with the project team’s work culture.

Do not forget to consider the time of work with the project’s specifics: setting up systems and processes and testing take one to two months. Only then can we say that the project has moved into production mode. With insufficient project duration, there is practically no real operational work on new processes and tools. This is reflected in the degree of involvement of team members, the level of attention, the quality of data preparation, the readiness to analyze project materials in detail, and the quality of requirements development.

It is essential that in a PMS implementation team, the specialization of the team members is similar to the specifics of the project. And this is where it gets interesting. On the one hand, we are tasked with creating a typical project management software system model, which can subsequently be extended to all portfolio projects. On the other hand, the first projects in which PMS will be implemented must be adapted to it as much as possible. They will only become good examples we can distribute and show to the public.

At the same time, there is always a risk that the PMS model, which is optimal for a particular project, will not be suitable for another, with its specifics. Therefore, when choosing a project, we need to pay attention to the fact that it has certain typical features. Namely:

• the presence of a contractor;
• the presence of an internal team;
• have at least one customer.

What else? The project does not have to be significant. Otherwise, it will be tough to change it to suit the requirements. And in general, it will be challenging to cover the entire project. Moreover, it is likely that large-scale projects usually already have their specifics and, often, their project management software system.

It is also worth avoiding reputational projects, that is, those with respected leaders who are not ready to change their management approaches. For project managers of such projects, the unwillingness to comply with specific rules, requirements, and use of PMS often comes to the fore. At the same time, they always argue about why it is not necessary to do this. For example, they report directly to the manager or owner.

It is essential to separate the project’s reputation from the reputation of the PMS because if the implemented software system is not used for its primary purpose, its reputation may suffer.

Also, do not take projects being implemented at a forced pace. A project manager rarely has enough free time. And the implementation of PMS just makes him pay more attention to the project. For example, the implementation of the system may require a revision of the project plan, the formation of project documentation, a project passport, etc.

When implementing PMS at an accelerated pace, conflict situations may arise with the project manager; he may not be sufficiently involved, working exclusively at meetings. All this leads to a delay in the project. Plus, there is always the risk that the project manager will blame the system for an unsatisfactory result.

It would help if you did not take on minor projects that do not have a clearly defined importance for the management of the unit or the company as a whole. Such projects are often not the focus of attention and are poorly controlled. Because of this, it is more challenging to show the effectiveness and quality of the result of the software system and thereby achieve recognition of the system. This may also lead to certain reputational risks for PMS.

Conclusion

So let’s sum it up. There is a risk that a model will work well for a particular project but may not work well for others. To avoid this, it is necessary to choose standard projects, that is, those that contain similar specifics for most projects in the company. Not the best option would be to select exotic projects, overly complex, or with respected leaders. Such leaders are usually not flexible and will defend their opinion at any cost.

Thus, projects and managers are selected simultaneously: a project cannot be chosen without understanding the identity of the project manager.

On the one hand, our main task is to develop a basic project management model that can be extended to all portfolio projects. And on the other hand, we must ensure that in the first projects, the software system is maximally adapted to the specifics of the project, like a suit tailored to the detailed parameters of a particular person. The first projects are those cases that will be distributed further as exhibition samples. Therefore, “adaptation” to the project must be perfect. In the first projects, much more specifics are taken into account than in subsequent ones, which follow the pattern.

To manage project changes, it is essential to show that the developed model fits perfectly, the software system works, and project managers support and actively use it.