Home / Project Scope / Is This Project A Success Or Not?

Is This Project A Success Or Not?

What happens when a project has been completed to schedule and more or less on-budget but the client is reluctant to sign-off the work and even more reluctant to pay for it?

The final product meets the documented requirements so surely a project that is on-time, on-budget and on-scope must be a success. Aren’t those 3 factors the cornerstones of determining project success? What else could be expected of the project manager and the team?

 

As it turns out – quite a lot more is expected of a project manager and it is typically in the areas of fully defining project success criteria and ensuring that the documented requirements actually state what it is the client wants and expects. This is not about managing client expectations (although, obviously that is an extremely important aspect of every project) but about making sure that a written description (of project success criteria and business requirements) is well understood. And that means that what is omitted from the documentation is also clear to the client to avoid assumptions being made.

 

So there you are with your completed project that doesn’t deliver what the client expected so what can you do about it? The answer in many cases is nothing – but, take heart, there is usually an agreement to be reached if you, as the project manager, are willing to accept that the project has not delivered on expectations (even if it has delivered technically on paper) and if you can persuade the client to agree to accept the project as is in return for the immediate implementation of a programme of enhancements to the product.

 

There can’t be many project managers out there who have never had to embark on a follow on project simply in order to get the product up to scratch. So that is usually the most viable solution out of your current predicament, and one which might just rescue your reputation as a good project manager. But why did it all go pear-shaped in the first place and how can you stop it from happening again? After all you followed the organisation’s project management framework, which has been tried and tested over years and proven to deliver successful projects, why has it gone wrong now? It would be tempting to say that maybe the PM framework in place has not kept pace with changes in the workplace and changes to technology but that’s really a discussion for another time.

 

Here I want to look at why the documented business requirements didn’t clearly state what the client actually wanted as that is a problem that can occur no matter how up to date the project management framework is and if the project team are not singing from the same hymn sheet as the client then disaster is a certainty.

 

Let’s assume that the project in question can actually have its requirements fully documented near the start of the project – of course, not every project can and some will have to take an iterative approach but whether you are documenting the requirements for the final product or just a stage deliverable it is still essential that the words reflect expectations. It is also, by the way, essential that those stakeholders responsible for approving the requirements documentation actually read the document fully. Many a project has been de-railed by stakeholders only giving a cursory reading of the specifications and a treating the sign-off as a rubber stamping exercise.

 

One of the best ways of ensuring this doesn’t happen is to have a walkthrough of every aspect of your specifications with a variety of stakeholders and others involved in the project, including end-users. Many people are daunted by the prospect of reading and absorbing a long document, particularly one that contains technical terms that they are baffled by, so take the time to have a number of get-togethers where you can lead the assembled group through every part of the specification and encourage discussion of each aspect. This will raise questions, areas that need clarifying and ultimately discover assumptions that are being made. Yes it takes valuable time and will eat into everyone’s working day but the alternative is a failed project so make sure everyone understands why they are spending their valuable time walking through a document in fine detail, and if all else fails bribe them to attend with coffee and cakes.

 

 

 

 

About M Symonds

The author is a freelance consultant specialising in digital marketing. She has many years experience in IT and IT Project Management in the oil industry and investment banking on complex global projects and managing outsourced project teams.

Check Also

scope creep - rising costs

Controlling Scope Creep

It is quite normal that the business requirements for a project will change after the …