Tooling in a project organisation

Good adoption makes the difference!

Project management and “tools” are often associated with each other, where the expectation is that one strengthens the other. However, you regularly see ingenious tooling that is not fully adopted and that, instead of simplifying the work, is more likely to generate resistance from project managers. How is it possible that these tools usually lead to the feeling of additional red tape instead of actually making the work more efficient?

A project management tool should be seen as a means and not a goal in itself. The tools are intended to contribute to improving the execution and implementation of projects, and could even provide predictive capabilities. The question is whether this goal will actually be achieved.

Taking change management into account

Unfortunately, our experience shows that this goal is not always achieved. For example, one of our customers, a corporate, works widely with ServiceNow.

This is a very comprehensive tool for project portfolio management that can also be used well in agile work environments. Despite the fact that the tool generates advanced reports and it is easy to prioritize and track projects, the organization is unable to utilize its full potential. How could this be improved? We believe that more can be gained from the tool if a solid plan of action is drawn up for implementation, taking into account change management in particular. Because it’s precisely the attention paid on implementation that ensures benefits of tooling will be fully utilized.

For example, in digital HR transformations, we see that in the implementation and rollout of an HR system such as Workday or Successfactors, for example, a lot of attention is paid to change management. Often a separate workflow is set up that focuses specifically on change and communication, with a clear policy regarding the adoption of the system. What are the benefits of the system? What are the changes to the way of working? What resistance can be expected? Even though these are large and complex processes, we believe that the principle remains the same. As simple as the tool is to use, if you don’t pay attention to the implementation and full adoption of the tool within the project organization, it will never achieve its goal. This change, whether or not on a small scale, ultimately requires the same change management steps and must therefore be approached in the same way.

What does such a rollout look like?

When rolling out a tool, it is important to consider what people want to achieve with the tool. What is the goal? What benefits do you expect to achieve and how does this tie in with the organizational objectives? In this it is also important to clearly describe the to-be situation. ServiceNow, for example, has many options, but not all options should be used immediately. When introducing a tool, you can gradually build up change consumption. By first arranging the basics, and adding on more advanced options in a later stage you offer a more gradual change approach and ensure end users are not immediately overwhelmed.

When did you realize a successful adoption?

  • If the new processes, procedures and ways of working are fully anchored in the project organization;
  • If clear governance around the tool has been set up;
  • If one has full ownership and control over the tool;

If the tool is used by the end user in a way that contributes to the objective (eg the tool leads to more efficient work, more standardization, etc.).

A different way of working therefore requires communication, support and training so that the tool is properly implemented and adopted. Given that the Project Management Office (PMO) in particular is responsible for standardizing and supporting governance and reporting, it is therefore up to them as the owner of the tool to help the project managers and other end users with the adoption. They must “sell” the tool as an ambassador by highlighting the positive sides and, where necessary, provide support by answering questions.

A new tool therefore does not automatically simplify the management of a project. As our experience shows, this also requires a change process in which the project managers must be included in order to guarantee full adoption. Ultimately, the project manager must also be managed, where he or she learns to understand the new way of working so that the tool can deliver the value it was ultimately intended for.