- Principles 1: The Essence of Driving – A Crash Course in Project Management
- Principles 2: Principles of Software Testing
- Principles 3: Principles of Software Development
- Principles 4: End-to-End Development Process
- Principles 5: End-to-End Development Process (for Large Projects)
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:
- Trend (and glide-path)
- Backlog / Burn-down List
- “Branded” status emails
- Schedule in Excel
- Schedule in Visio
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:
- Planning and kick-off
- Monitoring & Controlling
- Post-mortem learning
When I ask somebody to “drive” this or that, what I really mean is “be an effective PM of this effort”, exhibiting the following:
- Independence and accountability
- Ability to construct, communicate and get approval for a clear and well-though-out plan for the project, including:
- Scope, goals / non-goals and success criteria
- Internal and external “unmovables” and requirements
- Costs and funding
- Risks and mitigations
- Ability to set the project in motion, keep the project in motion and close down the project
- Proactive contribution of directive energy to the project, creating excitement, and identifying and removing road-blocks.
- Active monitoring of the progress of the project
- Proactive communication of status
- Ability to reach the desired results
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:
- Having a glide-path or some other indication of important milestones (e.g. B1, B2, RTM) always helps since it establishes a context for the trend and acts as a gentle “forcing function”;
- It’s a good idea to provide a title for the trend chart and names (and dimensions) for the chart’s axes except when they are self-evident (as is the case with time above).
Backlogs were popularized by Scrum and other agile project management methodologies. A backlog has two purposes:
- Keep all tasks / items associated with a particular project in a central, regularly updated location that is easy to point to, prioritize (hopefully just once in release);
- Have a “parking lot” for future items, feature requests.
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:
- Standardized subject line (e.g. “WPF 4 Pulse: Stress”) – allows people to easily filter and search for emails pertaining to that project;
- Standardized “look and feel” of the email – either by maintaining a consistent structure or by including a common logo in the email;
- Setting up a custom alias for this project only (e.g. “WPF – VS Tactics”, etc.)
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:
- Lightning fast way to communicate to your team and stakeholders where you are in relation to the whole project;
- Increases the confidence that the schedule is real and recent (if you bothered placing an arrow, you probably have ensured that you are placing it on an up-to-date schedule).
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:
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.