Key to successful project management: closing the loop

Chris Dippenaar

What I realised though, is that carpentry is not that different to project management, my day job. Over the years as a project manager and consultant, working in SAP implementations, I've realised how important it is to remember that the software is a means to an end. It is merely intended to solve a business challenge or requirement. Once it is implemented the project teams change from implementation to the support of the software, before business analysts finally step in and provide results through benefits realisation.

In the past I have relied on six key steps during project implementation, however, as I've compared SAP implementation to carpentry projects it has become apparent that there is one essential step that is often missing or ignored. These first six steps include initiation, planning, design, building, testing, and 'go-live'. The missing step, though, is what I like to call 'closing the loop,' or benefits realisation, and is sorely needed to close a project.

This missing step is, more often than not, the reason why the rewards of a successfully implemented project are seldom felt by the project management team. Other reasons include the fact that the results are only seen months after the implementation is complete, which means that the team leading the project leave the job with a sense of it never being fully complete, and little sense of achievement. Consequently, they probably will never know if the implementation was a complete success.

Before delving into this final phase and why it is so important to the conclusion of every project, though, let's explore what each step of Enterprise Resource Planning (ERP) or other software application implementation projects are.

Initiation

During the first step of an ERP project, we create a project charter which captures the requirements accurately, defines how the project goal aligns with the business goal, documents the benefits, and establishes a high-level cost estimate.

Planning

The next step includes creating a scope statement of what will be delivered and when. For an ERP project, we create a detailed project plan breaking down work packages, assigning resources and determining the cost of the project.

Design

During an ERP project, a detailed design of the proposed solution is created. This includes process flows of 'to-be' processes, detailed functional descriptions of functionality shortcomings and how it will be addressed for reports and system functions and the 'to-be' state of access to specific functions.

Building

With an ERP project, the components are put together and the finishing applied. Of course for an ERP project, these components are put together into a comprehensive and integrated build of the solution and access roles are built according to the access restrictions stipulated in the design step.

Testing

The testing phase allows us to prove that the design meets the intended requirement. For an IT project the individual components and the integrated solution, as well as the interfaces to other systems, are tested while the 'to-be' state access restrictions and other constraints are applied in a simulated environment.

Go-live

This step involves deploying the 'to-be' solution as an operational solution to perform its intended business processes and functions. During this time, all anomalies picked up during normal operation will be addressed by a support team established during the course of the project.

This would usually be the final phase in an ERP project before the project team steps away and support team steps in. Often this is because the team contracted to establish the solution will leave after the successful 'go-live' of the solution. Another reason is that the organisation requesting the service from a consulting service provider might prefer to take this step in-house, sometimes to reduce costs.

geralt via pixabay.com

The missing step

More often than not, project teams don't get the opportunity to see the project through to its results phase. This is because a support team is put in place to manage the smooth running of the day-to-day activities, and finally, business analysts are brought in to assess and show the results of the project's implementation. At the end of the project, only the business objectives and challenges will be supported.

This is an emotive point if you derive satisfaction from your work and is not something you face when completing a carpentry project, where the benefit is realised immediately. The reality is that benefits management should be treated as a stream of work within the project and follow a process of identification, definition, planning, and realisation.

Benefits management as a stream of work

The quantitative and qualitative benefits captured in the project charter (from step 1) should form the basis of a benefits scorecard. Any project should have a critical mass of quantitative benefits since these add credibility to the project. Qualitative benefits are good to mention, however, these do not help in selling the project to a sponsor.

During the definition phase, each benefit is baselined against current measurement and the improvement which wants to be obtained in the project, as well as how this will be measured is defined. In addition, during this phase, the timing of when the benefit is judged to be realised and what capabilities have to be put in place to deliver on the benefit, as well as what the KPIs and KPAs of the benefit are, who will be responsible for delivery of the benefit, and if any, what are the dependencies between benefits will also be defined.

The planning phase is where the benefit is aligned to the deliverables of the project. During this phase care must be taken to include benefits management as a possible area of impact, should changes arise during the course of the project.

During the realisation phase the changes are embedded and become the new 'business as usual'. It is more than just merely producing the deliverables of the project, it is measuring on a continuous basis if the perceived benefit is actually realised and keeps on being realised.

As we can see, this final step is necessary to the conclusion of a project. Not only does it provide the team with a sense of achievement, but it also serves to highlight the successes and provides crucial learning points for the next area of improvement.