Chapter 19 - Project Close-out¶

Part 2¶

What must be done at the end of a project?¶

Every project has to be formally concluded. After the completion of the project work you have to

get customer approval of work or services performed,
calculate the cost of the project and wind up commercial controlling,
document knowledge for the next project,
check if your project has autonomous management structures, if yes, you have to officially dissolve the project team and relinquish your authority.

In practice, the systematic conclusion of a project is extremely significant. Tasks and problems associated with the conclusion of a project are allocated to

an objective level and
a relationship level.

The end of a project on an objective and a relationship level. After finishing one projects, the lessons learned can be taken to the next project to make this even better.

Objective level¶

Although the tasks associated with the objective level are not generally linked to problems, but it is essential that they are performed.

It is a good idea to create a regularly updated to-do list to monitor the punctual and complete performance of outstanding work. You and your team should also ask yourselves the following questions:

To-do	Ask yourself
Acceptance procedures, tests and reviews	Have all the necessary acceptance procedures, tests and reviews been performed? → Acceptance can be performed by an external body or be based on the results of internal tests and inspections. The customer's approval of standard operation can depend on a positive answer to this question.
Performed and outstanding services	Which services does the contractor still have to perform in the project (e.g. delivery of peripherals documentation, training, customer support during standard operation)? Which change requests does the contractor still have to comply with? Which additional financial claims still have to be invoiced for changes implemented at the customer's request? Which obligations do suppliers and sub-contractors still have to comply with? → In each case, you and the customer must check whether the services are actually necessary, how much time they are likely to take and what costs will be incurred as a result. Sometimes, the customer will agree to dispense with specific services if a price discount is granted in return. Checklists can be helpful when analysing the services to be performed. They are prepared in conjunction with the evaluation of concluded projects and archived within the scope of project learning.
Dissolution of key relationships with project stakeholders	Which tasks still have to be performed by the project team for specific stakeholders (e.g. report for senior management, provision of information to the city council or press)? Which tasks do the stakeholder groups still have to perform in the project (e.g. user report after the first test run of a software system)? How will the relevant stakeholder group be informed about the conclusion of the project (e.g. personal debriefing, circular letter, customer magazine, employee newsletter)?
Cost, profit and financial situation	What is the final cost, profit and financial situation? → It is the project controller's responsibility to analyse the cost, profit and financial situation. He does this by determining which instalments the customer still has to pay and which payments the contractor still has to make to suppliers. On the cost side, he has to check if the project costs have been charged to the correct cost centres, the project personnel have charged costs to the correct work packages and whether double charges have been made, e.g. the same costs being charged to two different work packages.
Handover	Has the necessary post-project work (e.g. system support during a transitional period, assignment of responsibility from the project manager to the product manager) been properly transferred to the person or department responsible? Have the responsible members of staff been adequately prepared? Did they receive all the necessary information (e.g. manuals, drawings, parts lists)? Has the customer been informed about the transfer of responsibility? Have the resources, raw materials and supplies that are no longer required for the project been reallocated? Have all the necessary technical data (e.g. power consumption data) been compiled for the customer?

Relationship level¶

Social psychologists have closely studied the process of a group break-up.

The process can be difficult and stressful, when intense group dynamic and interpersonal relationships were carried out over a long period of time.

The dissolution of project teams is often even more difficult because the conclusion of a project can be associated with major concerns.

For example:
Project team members may not know

whether they will be assigned to a follow-up project,
whether they are at risk of losing their job in the organisation.

This situation can be very stressful and project teams often demonstrate a special defence reaction: they implicitly prolong the project work.

Common problems on the relationship level include:
The collective identity of the team gradually weakens and personal interests start to take precedence (e.g. securing a coveted position in a follow-up project). The team gradually loses its identity. → This process is exacerbated if team members who are no longer required to work on the project leave the team before the project concludes. New staff is recruited to the team to perform tasks associated with the project's conclusion or to be trained to provide system support. Often, team members are reassigned to line management or transferred to other projects before the official conclusion of their own project.
Sometimes, the project team continues to work on a project for longer than necessary because its members believe that they have no other prospects in the organisation. In many cases, they are not sure what they will be doing when the project ends. Further motives for unnecessarily extending project work include: New assignments are not particularly appealing. Team members are worried about having to work on something new.
Team members voluntarily leave the project shortly before its conclusion. In practice, there are various reasons for this phenomenon: Project team members may want to leave the project in good time to join another project. They may prefer not to be identified with a failed project. They may fear that they will be asked to perform menial and boring tasks (e.g. documentation) at the end of the project. When this happens, the customer and you, as a project manager, lose important contacts.

You should be aware of problems that occur on the relationship level when a project team is dissolved and develop an understanding for this type of behaviour. The personnel in question should be offered a specific new position. For example, many problems can be avoided if necessary personnel transfers are planned meticulously in advance by the personnel department and the employees being reassigned. This nips concerns about the future in the bud.

It is important to end the project with a joint experience involving all team members. Various separation rituals and ceremonies exist that are suitable for concluding a project on the relationship level. For example, a close-out party should be held and appropriate tribute paid to the project team - a representative of the organisation's senior management could attend. Organisational psychologists suggest that awards should be presented to project personnel. You should inform your project team about the planned event well in advance.

Project closure meeting and project learning¶

The project closure meeting and the report detailing its results are the counterpart to the project start-up meeting. The people attending the meeting analyse and evaluate the

project results,
project processes and
consequences for the post-project phase.

They also document the experience gained in the project and assign the tasks that still have to be performed.

