Microsoft Eats the Dog Food

We live in a project world, where project managers and project teams work together to deliver results on time, on budget, on spec, and on the money. Except for one project team that uses all kinds of mistakes, questions, quandaries, and what-ifs to make everyone else's projects run more smoothly: the project team that's creating the next version of Microsoft Project, the software first released in 1990 that's designed to make it easier to live in project world.

Project's general manager, Chris Capossela, says that he uses his own project's thorniest problems, and their solutions, to run better projects everywhere. "We use the old version of Project as we're building the new one," Capossela says. "At Microsoft, we call that 'eating your own dog food,' because it forces us to see what's wrong with our own projects and what's wrong with the software." In fact, in the course of upgrading Project, the project team came across a number of important lessons and improvements that can make any project more likely to succeed.

Expect the unexpected. In the course of its own work, Capossela's team came upon the central truth of collaborative work: Most projects are derailed by unexpected problems that thwart what looked to be an on-time, on-budget operation.

As part of its own internal operations, the team often uses a homegrown database that it has dubbed Raid. Like the canned product of the same name, it is meant to help find and kill bugs -- in the code -- and keep them from multiplying.

When it came to working on its own project, the team appreciated the value of Raid. "Keeping our eye on those bugs -- those issues -- was just as important as getting something finished on time, if not more important," says Todd Warren, who served as Project's program manager before Capossela took over last year. But it wasn't until a customer told the team that his most difficult task in managing projects was handling the same kind of pesky problems that the Project team realized that it already had the solution to a key project problem. "There it was in our own backyard," Warren says. "Managing small problems could be the centerpiece of managing a project well." Now the software includes a way of tracking nagging issues and problems -- and it can be synced with a company's existing issues-management software.

Measure work done, not hours spent working. It is one of the most respected axioms in business: What gets measured is what gets done. So it stands to reason that when it comes to project management, if you want your project to get done on time, you need to measure the hours that your project team works. With that simple logic in mind, Microsoft Project included as a regular feature a time-sheet tool that helped project managers stay on top of their team's hours. Particularly for teams working a regular 9-to-5 shift, it was a useful feature -- or at least the Project team always assumed that it was.

Until, that is, Capossela's own software engineers learned that they were going to have to start filling in time sheets. They staged their own minirevolt. As professionals at their jobs, the team members said, it wasn't about how many hours they worked; it was about getting the job done. "My team asked me, Would I rather have them writing code or punching a clock?" Capossela recalls.

His response? When it comes to a team of knowledge workers, it's more important to measure the percentage of tasks that are completed than to monitor the number of hours that are worked. Now, instead of punching a digital time clock, when engineers finish writing code and ask for it to be tested, that request can be synced with Capossela's project software and automatically updated as "task complete."

Don't crack the whip; share the work. It's an unpleasant but necessary facet of every project: the manager who dictates the plan and pace for the team -- and then cracks the whip to make sure everything gets done his way. "You know," asks Capossela, "the guy who comes into your office with a crappy project schedule and says, 'This is the way the project is going to run'? That guy used to be me."

Capossela knew that there had to be a better way of setting up a project and running it so that more team members had a say in the process. At the same time, most projects seem to require a top-down, detailed approach. The big question was about how to make the Project team more collaborative without turning it into a free-for-all. To test a new approach, Capossela tried mapping out a rough calendar for his project team, but he stayed away from specifying too many details. He sent the rough draft to the team members who would be doing the work. Then, instead of insisting that the team route its email comments and suggestions back to him, Capossela had the team's feedback entered into a central project database that was then used to fill out the project plan automatically.