Why use a Proven Project Methodology?
15 Apr 2015
In the second of our series on Project Management, George Strathie, Software & Services Director, looks at the importance of using a proven project methodology.
A methodology is a framework for the delivery of the project. It’s not a project plan, a Terms of Reference document or a training manual; it’s all of those, plus a process that suppliers or providers use to guarantee a successful outcome for each project.
Flexibility is important for a methodology. There are common methodologies such as PRINCE2 or the Microsoft methodology Sure Step, (at Castle we use PQIS), but whichever you choose, it’s important your methodology is flexible. The precise methodology you employ should depend on the size and importance of the project, size of your organisation and available resource.
Your chosen methodology should be scalable and flexible enough for your organisation to choose which parts are most important as one size doesn’t fit all. It can be detrimental not to consider the specific conditions of your project and utilise a standard ‘out of the box’ methodology.
Whichever methodology you choose, it should have steps and deliverables. Steps mean the project is broken down into manageable chunks and it gives a yardstick to the progress of your project. The methodology should include necessary controls for key steps that ensure you are on track in regard to timescales, but also deliverables and the meeting of objectives.
Typical Methodology Steps
This is definition of the project objectives, ensuring they can be met and communicating these to the project team. These should be detailed within a Terms of Reference document that articulates all the requirements. As the implementation can be more costly than the software, it is vital that it is well defined from the outset. The Terms of Reference should be documented and agreed up front.
The Scope definition should include documentation on why you are doing the project, regardless of the size of your organisation or project. You should define the resources that you will provide and those provided by your main supplier, or other third parties. The responsibilities for each step of the process should be clear, and of course include costs. The costs should not only include those quoted by the supplier, but also your internal costs of 1. Freeing up resources involved in the project and 2. Back filling the normal responsibilities of those involved. These should be shown for each stage, so the total cost of the project can be tracked.
These include business mapping and business process design as it’s important to understand what parts of the software you are going to use and how it’s to be configured. Modern software is very configurable, so you need to ensure that you are using it in a way that gives you the maximum benefit and return.
You should know who builds it and how they will be trained, to ensure that everything that needs to be done actually gets done.
The steps of the methodology help identify who has responsibility, but there can be flexibility in the order as they don’t have to happen sequentially. It’s dependant on the conditions surrounding the project, but employing the steps ensures that activities and resources are ring-fenced and you know who is responsible.
As we get closer to live operation, which is seen as the ultimate goal, we are gearing up to using the software, ensuring users are more confident, ensuring processes work, migrating the data and validating the solution.
You can’t just choose the software and start using it. You need to configure, train the users, migrate your data and then test the solution. You need to ensure the software you are using is doing the job that you expect it to do.
In the end, the step that refers to live operation should be of little consequence as a result of your preparation, but as a step, it’s important that it’s still ring-fenced and ultimately signed off, as that means that to all intents and purposes the project is complete.
Post implementation review
At the end of the process, you need to review what benefits have been achieved and articulate these back to the management team as sometimes in the maelstrom of the implementation process, these can get forgotten about.