“One of the key skills that every- body in a project needs to develop is to know when to ship the product.”

Paul Garner, Program

Manager, Outlook, Microsoft Corporation

A project is dependent entirely on the

management skills of its leader. And a Microsoft product development project is a good

example where even the skills of the best are tested. Paul Garner managed the Outlook and

Office 2000 product development projects and DATAQUEST solicited answers on many of the

taxing issues faced during the project. Prior to that, from 1994 to 1997, Garner was

Program Manager of the Exchange Product Unit. And from 1991 to 1994, worked as Senior

Consultant with MCS in UK. Excerpts of the interview:

What characterizes a Microsoft product

development project?



I guess the key things are our efforts for customer feedback–making sure we are
interacting with customers, getting a lot of feedback and integrating that into the

product. The other is innovation. We drive hard to ensure that we are innovating every

release we build. 






Okay, that describes the product itself. But what is different in a Microsoft project?


Well, probably the size of it. A lot of our projects are large and we have a huge focus on
testing. We spend a lot of time and a lot of effort building test matrices, test scenarios

and going through those test scenarios time and time again through the development cycle.

We have a test-to-developer ratio of about 1.2 testers per developer, which is

significant. This is greater than what you would find elsewhere in the software industry.






How often is user feedback built into the product development projects?



Throughout the project. We have a feedback process with our support groups, which is

an escalation process. There are user groups that we monitor. We interact with customers

on a one-on-one basis so that we really understand the requirements and understand what

they have trouble with. There are always things they have trouble with. And then we put

down what our priorities are for the next release. We are doing that all the way through

the release. 



As we move through the development cycle, we do alpha and beta releases that we ship out
to a number of customers. Usually the first one is to a relatively small number of

customers. Typically these are people we know we can rely on to give us lots of good

feedback. We take that feedback into account and we change what we are doing. We

re-prioritize. 






How are product development cycles phased out?



We start the planning process a couple of months before the next product release. But

they are very discrete project cycles.






So what are the skills a Microsoft project manager needs to have?



Firstly, to experience the industry, understanding customers’ requirements and

bringing those to bear on future decisions.






Is that only your responsibility or is there somebody else who also interprets the
feedback?




It is primarily the project manager’s responsibility to do that. There are other
people in development–developers, software engineers and testers who also need to

understand customer requirements. They work very hard to do that.






Coming back to skills required for managing a Microsoft project...



We talked about understanding customer requirements, understanding the market,

understanding competition and bringing that view into the project. The second is

day-to-day management of the project, scheduling, making decisions on feature

prioritization and on bugs that need to get fixed, how we go about fixing bugs, resolving

problems and troubleshooting.






What about the people management part? 



We have a very interactive process and spend a lot of time with developers and

testers, making priorities clear and working out issues as they arise. The development

team regards the product management team as their troubleshooters.






Do you need to get to an individual level to manage the project?



Yes, there is a certain understanding of how individuals in the team work and how

teams within the team work.





As a project manager, how do you ensure sufficient team building?



We have a lot of fun. One of the goals that we have is to make sure that people are

having fun—they are enjoying what they are doing. That they are empowered to do what
they do is very important for us. To make sure that people feel like they are impacting

the product, that they are not just driving code out of the door, that they are empowered

to make decisions on design and come up with ideas.






What would you regard as a key skill in the product development project?



One of the key skills that everybody involved in a project needs to develop is the

ability to know when to ship the product—to actually close it down, stop developing

the next little feature. Making sure the quality and the features in the product are right

rather than the tendency to keep adding new stuff. That is a hard skill to learn. It is

very tempting to keep on adding features. 



We also have a hard core postmortem address at the end of each project, where we formally
review the project. We understand what went wrong, where it went wrong, why it went wrong

and if there is something we can do.






Are there any particular learning points that have come up from your past experiences?


...I am trying to think of something that is explainable—so much of it is tightly
bound into the fabric of the project that it wouldn’t really make sense outside it. I

can give you an example. For the Office 2000 project, we centralized our spec management.

We have a spec server where all specs are placed and managed through a lifecycle of their

own. So we increased the discipline we apply to spec management for the Office2000 release

and that reaped benefits in terms of making sure the schedules were correct and that

features were woven together.






How do you plan out a development project?



We have a number of different matrices for a number of different variables. Sometimes

we have a release date to every cycle, so we know roughly when the market requires a new

release. There is also a given set of features that we absolutely need to deliver or the

must-have features for the next release. Then there is the people variable—how many

people would be available or what’s the most effective number of people to have

because it is not necessarily linear. Adding more people to the project to get more done

can be counterproductive. So having the right sized chunks of project to go with the right

number of people is important.

We review things that are going on in

the  company—like innovations that are being carried on elsewhere.






How would you become aware of other efforts in product development and innovation?


We have a very comprehensive internal website where a lot of information is posted. Then
of course, there is personal interaction, and we do a lot of that across groups, across

divisions. So it varies from a highly structured approach to very adhoc. We also do

research externally—with competitors, with analysts, with individual users and with

user groups. We do field studies and usability testing.






l Suppose you were to obtain feedback from user groups, analysts and media. Which would
you rank as the most important?




Across Microsoft, it has to be said our customers probably have the greatest weight. They
are the people we listen to more than anyone else. It can be end users, IT departments or

executives within the organization, who give us input on what their business requirements

are and what value they want us to deliver. So that is probably the highest priority

feedback for us. That is probably the thing we work at hardest.