Each week, project management veteran Tom Mochal provides valuable advice about how to plan and manage projects. He first describes a common problem scenario, based on a real-life situation, then offers a solution, using practical project management practices and techniques.
Reyna and I met for a breakfast meeting this morning. She is winding down a project to create a new advertising tracking system for the marketing and sales organization. She was torn because her project was over budget and over its deadline, and now she had to provide performance input for her team members.
“I talked to you a few times about our project,” Reyna began. “You know the difficulties we had trying to get the work done on time and the problems we encountered. On the other hand, the team worked extremely hard, and we would have been worse off without their effort.”
“There is no question your team worked hard,” I agreed. “I saw them working late and early on a number of occasions. Let me ask first whether your team created a project scorecard to help define your performance criteria.”
(The organization has a standard scorecard that focuses on schedule and budget, but project teams are encouraged to build on these minimum criteria.)
“No, we didn’t,” Reyna said. “We only have the default project scorecard. That is actually why I’m struggling. Since the project didn’t meet the criteria in the standard scorecard, I think it makes everyone on the team look bad. That doesn’t seem fair.”
“What do you think were the causes for the project’s problems?” I asked.
“Well, there is no question that we missed a number of internal deadlines,” Reyna admitted. “We encountered a number of problems that we didn’t resolve quickly enough. Of course, as you know, the testing took much longer than anticipated because of a number of errors that we encountered.”
“And who was responsible for these problems?” I asked.
Reyna didn’t want to put the blame on any one or two people: “The entire team contributed to the problems, and the entire team helped to resolve them.”
“Good,” I said. “Then it looks like our standard performance scorecard will still work fine.”
Have you ever been on a project that missed all of its commitments for cost, schedule, and quality? I can think of a number of projects I was involved in that had major problems, even some that were cancelled, on which the team members all received great reviews and the project manager was promoted.
My sense is that, in the past, the review process in many companies was based on overall effort and knowledge level. That is, if you were very knowledgeable in technology and the business, and if you worked hard, you tended to be rewarded with good reviews every year. On the surface, this seems fine, right?
It is fine up to a point, but these criteria don’t adequately tie actual job performance to your performance review. The review process should be based on performance against the expectations of the job description, performance against objectives, and performance against expectations.
I think companies are reviewing people more and more against performance criteria, instead of effort. That way, you don’t end up in a position where a project fails miserably, yet all the participants receive above-average reviews. I’ve never seen a problem project where the project team was not partially, if not totally, responsible.
In the mid-1990s, for example, our company had a project to develop a replacement for a major general ledger and accounting system. After two years, the plug was pulled after hundreds of thousands of dollars had been spent without producing any major deliverables. However, senior members of the project all landed on their feet, including one that was immediately promoted.
To the rest of the staff, that didn’t appear to be a case of rewards matching performance. A few years later, under a new CIO, the pendulum had swung. In departments where major projects experienced major problems, it wasn’t uncommon for the project manager and the department manager to both be reassigned.
On Reyna’s project, everyone on the team tried hard, but the results weren’t successful. In the past, we might have brushed this all under the rug and given everyone good reviews to reflect their hard work and get them pumped up about the next assignments.
However, that’s not how we do things today. Hard work is something that should be applauded and recognized, but missed deadlines should also be recognized, as should unit-testing problems that didn’t formally surface until user testing. Project management weaknesses should also be recognized, as should project issues that the team allowed to sit too long.
The bottom line is that individual contributions—and the project results—should be factored into the performance feedback. We should recognize team members for their contributions, but also hold them accountable for the project results. Make sure that the overall project results, good and bad, are factored into personal performance evaluations.
Tom Mochal is president of TenStep, Inc., a project management consulting and training firm. Recently, he was director of internal development at Geac, Inc., a major ERP software company. He’s worked for Coca-Cola, Eastman Kodak, and Cap Gemini Ernst & Young. Tom has developed a project management methodology called TenStep and an application support methodology called SupportStep.