November 23, 2010
How to Get Away from Percent Complete
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 have also, 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:Email sign up
- 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.