Implementation planning software: part 1.
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 three blogs what you have to decide on to make the implementation successful. This blog post is part 1 of this series: the central or decentralized implementation of your planning software.
For these blogs, I take the implementation of project and resource planning software (like Timewax) as an example. I differentiate between modules for planning, time registration, invoicing and reporting. The principles in this blog are universally applicable for any software.
Small and large businesses
Central or decentralized implementation: If you’re a small business with ten employees, then you don’t have to worry about this. By definition, the deployment will be a centralized one. In a company with multiple departments, whether or not distributed over various locations, this need not be that obvious.
With a central approach, you will set up the project and resource planning software according to one design. You assume that ‘one size fits all’ and you roll out this design to all departments.
This approach has advantages because then you can work with standard software. This approach also simplifies reporting on a group level, because you can aggregate all data according to the same structure.
The central implementation of the project will cost less money and makes the system more controllable. With a central approach, more thought has to go into the processes between departments. You need to know what the impact of the plan is on, for example, 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 the 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 leads to a more complex project for you to manage.
If you implement the project and resource planning software according to a decentralized approach, each department is one-hundred per cent responsible for the implementation of the software. 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 easier and faster to phase out old systems.
A disadvantage of a decentralized approach is that departments can use the software in multiple ways. You end up with inconsistent use of the system. The inconsistency will make it more challenging to obtain aggregate reporting at a group level. With a decentralized approach, you also have less grip on the development of the departments.
Choosing between a central implementation of the planning software or implementing it per department is not like choosing between black or white. There are many shades of grey. It depends on the organisations level of ambition to work with one process and one system. This is also not an end in itself.
You can assess which approach best suits the organisation based on the following three business factors:
If a strong central structure and culture need to prevail, it will call for a central approach. This you often see in the organisational structure. If there is an extensive management structure with many staff departments, a centralised approach is the best choice.
The same applies to the extent to which a department is responsible for sales. As departments are more accountable for the sales results, they will also be able to have more say in their costs. That gives them the autonomy to make their own decisions, such as the purchase and use of the software.
Finally, we look at the degree of integration. If departments hardly cooperate with each other, then a central system and a centralized approach do not make much sense. With a lot of cooperation between departments, a centralized approach is of great importance, because then you should match processes and systems.