Closing Out a Project

by Dimitrios Litsikakis on 08/05/2013

When the project is finished, the closeout phase must be implemented as planned. “A general rule is that project closing should take no more than 2% of the total effort required for the project” (Crawford, 2002). The project management literature has many different sets of actions for the last phase of the project life cycle. Maylor (2005) groups the necessary activities into a six step procedure, which can differ depending on the size and the scope of the project:

1. Completion

First of all, the project manager must ensure the project is 100% complete. Young (2003) noticed that in the closeout phase “it is quite common to find a number of outstanding minor tasks from early key stages still unfinished. They are not critical and have not impeded progress, yet they must be completed”. Furthermore, some projects need continuing service and support even after they are finished, such as IT projects. While it is helpful when this demand is part of the original statement of requirements, it is often part of the contract closeout. Rosenau and Githens (2005) suggest that “the contractor should view continuing service and support as an opportunity and not merely as an obligation” since they can both learn from each other by exchanging ideas.

2. Documentation
The importance of documentation is emphasized by Pinkerton (2003) who notes that “it is imperative that everything learned during the project, from conception through initial operations, should be captured and become an asset”. A detailed documentation will allow future changes to be made without extraordinary effort since all the aspects of the project are written down. Documentation is the key for well-organized change of the project owner, i.e. for a new investor that takes over the project after it is finished. Lecky-Thompson (2005) makes a distinction between the documentation requirements of the internal and the external clients since the external party usually needs the documents for audit purposes only. Despite the uninteresting nature of documenting historical data, the person responsible for this task must engage actively with his assignment.

3. Project Systems Closure
All project systems must close down at the closeout phase. This includes the financial systems, i.e. all payments must be completed to external suppliers or providers and all work orders must terminate (Department of Veterans Affairs, 2004). “In closing project files, the project manager should bring records up to date and make sure all original documents are in the project files and at one location” (Arora). Maylor (2005) suggest that “a formal notice of closure should be issued to inform other staff and support systems that there are no further activities to be carried out or charges to be made”. As a result, unnecessary charges can be avoided by unauthorized expenditure and clients will understand that they can not receive additional services at no cost.

4. Project Reviews
The project review comes usually comes after all the project systems are closed. It is a bridge that connects two projects that come one after another. Project reviews transfer not only tangible knowledge such as numerical data of cost and time but also the tacit knowledge which is hard to document. ‘Know-how’ and more important ‘know-why’ are passed on to future projects in order to eliminate the need for project managers to ‘invent the wheel’ from scratch every time they start a new project. The reuse of existing tools and experience can be expanded to different project teams of the same organization in order to enhance project results (Bucero, 2005). Reviews have a holistic nature which investigate the impact of the project on the environment as a whole. Audits can also be helpful but they are focused on the internal of the organization. Planning the reviews should include the appropriate time and place for the workshops and most important the people that will be invited. Choosing the right people for the review will enhance the value of the meeting and help the learning process while having an objective critique not only by the team members but also from a neutral external auditor. The outcome of this review should be a final report which will be presented to the senior management and the project sponsor. Whitten (2003) also notices that “often just preparing a review presentation forces a project team to think through and solve many of the problems publicly exposing the state of their work”.

5. Disband the project team

Before reallocating the staff amongst other resources, closeout phase provides an excellent opportunity to assess the effort, the commitment and the results of each team member individually. Extra-ordinary performance should be complemented in public and symbolic rewards could be granted for innovation and creativity (Gannon, 1994). This process can be vital for team satisfaction and can improve commitment for future projects (Reed, 2001). Reviewing a project can be in the form of a reflective process, as illustrated in the next figure, where project managers “record and critically reflect upon their own work with the aim of improving their management skills and performance” (Loo, 2002). It can also be applied in problematic project teams in order to identify the roots of possible conflicts and bring them into an open discussion.

Ignoring the established point of view of disbanding the project team as soon as possible to avoid unnecessary overheads, Meredith and Mandel (2003) imply that it’s best to wait as much as you can for two main reasons. First it helps to minimize the frustration that might generate a team member’s reassignment with unfavourable prospects. Second it keeps the interest and the professionalism of the team members high as it is common ground that during the closing stages, some slacking is likely to appear.

6. Stakeholder satisfaction

PMI’s PMBoK (2004) defines that “actions and activities are necessary to confirm that the project has met all the sponsor, customer and other stakeholders’ requirements”. Such actions can be a final presentation of the project review which includes all the important information that should be published to the stakeholders. This information can include a timeline showing the progress of the project from the beginning until the end, the milestones that were met or missed, the problems encountered and a brief financial presentation. A well prepared presentation which is focused on the strong aspects of the projects can cover some flaws from the stakeholders and make a failure look like an unexpected success.

