Cheers! Celebrating Victory

At the end of the project, congratulations and kudos to the project team, the project manager, the project sponsor, and anyone else who helped make the project a success. It is necessary to celebrate the victory of a project and reward the team members for their commitment and hard work. Hopefully, especially if you want future projects to be a success, your organization will spring for something elaborate and in proportion to the project you’ve completed and the success of the victory.

The team members that you’ve coached along have formed friendships and trust among themselves and hopefully with you. This group of individuals has worked hard day and night for you to make you look good and make the project a success. Reward them! Offer tickets to an event, take the team to a fancy dinner, go out dancing, or offer individual rewards that the team members can enjoy on their own such as videos, gift certificates, or cold, hard cash. The point is, reward them, love them, and they’ll come back to work with you again and again.

Interview with Rob Adams

Name: Rob Adams
Title: Corporate Skills Lead, Project Management, PMP
Company: Online Business Systems
Years as an IT project manager: 5

Robert Adams is the Project Management Corporate Skills Lead for Online Business Systems, a North American IT/e-commerce consulting firm, as well as a project manager.

Q: What is the best thing about completing a project?

A: The best thing about completing a project is stepping back and measuring the success. There are two aspects you are measuring. First, while completing an IT project is one measure of success, it is really only a small part of the whole picture. Ask yourself these questions:

Were you on time?
Was the project on budget?
How was quality?
Are you comparing against a baseline only or are you considering change request?
From a business perspective, was it successful?

Second, as a team how did you perform? Was it successful on that front? We are sometimes constrained in our approach and need to deliver under less-than-ideal circumstances. Perhaps there are numerous risks or constraints we are asked to deliver under. While one goal should be to eliminate unnecessary risks and constraints, you rarely eliminate them all.

Q: What are some activities that you do in the completion stage of an IT project?

A: Always review lessons learned by the project manager and by the project team. You need to include the client as well. Forms are easy to use for lessons learned activities; however, it is significantly more valuable to conduct a lessons-learned session with the client or have a face-to-face debriefing. We all know how the team's process affects the outcome of the project. One of the shortfalls I have seen in the IT industry is the lack of emphasis on the impact of how the business process works for projects. Two of the top reasons cited for project failure are lack of sponsor support and lack of end-user involvement.

There is little value to be gained from lessons learned if they are not used in future projects. Additionally, all deliverables, metrics, and pertinent information should be archived in a central repository. My favorites for reference on future projects are project plans, estimation, and risk management. Archiving will also lead to faster development of best practices.

Q: How important is it to create a report on the project's success or failure at the conclusion of a project?

A: This is related to lessons learned and is critical to future improvement in delivering successful projects. Additionally, the report or information must be disseminated. Lessons learned in a nutshell are asking, “How do we repeat the positive and avoid the negative?” If one of your problems was changing business priorities, then this must be communicated to upper management. Perhaps they are not aware of the impact.

Q: What is the most difficult part of completing a project?

A: A lesson learned from a troubled project is the most difficult part. Tension can be high and people can be defensive. Ignoring the problem will not make it go away. It will be a good chance to test your conflict resolution and your communications skills. You may need to communicate unpleasant information to management and team members.

Q: What methods do you use to confirm that the project has reached its conclusion?

A: While the absolute end of the project is administrative closure, the key milestone will be the acceptance of the performed work. This goal begins back in planning. You need to define an end point through a series of deliverables. For many IT project managers, the end is usually recognized by the result of testing the project deliverables.

The quality plan, in concert with the test plan, marks the major end point. The test cases should map directly back to the signed off requirements. We can meet requirements! Therefore, the signed off tests by the client set the marker as to when you are done. The quality plan describes the level of quality attained by the performance of the testing. If you keep the testing phase simple and direct, and there are no serious bugs, the deliverable will be accepted.

Q: What method do you use to evaluate team members' performance at the end of a project?

A: I ask two questions when reviewing each team member:

How did she perform relative to her skill and experience?
Did she progress as the project went along?

We gather this through feedback, from my experience with the team member, from the client, and from the team member herself. The timing of the feedback is important as well. If the person rolls off the project, gather feedback. If the project is long, then evaluate progress on a quarterly basis. Waiting to year end makes everyone's memory fuzzy and does not allow the person to act upon the feedback. For long projects, you do not want someone to underperform for eight months when constructive criticism can result in five months of improved productivity.

Q: What methods do you use to assess the deliverables of a long-term project that may have spanned geographical areas?

A: I would start with the standard matching of project deliverables with business objectives, risk management, and a strong communication plan. I ask the following questions:

Are the business objectives bound to change?
Is there time-to-market pressure?
Is funding set for the duration or do you grab funding as you go?

The answers will affect how you assess the project deliverables. If there is a good chance business objectives could change, then deliverables need to be more frequent. Long-term and geographically diverse projects can carry significant risks. A solid plan, including risk management, is the only sure way to have a shot at being on time and on budget. Projects spanning geographical areas scream for communication—which is the key throughout the project. A long-term project can see a change in the players and even stakeholders. A solid communication plan allows new participants to get up to speed quickly.

Q: How does a project manager know if a project should be declared a failure and raise the white flag?

A: There are a couple of ways. First and foremost, the charter or project plan defines the conditions under which you will consider canceling a project—at a more detailed level, earned value. If the Cost Performance Index is off significantly in the first 15 to 20 percent of the project, in the best scenario you're most likely looking at the same performance for the rest of the project. The worst case is that the project will just get worse! You can predict that you will not recover cost. You may be able to recover schedule, but at an even higher cost. You need to be forecasting! It is not where you are, but where you are going that is important. More subtle signs of a failing project could be resources getting pulled, lack of involvement from key end users or stakeholders, major technical hurdles, or severity of unidentified risks.

Q: Can you share an experience of a project you've managed that reached its conclusion and some of the challenges you faced therein?

A: Sure. An intranet application to be used by ten offices across the country comes to mind. The challenges were numerous:

All four developers were just out of school, but they were quite skilled for their experience.
We had to use a data model that was being modified by five different projects simultaneously.
Of course, there was no program manager for the five projects.
There was no significant project manager authority.
The IT department lacked development methodology and project manager discipline.
The project was IT driven with no business sponsor.
The deadline was tight.
Our question-and-answer resources from the client were constantly unavailable.
The client accepted all the risks.

Through long nights and longer days, we made the date as per requirements. The only problem was the requirements were assumed by the IT staff and did not fit the business unit's objective. I'm sure you saw that coming.

Q: What are some pitfalls a new project manager may face in regard to finishing a project?

A: I have seen two common pitfalls. One, knowing when you are finished. This criterion should be defined in the project scope. Two, not conducting a proper lessons-learned session and communication of the findings to the appropriate people. Lessons learned can be a delicate task depending on what needs to be communicated.

Q: What advice do you have for aspiring project managers?

A: Set expectations. Garner an understanding of the expectations of you and the project. In addition, set standards for what you expect from the team, end users, and the project sponsor. Never stop communicating, and document everything. At the end of the day, it is the people that make the project, not the technology.