Unfortunately, these recommendations are difficult to follow, especially in problematic projects. It is never easy to talk about failures. This is why it is possible that the project will not be analysed objectively and that the team members will blame each other for the project's failure. Project closure meetings should therefore be prepared carefully.

At the project closure meeting, the steering committee generally discharges the project manager and his team from their responsibilities, i.e. they approve all the performed activities of the project manager and his team (declaration of acceptance by senior management).

The following issues should be discussed at the project closure meeting:

Summing up the project by the project manager:
- What objectives were attained/not attained?
Feedback round - each participant is given the opportunity to speak:
- What went well (e.g. strengths)?
- What didn't go well (scope for improvement)?
Discussion of the feedback round
Project learning - safeguarding knowledge for future projects:
- What can the team and the entire organisation learn from the project?
- What measures have been implemented to prevent the repetition of mistakes?
Information about the conclusion of the project:
- Who will receive the final report?
- Who will only receive brief information about the conclusion of the project?
Assignment of remaining tasks (e.g. drafting of the final report)
Celebration of the project's conclusion

Final report¶

Project management literature provides numerous suggestions about how to structure final reports. However, there isn't the one and only structure that is appropriate in all circumstances. The content of the final report depends on the type and scope of the project. Bearing this in mind, the following sections only refer to content that is absolutely essential:

Information about
- quality objectives planned at the outset and those that were actually achieved,
- originally planned and actual close-out date,
- estimated budget and actually incurred costs.
  → It may be appropriate to provide reasons for any deviations in all three parameters.
The issues of
- what went particularly well in the team and in relationships with project stakeholders,
- what didn't go that well.
Information about
- Consequences for future projects that are derived from deviations,
- tasks that still have to be performed.

Project analysis¶

Objective level¶

To-do	Ask yourself
Calculation of historical costs	Most common method Historical costs can be taken as the basis for the calculation of costs in a new project, provided that the project is associated with a low degree of innovation. If the originally planned costs are exceeded by far, it is necessary to identify the main cost drivers in a cost variance analysis. It is also important to implement a variance analysis if the project lifecycle is longer than originally envisaged.
Project cost databases	Far less frequently used than historical cost calculation. Construction industry is an exception to this rule. → Systematically evaluates the costs of concluded projects on a relatively frequent basis. This analysis can be used to plan new projects. Construction industry has developed structuring guidelines that enable experts to make an understandable record of cost data and to find information about historical costs.
Performance indicators and performance indicator systems	Rarely used (exception: IT industry) Performance indicators that are defined for IT projects apply to both the developed product and the process of product development. Key performance indicators include adherence to deadlines, adherence to costs, frequency of changes in project requirements, number of errors and error rates, which in some circumstances are categorised.
Customer survey	Trend: Increasing customer orientation → makes it essential to survey this stakeholder group, so a customer survey should be established. In practice, it is not always easy to determine who precisely should be surveyed. → In cases of doubt, it is therefore advisable to survey the satisfaction of several target groups.

Relationship level¶

To-do

Ask yourself

Questionnaire

There are some questionnaires which are meant just for the relationship level.

They can be used during the project to encourage the team to consider their approach to teamwork.

Feedback interviews

Feedback interviews between the project manager and his team are a source of information that does not appear in official reports (e.g. about team conflicts).
One-to-one interviews are generally more advantageous than group discussions:
- Employees are more likely to express their criticisms and ideas when alone than if other people are present.
- But, they are time-consuming and management-intensive.
You should also hold feedback meetings with the next management level to enable the systematic processing and use of experience from the project.
The meetings also provide senior management with information, for instance, which project manager is suitable as a mentor in other projects.

Comparison: Objective and relationship levels¶

To-do

Ask yourself

Project personnel questionnaire

Fast and simple to implement
Can be used for analyses at both objective and relationship level
Often, one questionnaire is used to survey both levels. They can be used to survey
- project team members,
- departments involved in the project,
- suppliers or sub-contractors,
- customer representatives,
- potential users or
- other stakeholders.
Standardised questionnaires or interview guidelines for questioning stakeholders are commonly used methods:
- Enable a comparison of different projects
- Final project workshop provides a good opportunity for its use
Informal one-to-one interviews allow the interviewer to obtain additional information that a questionnaire cannot collect.
- Ambiguous statements by interviewees can be clarified and they can be prompted if they are obviously withholding information.

Project experience databases

Development of project experience databases is very complex.

These databases are suitable for analysing a project on the relationship level.

Provide a clearly structured overview of experience gained in earlier projects.

How the story ends…¶

Dr. Rogers comes to an end with his lesson. John seems satisfied with the contents, since he learned a lot of new things. "Last but not least, John, I want to ask you one question of which the answer is important for every future project manager: which two aspects are the key to a successful project conclusion?" "Since you took me under your wing, I've realised the importance of communication. So, I would say that one key to success is definitely communication", replies John. Dr. Rogers is proud of his colleague who learned many things during the internship: "Yes, that's it! It is important that formal communication is properly organised. The second aspect is connected with the project manager's authority. The stronger the formal position of the project manager, the better he can influence the project."

John and Carl have their drinks and talk a while longer - about project management in general and the hay fever medication in particular. John talks about how his university studies will continue after his internship and what his future plans are.

Dr. Rogers asks how John liked the internship and John tells him what he liked most and where the challenges have been.

All in all, John is very satisfied with the internship - he learned a lot, got a taste of a "real" project and now he definitely knows that he wants to work in project management after finishing his studies.