When I’m consulting with a client—usually a large business where bloated, traditional Waterfall-style software development processes are the norm — someone inevitably asks about tracking percent complete. They’re pretty shocked when I tell them that tracking percent complete is an utter waste of time.
Unfortunately, many otherwise good project managers are taught that tracking percent complete on a software development project somehow adds value. Often, tracking percent complete is part of the organization’s “standard” PMO process, making it a mandatory metric for all projects. Many project managers track this metric because they don’t know any better — or they know better but are not able to confront the issue within the organization. Any resistance is usually countered with “we’ve always done it this way.”
I know because I have been managed by these traditional-thinking project managers and PMO's; as well as, in my early years, managed projects this way.
“What Percent Complete Are You?”
I shudder at the thought of a project manager stopping by with his Gantt chart and asking, “What percent complete are you?” I have been asked this more times than I can count, and my response was usually something like, “Hmm, 23 percent.” The next week, my response might be “35 percent.” The project manager would keep stopping by until I reached around the 80-90 percent done mark, and I stayed at this percentage until my work was “done.”
Often, the last 10 or 20 percent was the most difficult part. It didn’t matter if I was writing a line of code, documenting requirements, or testing some features, because software development by its very nature is a creative endeavor. On a task that was estimated at 16 hours, that last 10 or 20 percent might be another five, 10, 15 hours or more. It’s not like building the frame for a house a thousand times over, where all the materials, tools, and labor stay the same. In software development, every project is different.
If you’re a project manager, you may get frustrated when the person performing a task gives you a percent that has not increased since the previous update. Up until that point, you joyfully updated the Gantt chart with new percentages and transcribed that into a report for management to show progress. However, once the 80-90 percent wall is hit and the project manager becomes unable to show progress, the race to get to 100 percent complete begins. As a project manager, this too always drove me crazy.
Debbie’s Dilemma
To further highlight the pervasiveness of the problem, I’ll tell a story that happened to me recently at a client site. I will describe how I handled the situation further down in the post, but for now I’ll focus on the problem. Consider the following paraphrased conversation between my client’s employee and me:
DEBBIE (not her real name): Hey Alan, you’re a Microsoft Project expert, right?
ME: I’m a little skeptical of the word “expert.” Let’s start with what you want to know.
DEBBIE: Jennifer (our manager, also not her real name) wants me to provide percent complete for all of my projects for the new CIO.
ME: Why does she want you to do that?
DEBBIE: Jennifer wants it to look nice
ME: Debbie, I gotta ask, what value does this add?
DEBBIE: (now literally almost in tears): I don’t know, but I just need to know how to do it in MS Project.
This is the state of many organizations. Management says do it, and people like Debbie do it, without understanding why. Bad behavior begets bad behavior, and Debbie’s situation is a perfect example of that.
I attended a Project Management Institute (PMI) conference a few years back, where the keynote speaker warned against the “percent complete project manager.” He said that if you are a poor project manager, you shouldn’t try to hide it because “your reputation will precede you” on a project. I was amazed that even PMI was commenting about this.
One of the core problems with predictive, plan-driven, tasked-oriented approaches is that they focus too much on the completion of tasks and not nearly enough on the delivery of overall business value.
The Agile Philosophy
To understand how the Agile philosophy looks at percent complete, we have to look back to the Agile Manifesto and its twelve principles. More specifically the following:
- Manifesto Value: Working Software over comprehensive documentation
- Manifesto Principle: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
- Manifesto Principle: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Manifesto Principle: Working software is the primary measure of progress.
- Manifesto Principle: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
An organization and/or project manager who values tracking percent complete on a project does not put a priority on the above values and principles. Non-Agile projects value delivery of tasks over frequently delivering valuable working software. They value controlling the team at the expense of trusting individuals to get the job done.
By contrast, an Agile project views percent complete as either zero or 100 percent; there is no in between. Agile projects celebrate the successes that come with delivering working increments of software based on prioritized business value, within the time frame the team said they would deliver it. When a team looks at delivering a product in this way, the tasks fade into the background and we can focus on what really matters most: building trust within the team and satisfying our customer.
A Slow Transition
Let’s return to the conversation with Debbie.
ME: OK, Debbie, I see you’re frustrated. Here is what I recommend to make it easier for you. For not started tasks, use zero percent. For started tasks, use 50 percent, and for completed tasks, use 100 percent. Does that make sense?
DEBBIE: Yes, but it doesn’t look real.
I thought “real” was an interesting word. As if percentages are ever really “real” in software development. Using the zero, 50, 100 percent model is a good way of getting out of the percentage trap and weaning management away from creating undo overhead for both the team and the project manager (or whoever is doing the status reporting).
Agree or disagree? I’d love to have your comments