About a year ago, I got feedback from my team that I needed to clarify what I meant by “drive this effort” or ���lead that effort”. So I decided to create a quick document explaining what I meant. Below is that document. I later converted the document to a slide-deck, which is also available at the end of the post.
There are *a lot* of books on project management. From that point of view, there is nothing special about the techniques below – all of them are pretty much common sense and all of them can be found in those books. What is special about the post that follows is the condensed presentation (my goal is to essentially save you from reading a PMP book) and the fact that we actually used every single one of these techniques to manage the WPF 4 and Visual Studio 2010 products, which we released in April 2010.
The techniques listed below are:
Project management is a skill that can (as any other skill) be acquired and improved. Really most of our work and a significant part of our personal lives boil down in one way or another to project management.
Every project has a life-cycle, consisting of several standard phases:
An effective PM understands and actively manages the life-cycle of a project.
When I ask somebody to “drive” this or that, what I really mean is “be an effective PM of this effort”, exhibiting the following:
These are the standard milestones of a project. Simpler projects can certainly be managed without necessarily differentiating between some of the milestones.
It is important to note that there are project management techniques out there that try to simplify the model above. Such simplifications are often based on “hardcoded rules” e.g. (“each project cycle takes exactly 4 weeks”, etc.) It’s also important to note that not all projects require all of the “line items” above delivered explicitly. Most projects do require them at least in implicit form though.
Depending on the specific project, some of the activities may or may not be required. Below are two example projects that demonstrate how to use the template above.
Keeping good communication throughout the project is a common-sense technique. It is, however, surprisingly rare. So, as a good rule of thumb, always over-communicate your project status. Don’t worry -- you will inevitably hear from your manager and other major stakeholders if you truly are spamming everybody, but I guarantee that would never happen.
Scorecards provide a way to track progress against a set of success criteria. Scorecards are often presented in time, although that may not be always possible or meaningful. Here is a sample scorecard:
You can track both “qualitative assessments” (e.g. “gut-feel of main stakeholders”) as well as “quantitative observables” (e.g. “number of defects”). When rating the progress, it’s useful to use a 4-level scheme similar to the one below. Excel’s conditional formatting feature makes construction of scorecards fairly easy.
Glide-paths are a common way of graphically displaying change in time of one or more observables in an attempt to inform future progress. Here are a few examples:
Note a few important details:
Backlogs were popularized by Scrum and other agile project management methodologies. A backlog has two purposes:
Here is a sample backlog:
The average engineer at Microsoft receives between 200 and 300 emails every day. One way to allow stakeholders and observers to easily monitor the progress of a project you are managing is to “brand” the emails related to that project. Examples of “branding” include:
Excel presents an easy way to construct schedules. These typically have a “From”, “To” and “Length” columns. Here is an example:
More complicated schedules typically require the introduction of a “Type” (of event) column, to allow filtering per type, thus making your schedules easier to grasp. Using “tables” in Excel makes the constructed schedules easily “filterable”.
What Excel schedules lack is a graphical representation of scaled time periods. This is where Visio schedules excel. Here is a sample.
It’s often very helpful to complement this with a “we are here” arrow:
The arrow accomplished several things:
Good project managers are hard to find. Partly, because good project managers grow through experience. Invariably though, through experience, they (or at least the ones I have observed) tend to gravitate to the same basic techniques – the ones you see above. Hopefully, you will find these helpful.
In case you haven’t noticed, I love Excel. I use it as my main project management tool. My wife is a construction project manager and she constantly bugs me about not using Microsoft Project. Project is a fine product and I have in fact used it for some of the more complicated projects I have managed. What I love about Excel is its simplicity, integration (charts) and high-availability (Excel files are viewable on any device).
Some manage their projects using databases and web sites. I still prefer Excel. The reason? Versioning. With Excel (or Project), all you need to do is check in the corresponding file in your SCM (source code management) system. Databases are harder to version.
Finally, here’s a pointer to the slide-deck accompanying this document as well as a sample Feature Backlog spreadsheet:
PM in this context refers to any “project manager” (a lead or an individual contributor in any disciplines tasked with “driving” something), not just a Microsoft PM.
VMI (Vision-Mission-Identity) is something that is often neglected, mostly because project teams tend to eventually infer these themselves. VMI is, however, a major part of the branding of the project and the project team and tends to have a very positive impact on driving ownership into and empowering of the team members. In practical terms, VMI is answering the questions “what is the ideal outcome of the project (e.g. “deliver the best text on any platform”), who are we (e.g. “we are the team, enabling clear text in VS 2010”), and why are we the right team to do it.