A recent project has caused me to write this blog, although it is not a new phenomenon … I should have written this some years ago and forwarded the content when projects start to go astray.
There are several industry standard methods of controlling and managing projects used in project management today.
DSCallards are trained in two of these: PRINCE2 and Agile. In some ways these are conflicting methodologies.
PRINCE2 is there because government and public sector projects needed an agreed method of control. And PRINCE2, if adhered to correctly, provides you with this tight management process. But although we can plan projects down to the “nth” degree, somewhere in this very strict framework there needs to be movement. Some form of freedom to work on unknowns and “what if’s”.
This is where Agile comes in to play as this methodology is seen as a form of freedom. But this requires just as much rigour in handling these Agile work processes as PRINCE2 insists upon.
And perhaps this is why a lot of government and public sector projects fail. The projects are far too big, and any smaller work package that fails during the life-cycle of the project can impact the delivery. The problem is known early in the project and from then on it is a constant trouble shooting exercise. So focus starts to disappear on the end target and this means the delivery is bound to fail.
So whatever delivery method you decide upon, it needs a trust from both sides - the customer and the supplier.
In most other walks of life this is the case. When you have your car in for a service there is a service cost. And when the garage calls you during the work and tells you they have found something else, although this is always a pain, we don’t insist the garage do this work within the cost of the service? Or do you?
If you have a house built they do say allow 10%-15% above the costs you have been quoted to cover the unseen items. In my experience it is a lot more than this.
In any project delivery there are three points within the delivery. Cost, Time and Functionality. Until both parties realise and understand that only two of these are deliverable, projects will continue to fail.
So for example if you have limited budget, and need it delivered on a certain date, be prepared for the functionality you asked for to suffer.
If you insist on the functionality and the time scale, then cost may go up.
And if you insist on functionality and cost, the time scale may slip. In this case it is also more prevalent for the costs and functionality to suffer.
So coming back to the case in point, one of our customers wanted functionality at a limited cost. So I explained that this was now purchasing time from us and not a deliverable. Although we will endeavour to deliver the functionality, due to the weak specification and limited budget all I could realistically promise is an amount of time.
This was explained in the Statement of Work and was agreed by us and the customer, but as we near the end of the time allocated and after several changes to the specification we will not deliver the functionality expected by the customer. We will deliver the time worked, in fact more than promised if I am honest, but because of the missing two way trust, this project will probably fail.
The lesson here maybe mine rather than the customers.
Make sure the customer understands this is a two way thing before you start. Perhaps they would have spent more time on watching the clock and putting together a better specification at the start to avoid the missing “functionality” part of the triangle?