PM Skill #3: Getting Things Done

Fundamentally, a PM’s job is to get things done. If you’re going to plan and ship while keeping your team happy, you’ve got to plan, ship and keep your team happy. All of this pre-supposes you can get things done.

Getting things done isn’t magic. For example, I’m sure everyone reading these words can get something done all on their own. However, when you’re a PM, you’ve got to lead a team to get something done and that’s a little trickier. Here’s what I do:

1. Identify a problem, e.g. I don’t like doing Sudoku with pencil & paper.
2. Identify a solution, e.g. put Sudoku into Windows.
3. Identify your customers, e.g. Sudoku freaks that would prefer a better experience than pencil & paper.
4. Figure out the folks that care one way or the other, e.g. the people that decide what goes into Windows and pitch your solution, either convincing them it should be done or convincing yourself it shouldn’t. In most cases, your solution will need to change a bit to match your agenda to theirs.
5. If you still think it’s a good idea, find the folks that need to approve of the work (it may be the same folks that decide) and negotiate what success looks like, e.g. a user of Windows can choose Sudoku from the Games menu of the next version of Windows and have a happy Sudoku playing experience.
6. Find the folks that need to help, e.g. the people that actually puts things into Window, and plan the work, e.g. write Sudoku, debug Sudoku, test Sudoku, get it into the manifest of files that make up the Windows setup, etc.
7. By now, you’ve got a group of people involved with your idea. At Microsoft, these people are called stakeholders, and form the team of folks getting things done, whether it’s approving the work, enabling the work, doing the work or using the work. With these stakeholders, you need to schedule the work. Scheduling accurately is a whole other topic, but to get things moving, you basically need an owner for each and every task in your plan and you need that owner to commit to a date, e.g. you (the PM) bill spec Sudoku by 1/1/06, Bob will write Sudoku by 2/1/06, Pete will test it as Bob writes it, etc. Also, if the work is more than a month or so, break it into milestones so that people see steady progress.
8. If these people aren’t enough to get the job done in a reasonable time frame (as determined by your schedule), you’ll need to get additional resources, either by hiring or convincing other people that already work with you to spend their precious time working on your idea.
9. Now that you’ve got a set of tasks and a schedule, you need to execute. That means making sure everyone’s got what they need to do their work, including time, tools, the right information, etc. This also means gathering information about how folks are doing and sharing it with the stakeholders (a lot of them, like your boss or his boss, won’t be doing the work, but will care about it). Finally, executing as a PM means holding the schedule up in front of the individual faces on your team every once in a while and “motivating” them into living up to their commitments, where “motivation” includes encouragement, bribery, shame, nagging, reminding them what problem you’re trying to solve so as to keep them on track, etc.
10. When you’ve met your criteria of success (which will involve more stakeholders, time, tasks and/or resources than you thought), ship it. Do not forget this step! I know it’s silly, but unless you’ve got an ever-decreasing list of tasks that shows you’re getting closer to a real ship date instead of further, you’ve lost one of your major executing motivations. In fact, getting close to a goal is so important for the health of your project and your team, that you should have as much shipping in your schedule as possible, which is why must non-trivial projects are broken down into milestones, each of which you’ll share with some set of your stakeholders, e.g. daily builds stay internal while betas are shared with customers.
11. After you’ve shipped, don’t forget to post-mortem. In fact, I like to do port-mortems after each milestone. This allows you to decide what went well and poorly so you know what to repeat and what to avoid in the future. In addition to increasing your team’s knowledge so that you can do better next time (or at least not do any worse), the post-mortem is a great time to really highlight the team’s accomplishments, making sure to point out the work that individuals did. People need to know that their work is appreciated. That’s not to say you need to plunk down a chunk of Lucite on their desk, but a simple “thank you” with specifics in front of a crowd goes a long way.

As an example, after the 2005 PDC, I wanted to make sure that Avalon and Indigo worked very well together. Obviously, that’s not something I can do myself (I have check-in rights to neither team’s source code). I’m not done with this work yet, but here’s how it’s coming along:

1. Problem: Avalon and Indigo didn’t work together during my PDC talk as I would’ve liked.
2. Solution: Getting a set of Avalon/Indigo technology samples into the SDK (a technology sample is minimalistic, the SDK already has a bunch of Avalon/Indigo application samples, which attempt to show something more akin to real-world usage).
3. Customers: Developers using Avalon and Indigo together.
4. Pitch: I made my pitch to the people in charge of the SDK samples for Avalon and Indigo. They liked the idea and became my first stakeholders. They also reminded me that WinFX included Workflow, which quadrupled the pairings of technologies, i.e. from Avalon/Indigo to Avalon/Indigo, Avalon/WF, Indigo/WF and Avalon/Indigo/WF, and required an extra stakeholder. They also reminded me that I’ll want to get someone from the SDK team itself involved, because I’ll want to make sure there’s a special section in the SDK samples that lists integration samples separately from the individual technology samples.
5. Success: A set of samples that show the “right” way to integrate the technologies and meet the standard sample bar of quality, e.g. they compile, they run, they pass FxCop, etc. This definition of success reminds us that the problem isn’t that we don’t have enough samples, but that the pieces of WinFX don’t work together well enough, which is why getting architects from each technology into the room together to decide what’s “right” (and changing the technologies appropriately) is the real job. Getting samples into the SDK is just the thing we’re doing to motivate this activity.
6. Plan: We’ve got a list of samples that cover integration scenarios, what technology pairing they each cover, who owns ‘em, who’s authoring ‘em and milestone dates, e.g. code complete, architectural review, submission, SDK drop release date.
7. Schedule: We composed the schedule by looking at the samples we wanted to do, picking the releases of the SDK that we wanted to hit (different releases had different features that we wanted to integrate together) and then backing it up from their, i.e. if we want to hit the Foo CTP, the submission deadline is n, we’ll need m weeks to turn around architectural feedback, so we need to be code complete and have the review on n-m, etc.
8. Resources: Remember that this project started with just me, but now includes a decision-maker (or two) from Avalon, Indigo, Workflow and the SDK as well as sample authors and point people to get individual tasks done. In addition, there’s my boss and the bosses of all of the folks doing the work that have to approve how folks spend their time, all of whom have to be kept informed and can have input to the process. Some folks are part of the team because they were convinced of the importance of the work and some are part of the team because their bosses were convinced and asked them to participate, but none of them work for me. It’s common for a PM to run a project composed entirely of people that don’t work for them, so sharpen up your people skills.
9. Execute: We meet semi-weekly to make sure we’re still on track and to identify any addition tasks and owners, e.g. adding the new section to the SDK, etc. Also, I’m the author of a bunch of the samples, so I have to meet the deadlines personally. As the PM, if I don’t meet my own deadlines, I’ve got no leg to stand on when I ask others to meet theirs.
10. Ship: We’re coming up on the first code complete deadline, which was delayed a bit because we needed a stable internal build of a WinFX CTP that we’re targeting to have the first set of samples placed into. Once we get the first set running on the right CTP, we’ll review, fix problems in the samples, file architectural issues we discover in the review process as bugs against the individual technologies, submit the samples to the SDK team for their quality check and out it goes!
11. Post-Mortem: We haven’t done this yet, but I things I expect to see come out of it is how to keep this work going. There are lots of combinations of technologies that we promote at Microsoft and there needs to be a way to make sure that they work well together, which, after all, was the whole point of this exercise.