In my spare time I enjoy working with my hands, specifically doing some carpentry. I enjoy the physicality, the tangible nature of the outcome. Or rather, the sense of achievement when I see the final product and experience the benefits of my labour and handiwork.
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 support of the software, before, finally, business analysts 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 look at each step, exploring how alike carpentry and Enterprise Resource Planning (ERP) or other software application implementation projects are.
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.
Similarly, a high level project plan is drawn up when creating a carpentry object, including a preliminary sketch, a defined understanding of the object’s purpose, and a cost estimate.
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. Likewise, in the planning step of a carpentry object, I have to make sure the high level design meets the requirement, define in more detail how the object will be produced, and refine the cost estimate.
The design phase of a carpentry project involves documenting the details, including the dimensions and size and exact specification of screws, wood, and other fasteners.
During an ERP project a detail 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.
During the building phase of a carpentry project the design is converted to the physical object. Just like 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.
The testing phase allows us to prove that the design meets the intended requirement. For the carpentry project this would include using it for its intended purpose, while 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.
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. Or, in other words (for a carpentry project) the object is put to use and at long last family and friends use, observe, and comment on the object.
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.
7. 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.
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 base-lined 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 are the KPIs and KPAs of the benefit, 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.
By: Chris Dippenaar, Project Manager – Britehouse