Tracking Multiple Estimates with Project

MS Project is a powerful tool. However, it has certain expectations about tasks, and deviating from them can be difficult. For instance, Project presumes tasks have a single work amount and duration.

I prefer multiple estimates. I typically ask developers for a realistic and a pessimistic estimate (i.e., "should be done by, could take as long as"). Then, I also track a weighted estimate somewhere between these, based on my confidence in the given estimates. Finally, I want a projected duration based on how long the work has taken so far (e.g., if a task is half done in a week, the projection should be two weeks).

Since Project expects only one work/duration value, tracking progress and making predictions against multiple estimates is hard. You can create extra columns for them, but these don't integrate well with many features, such as Gantt charts. And, as far as I can tell, the projected duration isn't a built-in option.

To work around these issues, I created a Project 2010 template that lets me track work items with multiple estimates. The key advantages are:

• Easy pessimistic/optimistic/etc estimates, Gantt charts, and end dates.
  
• Projected estimate based on how long tasks have taken so far.
  
• Simple steps to track progress, whether reported as percent done or time left.
  

Here are links to the template and to instructions. I think it's fairly easy to use, but I'm very interested in any feedback. If you give it a try, let me know!

---

Edit: A commenter requested a Project 2007 version of the template, so I've put one here. However, not having actually used it myself in Project 2007, I can't guarantee how well it'll work.

Read more... Collapse post...

Productive Tension, Checks and Balances

Many software houses have caught on to using separate teams for writing and testing code. This is a great example of building productive tension: developers take pride in writing code with no bugs, and testers take pride in catching bugs the developers missed. This is one of the checks and balances that leads to better software.

Recently, I've been thinking about how one beauty of the program manager role is that it adds its own dimension to this productive tension. The key is that PMs champion the customer when designing functionality, yet have no authority over developers and testers. I've seen this build productive tension in two ways.

The first is a tension over design. Part of a PM's job is to empathize with customers. We want to listen to their asks, anticipate what they need, and design conceptually clean and complete features. In other words, we worry first about customer functionality, then about implementation. However, developers worry first about tractable features, then about "ideal" functionality. This difference in primary goals builds productive tension. But the overall overlap in goals means the design iterates until the PM feels pretty good about the customer functionality, and the developers feel pretty good about tractability. Since each role champions a different goal, both desirable, the result tends to be good compromises.

The second is a tension between influence and authority. While the PM is responsible for designing features, he cannot tell developers and testers "do it or leave". He's not their manager. At the same time, their manager does not design functionality (though he or she typically has valuable input). The result is that no functional design is by mandate: if the PM has an idea, he has to convince the developers, testers, and their managers; if the manager has an idea, he or she has to convince the PM. Having to convince several other smart people, over whom you have no authority, is a great way to select for good ideas.

These are the ways I've noticed PMs contributing to productive tension, and to the checks and balances that make for good software. Anything else I should look for?

Read more... Collapse post...

Nice thing about PMing at SQL Server

Fair warning: shameless plug ahead.

Groups within Microsoft vary widely, including everything from the culture, to the engineering process...even the acronyms. Makes it hard to paint the whole company with one brush.

For instance, take SQL Server. We're not the 500lb gorilla; that's Oracle. In the database arena, we're one of the scrappy underdogs, and it shows in the culture. At the same time, our division is one of Microsoft's established workhorses; we're not an experimental foray into a new business. That also shows in the culture.

It's an interesting combination. It gives us constant drive and motivation, but directed by a maturity that comes from knowing we impact the company's bottom line. As a PM, I really feel both of these factors. I'm always encouraged to think about differentiating, and solving the biggest customer pain points. At the same time, I know we're working on cool stuff that will actually make a difference.

Read more... Collapse post...

Defining Program Management

I joined Microsoft SQL Server as a Program Manager in January. Before then, my direct PM experience was herding 20 undergraduates into developing a video game for a class, reading parts of "The Art of Project Management", and preparing for the Microsoft interview. In other words, I'm still very new at this.

About the first thing I learned is that the PM role is hard to define (which is part of what makes it fun).

I've heard developers describe their role as "we fix bugs", and testers as "we find bugs". Oversimplified, but, given a broad enough definition of "bugs", mostly accurate. It's harder for PMs. "We write specs" fits the pattern, but no definition of "spec" covers most of what we do. Scott Burken renamed his book "Making Thing Happen", but that's not really concrete. A developer friend suggested "we schedule meetings", which, while funny, isn't very specific.

In an effort to understand and communicate the role, here's a list of what I think it means to be a PM (which, by the way, is a very PM-ish thing to do). The goal is to keep it updated over time, and to track the changes.

What do you think? Anything I should add to or take off the list?

So, what do Program Managers do? I (currently) think

• We make things easier: for customers, by designing good features; for engineers, by getting stuff out of their way; for managers, by abstracting away the project's day-to-day; for sales, by differentiating and evangelizing.
• We (try to) understand customers: listen to them, shadow them, think like them, and champion them.
• We drive consensus: get stakeholders to agree on a vision.
• We champion the vision: keep the project on-target.
• We understand the business: how do we differentiate? What's the next big thing?
• We design the functionality: specify what the feature does, and help developers design how it does it.
• We project manage: plan the project, track progress, and manage risks.
• We explain things: communicate between engineering, customer, and business worlds, through presentations and writing.
• We evangelize: get people excited about the project.

Read more... Collapse post...