Central or decentralized implementation?

Implementation planning software: part 1
Central or decentralized implementation?

You have opted for new project & resource planning software. Now is the time for implementation. Just a matter of doing, right? Or maybe you should reconsider the approach? I will explain in a number of blogs what you have to make a decision on to make the implementation successful. Part 1: the central or decentralised implementation of your planning software.

For these blogs, I take the implementation of project & resource planning software (like Timewax) as an example. I differentiate between modules for planning, time registration, invoicing and reporting. It goes without saying that the principles in this blog are universally applicable for any kind of software.

Small and large businesses

Central or decentralized implementation: If you're a small business with 10 employees, then this is not a point to think about. By definition, the implementation will be a centralized implementation. In a company with multiple departments, whether or not distributed over multiple locations, this need not be that obvious.

Centralized implementation

With a central approach, you will set up the project & resource planning software according to one design. You assume that ‘one size fits all’ and this design you roll out to all departments.

This has advantages, because then you can work with standard software. This also simplifies reporting on group level, because all data can be aggregated according to the same structure.

The central implementation of the project will cost less money and makes the system more controllable. Finally, with a central approach, more thought also goes into processes between departments and what the impact of this is, for example, on the planning and reporting.

However, there are also disadvantages. Because you depart from a single design of the software, you will need more time to discuss this with all departments. It may therefore take longer before the first department can work with the software.

If there are differences between the needs at central level and what the department needs, it can also lead to resistance. In addition to the resistance, the involvement of all departments and their wishes in any case lead to a more complex project to manage.

Decentralized implementation

If you implement the project & resource planning software according to a decentralized approach, each department is 100% responsible for the implementation. There is little or no central coordination.

One advantage of a decentralized approach is that the first implementation can take place rapidly at low cost. It is also a relatively simple project and there will be little resistance from the department. After all, they get a free hand to use the software at their sole discretion.

For the departments, it will also be much faster in order to phase out old systems.

A disadvantage of a decentralized approach is that the software can be used by the departments in multiple ways. You end up with an inconsistent use of the system. It will therefore be more difficult to obtain aggregate reporting at group level.

With a decentralized approach, you also have less grip on the developments by department.


Choosing between a central implementation or by department is obviously not like choosing between black or white. There are many shades of gray. It depends on what the ambition level of the organization is to work as far as possible with one process and one system. This is also not an end in itself.

  • You can assess which approach best suits the organization on the basis of the following three business factors:
  • 1.  Structure and culture
  • 2.  Sales responsibility
  • 3.  Integration management

Business factors for a centralized or decentralized approach
Figure 1: Business factors for a centralized or decentralized approach

If a strong central structure and culture prevails, it will call for a central approach. This you often see in the organizational structure. If there is an extensive management structure with many staff departments, a central approach is more obvious.

The same applies to the extent to which a department is responsible for sales. As departments are more responsible for sales, they will also be able to have more say in their own costs. That gives them the autonomy to make their own decisions in things such as the purchase and use of software.

Finally, the degree of integration. If departments hardly cooperate with each other for customers, then a central system and therefore a central approach does not make much sense. With a lot of cooperation, a central approach is of great importance, because processes and systems should then ideally be matched.

Questions or comments regarding this blog? Contact Timewax.

Mark de Jong
Mark is Sales & Marketing Manager at Timewax. He has a background as a project and resource manager with PricewaterhouseCoopers Management Consultants with expertise in the field of Professional Service Automation (PSA)