Earned value, percent complete, and other measures of work performed on a project have always seemed useless. Perhaps that’s why I like Scrum so much–it only requires participants to estimate the hours of work remaining. Johanna Rothman wrote a short but important piece: Managing Product Development: There is No Such Thing as Percent Complete. While some of the comments are critical, I think they highlight the real challenges of giving a percentage. To pull out two:

The difference between Physical Percent Complete and Percent Complete needs to be clarified. On software projects where the delivered features are produced through Work Packages the comcept of Physical Percent Complete can be used. (Glen B. Alleman)

This is only a problem if you take the percentage as a percentage of time. A percentage of requirements fulfilled works just fine. (Michael Lucas Smith)

To be confident in % complete, you need to be confident in your estimates, in the amount of work completed, in the amount of work remaining, and in the speed at which the remaining work can be completed. That’s a lot of moving parts and merely watching the percentage change over time provides little insight into those underlying numbers.

When you ask a team member for percent complete, you’re generally only trying to learn two things: when will their work be completed and how will that timeline affect other parts of the overall project. Ask only the questions you need answered and you’re more likely to get the answers you need. The fact that it takes less effort to answer smaller and narrower questions is just gravy.

Photo by juliehicks75

Classic new product development starts with features, functionality, and quality. Customer needs are surveyed and researched, requirements are written, prototypes are designed and analyzed…and the entire effort is either time-boxed or budget-boxed, depending on the industry. Good companies know whether time or cost is more important, but those are generally secondary to actual functionality or final product qualities.

I’d like to propose that for emerging and innovation-driven markets–like high tech–features and functionality represent the least important corner of the triangle. I think that some of the most innovative companies start by specifying the cost and timeline for new product development, and take a more hands-off approach to actual functionality. Companies like Google and 3M, which explicitly require employees to devote time to personal projects (PDF) already do this. Events like Hackday are even more explicit.

The different product development focus looks a lot like Agile software development methodologies. Instead of asking, “What should our new product be?” it asks, “What cool things can we do cheaply?” I think this makes the most sense in innovation-focused markets because these are places where we know the least about what customers really want. The less you know about what customers really want, the less value you can expect to get from a product specification process. Agile methodologies, similarly, teach us that it’s unlikely you’ll get anything right on the first try, so you’d better make each iteration quick and cheap (Google cache) so that you can get it in front of a customer as quickly as possible.

Even though this kind of product development may make sense for technology companies, it will be seen as a challenge to the traditional product management role. Their job no longer consists of telling people what to do. Since essentially they’re being handed stuff (Engineer: “I noticed that with only a few more lines of code, our Wiki software would make a pretty good MS Project killer!”) they become advocates, influencers, cajolers,  and evangelists. It becomes a zen role: each new product becomes a surprise, an opportunity you cannot own, and a leap of faith to let others do what you had believed was your job.

The reward is profitability. The high-margin reward of being “first mover” can be overwhelmed by the sunk costs of the product development process. Explicitly starting by minimizing costs and decreasing cycle time means your margin of success is lower.

I’ve written about it before, but Tom DeMarco’s book Slack addresses this very issue. According to DeMarco, these sorts of interruptions are part of business. He likes Agile methodologies, but his solution is more straightforward: make sure your teams has enough Slack, the free time to do unscheduled and unplanned work.

“From Manufacturing to MIS and Medicine: The Theory of Constraints in Knowledge Industries”

“Limits of the Balance Sheet: How Financial Reports can Obscure Operational Problems”

“Aligning Operations and Strategy using the Discipline of the Project Triangle”