A Little Story about Counting the Wrong Thing
Here are a few illustrations of counting the wrong thing on a customer service improvement project with a scope defined as, “Provide World Class Customer Service that Delights the Customer”:
- A PM measures the engineers’ performance by the number of lines of code each engineer writes and rewards the engineer with the highest total with a lunch with the CEO.
- A PM measures the trainers’ performance with the rating that class attendees give each trainer and the one with the highest rating receives a certificate of appreciation.
- A PM measures the performance of team members doing a survey of managers by the number of interviews each team member conducts and rewards the one who does the most interviews with public recognition at a status meeting.
What performance do we get from assignments like these? Well, the engineers will write a lot of lines of code and some of it may benefit the customer service division and a lot will not. The attendees in the trainers’ classes will really have a fun time but may not learn much. The interviewers will conduct a whole lot of interviews but much of the information hurriedly gathered may be useless.
The project manager in these examples counted the activity being performed and got the expected; lots of what he was counting even if it contributed little business value. The project manager most likely did not know what business value was needed from the assignments so he picked the activities that were handy.
Just Counting Dates
Another form of counting the wrong thing occurs when a project is so vague that the only metric we can count is the due date. Usually, the due date in these situations does not reflect the amount of work to be done or the resource’s availability to do it. They are picked to hit an executive’s completion date. The team members have no commitment to these dates and often they recognize, before work starts, that the dates are impossible.
So at each status meeting the team is asked, “Are you on track to hit your due dates? You committed to them.”
Most team members give the PM an optimistic thumbs up. Then one day a reckless soul answers truthfully, saying, “No, that date is impossible. There is no way I can hit it.” Lightning strikes the truthful innocent and thereafter everyone reports green light status regardless of how much optimism that requires or how many miracles they are counting on. What does the organization get at the end? The team members turn in crappy work, but it’s on time, and then spend months fixing it.
Project sponsors drive much of this “date behavior” when all they focus on is the due dates of assignments and the project as a whole. This is not to suggest that the dates are not important; they are. But delivering crap by the due date does not mean the project is a success. Of course, most project sponsors are accustomed to having projects where there is nothing else but dates for them to track. Everything else is vague subjective statements. So it’s not surprising that sponsors like dates; they are objectively measurable and unambiguous and too many project managers don’t give them anything else that is measurable. What we need to do is to count the right things. We need to count the business value an assignment or a project produces, the date, the cost and the risk. These techniques take a bit of time but yield enormous benefits.
Top Down Decomposition
The PM works with the sponsor to define a measured business outcome for the project with acceptance criteria that are also measurable. For a customer service project a scope definition of, “Complete 95% of customer phone calls within 3 minutes with less than 3% call back about the same problem” is a clear measured outcome. Next we decompose it.
As we decompose the scope into system deliverables we’d come the GIU (screen display) that an engineer has to develop. That measured outcome would be “Customer service rep sees 6 months of customer history within 4 seconds of entering the customer’s name or number.” Note that is an achievement measured in the user’s business, not the engineer’s department. That makes it a whole lot more relevant to the scope than counting lines of code.
The trainer would have a different achievement too. The assignment would be “80% of the attendees at the class can answer the top 20 customer questions in 120 seconds or less using the new GUI.” Again what we are counting is more relevant to the project’s scope than how good a time the class attendees had.
The team members doing the interviewing of managers would have a measured business outcome like, “Managers reach consensus on the ten most important customer service problems.”
That sounds pretty straightforward. It takes some time and good technique but what we are now counting and measuring is relevant to achieving the project scope. Assignments defined in measured terms like those above make performance expectations clear to the team members before they start work. That makes estimating and tracking much more precise and lets us spot problems early.
All the techniques in this article are part of our Best Practices Project Methodology which we teach in one-on-one courses over the Internet as well as in-person seminars for organizations.
