Microsoft Eats the Dog Food

(In which we watch software writers improve on their Project by using it)

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.

The result: a project plan that is both more inclusive and faster to produce. "What used to take two months of doing what no one really wants to do — spending time holed up in your office, filling out a project template — now takes maybe five days," says Capossela. "In reality, project planning is unstructured and collaborative, and the software has to mimic that."

If you want the right people, you have to know what you're looking for. Every project needs a plan — but it's ultimately all about the people: Do you have the right people, with the right skills, to produce the right team? "Most project managers are probably like me," says Warren, "or at least the way I used to be. I'd wander the halls of Building 18 [the Project team's base of operations at Microsoft's Redmond, Washington campus] to see who was up for a new project."

Warren didn't want to lose what he calls the "watercooler" part of putting a project team together. But he also knew that this time around, he needed people with different skills. Project 2002 was going to be Microsoft's breakthrough opportunity, moving the software from desktops and smaller-business units into the world of big-company project management. To upgrade his own Project software, he needed new project team members — people who knew how big companies ran big projects.

But if Warren knew the kinds of backgrounds and skills that he needed, he didn't know the names of the people who had those skills. As it turned out, Microsoft ultimately had to buy some technology and recruit some key developers from eLabor to get the project done right. But the experience triggered a question in Warren's mind: Why not include a feature in Project 2002 that would allow people to input skills into the plan instead of people?

Project managers could plan for the skills they would need and when they would need them on the team — even if they didn't know exactly who would do the jobs. Then, if companies linked the Project software to their human-resource databases, project managers could conduct an efficient search for the best candidates instead of wandering by watercoolers hoping to bump into the right people. As a small embellishment, the Project team included little reminders in the software called Smart Tags that can, say, flag project managers if the people they want for their teams are busy, are in the process of reassignment, or are leaving the company. And the software program even offers suggestions for ways in which project managers can deal with change when people do make those kinds of moves.

Capossela expects the Project team to keep asking questions about its own projects, making mistakes, and looking for improvements — all in the pursuit of a better project tool for other teams. In the end, however, he acknowledges that great software alone doesn't make great projects. "Sometimes there are simply cultural issues that you've got to work your way through," Capossela says. "But if you can engender an attitude of collaboration, flexibility, and learning from the past, that's a good first step."

Sidebar: No More Speed Bumps

Garry Embleton, a business-development manager at Rhodia (formerly part of Rhône-Poulenc), a global chemicals company headquartered in France, had a problem: He needed to reduce the time it took to transfer technology to plants in Canada. "We used to think a year was normal for this type of project," Embleton says. Using Project 2002, he cut it down to two months.

For Embleton, the software — and, most importantly, the Internet access that let his global team tap in anytime they wanted — let him see all of the speed bumps that were slowing down the project.

Sometimes the bumps were just a few days. "It used to take a week to create a project plan," Embleton says. "This time we teleconferenced everyone, we launched Project 2002 on their computers, and we were done in a day." His favorite speed-bump basher? "Emails that tell you when a task is overdue," he says. "It's a great early-warning system to see when somebody hasn't done their work. Then I just pick up the phone and see what's wrong."

Add New Comment

0 Comments