Are we There Yet?

26 May, 2014

It seems like an obvious question, but when is the execution of a project finished? People with project management certification will cry that it is only finished when the customer has signed off that the deliverables are acceptable. While this is the right answer, real world projects often have very unclear endings.

If you have ever bought a new house, or a second-hand car, you will understand what I am talking about. Take a walk around any new house and you will soon have compiled a surprisingly long snag list. Similarly, you might cut a deal with a garage to buy a car on the basis that problems you have seen will be remedied.

Yet life moves on. Our rental agreement runs out and we have to move into the new house, ready or not. Similarly, I need the car for work, so I will, in the end, take it without all the remedial work completed.

Many projects are executed in the context of a wider programme. Other work, such as training or a big advertising campaign is planned on the basis that your product, service or result is ready for roll out. If it is not, what is ready will be used, but only on the strict understanding that the snag list will be addressed. Because the customer will not sign off until the deliverables are completed satisfactorily, the execution of the project cannot be deemed complete.

However, the project manager now comes under pressure internally to free up resources that are needed on other projects. So people leave the project without any sense of closure. Similarly, those that remain find themselves in a sort of limbo between development and maintenance. Wise maintenance departments will also be reluctant to accept a half-finished product.

But, assuming that you have finished everything and are quietly congratulating yourself on a job well done, are you sure you are actually finished? Get out your project plan. Has all the work specified in the work breakdown structure and the activity lists been completed? Can you show that it has? This is where a traceability matrix helps. If everything is not finished, then what is your plan to complete the work?

Similarly, check your issue log. Are there any outstanding issues? If so, what is going to be done about them? Sadly, just like some of the items on your snag list, many of these items might never get addressed. However, as a professional project manager, you need to do better than simply sweep these under the carpet. Contact the people who have raised these issues and explain the situation. At least if the stakeholders know the position, they can deal with it.

Are we in a position to transfer the project over to a maintenance organization? Is all the user documentation complete? Have we been working with the maintenance organization to train them up in how the deliverables work? Have we shown them workarounds to deal with known problems?

Have we planned the transition of the project’s deliverables? Have we met with the maintenance organization and organized a smooth handover? In many instances, there is a perception that a maintenance team can magically hit the ground running with a new product. By opening lines of communications with the maintenance people, even getting them involved during the development itself, can make the group more willing to take on responsibility earlier.

Remember the quality goals we set during planning? Were they met? While 100% perfection is the ideal we should be striving for, was our end product anywhere near that? Have we measures that can be used to assess the final quality of the product? The big question is if the final quality is acceptable to the customer. It might not be perfect, but it could well be good enough. If it is not acceptable, more work needs to be planned.

Have acceptance criteria been specified with the customer? These form the basis for acceptance tests, where the product is given a series of trials to demonstrate its ability. However, if the customer is not happy with the trial, how much can be done to remedy the problems? Resources might not be available to do the work and deadlines could mean that the product or service needs to go live as it is.

When rework is required at the end of a project, there is a temptation to forget the project closing activities in order to make some time. However, this will only make things worse, because now there is no definite end to the project. It was reluctantly accepted and eventually got into maintenance mode because the need for the project resources outweighed the need to complete the project. Closing things formally and reviewing the project with the team and the stakeholders will provide closure and record the painful lessons learned.

However, it is important that project managers do not leave the formal handover to the end of the project. You need to analyse your stakeholders and ensure you understand what their priorities are. If you can target your best resources at the correct areas, an unfinished product might not be a complete disaster. Of course, an ideal situation is to deliver functionality as soon as you can in order to get feedback. Sometimes, this exercise can provide business value to the customer before the project is finished. Don’t just take my word for it, this sort of thinking forms the basis of agile and lean methodologies – so it is worth a look.

Velopi has put these points into a checklist and will send this onto any project manager who is interested. Simply contact us by e-mail and we will send one straight back to you.

By Velopi Seamus Collins

© 2018 Velopi : PMBOK, PMI and the R.E.P. logo, PMP, PgMP, CAPM, PMI-SP and PMI-RMP are registered marks of the Project Management Institute, Inc.

Web Development by Granite Digital