When does a project require recovery?
Here we are talking about specific situations that have emerged during the implementation of a project:
- The lack of a holistic vision of the whole solution and unclear or inconsistent requirements.
- Scheduling issues (unrealistic or too optimistic a schedule).
- Planning based on the absence of key information and elements or wrong estimations.
- Resource shortages (excessive resource usage, impossibility of their effective allocation, lack of competence on the resource level).
- Incomplete or missing management of project risks and threats.
These problems may occur in management and expertise areas. While project management issues are usually easy to solve, expertise issues are often a very challenging situation.
Let us take, for example, the internationalisation of the project – the project complexity level increases in countries east of the Oder and south of the Alps. The diversification of markets grows and if companies fail to adopt certain standards at the beginning, it may turn out that an implemented project does not meet the company’s business assumptions and generates much trouble, – says Remigiusz Efinowicz – Executive Director International Sales and Managing Partner at Hicron.
The project is failing
Now imagine that the customer is carrying out a project, but all indexes, including KPI, show that both budget plans and the schedule have been exceeded. The project is suspended. We had a case like this with one of our customers from the DACH region. The customer and the consulting company got stuck on the level of creation of the facility management conception. The solution was ineffective, and invoicing processes lasted around two weeks. The customer looked for a solution to this problem. The consulting company tried to help, but it lacked enough competence to go beyond the ordinary standard of the ERP system. To sum up, the solution was implemented, but it was extremely ineffective.
We were invited to co-operate in solving this issue. We looked at the main goals determined by the customer and proposed an alternative solution that would be fully based on the already implemented modules of the system. Our method allowed the customer to focus on business, not on the structure of the system. It took us one month to improve the conception on which the customer had been working for a year. – says Remigiusz Efinowicz.
During the following 7 months, Hicron implemented a full solution that automated users’ work to a considerable extent and contributed to the accomplishment of the customer’s business goals:
- reduction of the invoicing period from 2 weeks to 12 hours,
- decrease of the number of persons serving the specific area from 8 to 3.
To sum up, the customer achieved its business goals on the basis of the same ERP solution. The original supplier specialised in the standard approach to business process management, but it lacked the courage and knowledge how to go beyond the familiar solution and, relying on the existing infrastructure, to propose an innovation based on the same ERP system.
The project failed
And another situation – an international customer from distant Asia. A standard solution was implemented but the required expertise base was not taken into account, which resulted in the lack of preparation for its implementation on diversified markets. The implementation approach did not consider:
- the standardisation of basic processes,
- the flexibility of processes in regard to regional requirements (e.g. legislative issues in specific countries).
These two points are often perceived as contradictory; consequently, being anxious about excessive complications, companies try to simplify everything and build a solution that is hardly useful on diversified markets. This is because end-users are dissatisfied with the way in which the system supports their operations – says Efinowicz.
In the described situation, it is necessary to stabilise such a system, to remove the biggest problems and, ultimately, to reengineer the solution. This last part is important because enterprise resource management systems are tools that should be updated in line with ongoing market changes in the area concerned.
It is also worth noting that in the digitalisation process changes are expected to be implemented as quickly as possible in the context of business processes and growing competition. The reengineering of the project supports the reduction of the cycle of changes in the field of company operations.
It costs too much
It also happens that a recovery project is started because of excessive costs of implementation of a solution onto various markets (rollouts). A change of perspective regarding the transition of requirements to new areas requires a consulting approach. We can quote the example of a company that performed many different international implementations of its system. Having exceeded the budget and deadlines in the USA to a large extent, they asked Hicron whether it was possible to elaborate a new approach with regard to projects of this kind. The overriding goal was to accelerate the rollout process and to lower costs.
In this situation, we were not an implementation partner; we did not implement any software, we provided only consulting support. The problem was solved in co-operation with the program management. – recalls Remigiusz Efinowicz.
It turned out that key aspects were the management of requirements for new markets and the solution of the problem involving the exceeded implementation deadlines. In such situations, it is necessary to divide project requirements into two groups:
- legislative requirements – related to the economic & legal system of the given area.
- functional requirements – related to customs and cultural characteristics of the given region.
It is worth remembering that in such a situation a conflict may arise between the owner of the central system and the entity being a part of the organisation. The subsidiary company usually tries to preserve its methods of functioning that the main organisation is trying to standardise.
Our proposal was to implement legal requirements in the first place; as far as others are concerned, we recommended putting them on the list of functional requirements that will be managed by a central managing body appointed specially for that purpose. This will help to select and implement the best practices applied both by the main company and the subsidiary. Another proposal was to create accelerators and tools helping to implement IT solutions on new markets, such as documentation templates. The third aspect that we proposed was a change in the approach to rollouts. Here, the idea was to treat certain markets as clusters showing certain legislative, geographical or cultural similarities and to put these clusters into operation at the same time. As a result of this approach, single markets are no longer a challenge and do not involve extra costs. – adds Efinowicz.
Accelerators supporting the systematisation of projects
In a situation when we are forced to reengineer the implemented solution, we rely on our own accelerators that help us to carry out such projects. They systematise and ensure quality by imposing an implementation standard. They help us and our customers avoid many problems during implementations. – says Remigiusz Efinowicz.
Accelerators were created because each person engaged in the implementation (consultants, programmers, PMs) has his/her individual approach. Taking the holistic picture of the solution into account, individualism has a negative impact on the project. Accelerators enforce a certain method of implementation, and all users applying it carry out a consistent implementation process in all of its aspects. It also ultimately allows the company to reduce servicing costs because all of its elements are performed on the basis of the same assumptions and standards.
Ensure support
The maintenance of the implemented solution has a very significant impact not only on the current operation of the enterprise, but also on its future. Even if implemented in the best possible manner, a solution that will not be developed properly may become much less flexible in the course of time. We are often also dealing with this situation at the moment of making a decision to expand business activity into new markets, when this turns out to be impossible on the basis of the system in use.