Even when the client accepts the delivery of the final product or service with a formal sign-off (Dvir, 2005), the closeout phase should not be seen as an effort to get rid of a project. Instead, the key issue in this phase is “finding follow-up business development potential from the project deliverable” (Barkley & Saylor, 2001). Thus, the project can produce valuable customer partnerships that will expand the business opportunities of the organization. Being the last phase, the project closeout plays a crucial role in sponsor satisfaction since it is a common ground that the last impression is the one that eventually stays in people’s minds.

Share

{ 0 comments }

Permalink

Trackback URL for this post: http://www.orgtopia.com/2013/05/08/closing-out-a-project/trackback/

Selling Project Management

by David Hinde on 01/05/2013

I received an email from a past client this morning asking for some help “selling project management” within his organization. From my own experience I know how difficult communicating the value of project management can be.
I remember early in my career managing an IT project. At the beginning of the initiative my team and I carefully identified stakeholders and the scope of work and then planned the implementation. There were a few hiccups along the way, but the time we took at the start paid off and the project ran pretty smoothly.
Contrast this with a very similar project running at the time.  This project’s team had dived into the implementation with minimum planning. Problem after problem surfaced. They had to work long hours and weekends to put out the many “fires” that occurred. Their project delivered several months late.
Later on I discovered that a senior director had noticed the weekends and long nights that the “firefighting” team had worked. In the next company meeting he made special mention of the time they’d put in. Our team, who’d delivered the project on time, on budget to a happy client who went on to order more of our services, got no mention!
It was a good early lesson for me. I realised that good project management is like invisible glue that pulls a project together. The time that a project manager takes liasing between all the key people, cajoling and negotiating with them to agree a realistic scope and timescales, ensuring they take on the correct roles and do the right work can be easily forgotten.
I realised that one very important role for a project manager is project management publicity. These days I encourage project managers to regularly communicate to key people the importance of their work. For example a recent client managed to get agreement about the scope of a large change programme for a multi-national company. After months of disagreement, he’d got all the key people into a room, spent a long day facilitating a hard negotiation and came out with a realistic agreement. I made sure he communicated his role in this work to his own senior managers and how this meant a large order for an implementation initiative for his own company.
Make sure – for your own good – people realise all the work that you have done as a project manager, how difficult it was and its importance.

Share

{ 0 comments }

Permalink

Trackback URL for this post: http://www.orgtopia.com/2013/05/01/selling-project-management/trackback/

Responsibility – a Key Ingredient for Change

April 10, 2013

One thing I look for when working with a new client is whether they are taking any responsibility for the problems within their organization. I find the more a client is willing to accept the hard truth that some of the things going astray are their fault, the easier it will be to implement positive [...]

Share
Read the full article →

User Points and Planning Poker – Some Estimating Ideas from Scrum.

July 9, 2012

Scrum has some interesting ideas to overcome the perennial challenge of accurate estimating. In this blog I’d like to have a look at a collection of those approaches: story points, burn-down velocities and planning poker. Scrum is generally used for software development projects, but the ideas in this blog could be applied to any type [...]

Share
Read the full article →

Useful Software for Managing Agile Projects

June 28, 2012

This is less a blog and more a list. It comes from a project management for software development course I ran a few weeks ago. As a class we came up with a list of software we’d used to manage agile projects. The only two I have used are Pencil and OnTime, but I’m sure [...]

Share
Read the full article →

Are You Managing a Programme or a Project? (And Why You Need to Know)

June 28, 2012

In some ways projects and programmes are pretty similar; they both introduce change, should bring benefits to the organisation or the environment, have a start and end and are generally riskier than business-as-usual. But managing a programme in the same way you’d approach a project could lead to disaster. Why is this? Well firstly a [...]

Share
Read the full article →

Project Rescue: A Parental Approach

April 30, 2012

I have spent a large portion of my career rescuing troubled projects. Sometimes I get them in the beginning and have time to restructure them and sometimes (usually) I get them late when everything is on fire. In my view there are four types of projects which need attention and I will use a parenting [...]

Share
Read the full article →

A Lesson in Change Management

April 30, 2012

I deal with change management on an ongoing basis and what never fails to amaze me is the inertia of some senior managers in front of severe problems the company is facing. Even if the shares are plummeting, the press is slaughtering them for poor performance and the shareholders voice their concerns, those senior managers [...]

Share
Read the full article →

Forget Task Planning – Use Pull Planning!

March 16, 2012

Two difficulties with project management are keeping a project on schedule and on budget. Failures to meet requirements in these areas have resulted in an over reaction in the level of detail put into early project plans. Nice little catch phrases like “He didn’t plan to fail, he just failed to plan” distort the realities [...]

Share
Read the full article →

Selecting Project Managers

March 16, 2012

The project manager needs to be one of the best managers in the company and picked at the onset of the project. After all, they have a difficult job. They must manage diverse teams with members who all have “real” bosses elsewhere in the company. When picking someone to be a project manager, keep these [...]

Share
Read the full article →