“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.

Leave a Reply

Your email address will not be published. Required fields are marked *