A co-worker of mine recently recommended an interesting book: The One-Page Project Manager by Clark A. Campbell. My initial reaction was that it sounded like a gimmicky book, but she had come up with a lot of good recommendations in the past, so I gave it a shot–and I’m glad I did.
The title of The One-Page Project Manager (OPPM) may be suggestive of more than what the book itself actually claims to solve. The book presents and explores the OPPM tool, a specialized Excel template, that turns out to be a very clever and practical way to communicate the status of a given project at certain points in time.
As a follower of agile software development philosphies (I have been an XPer for years, and am starting to be introduced to Scrum), what I immediately noticed is that this tool is a perfect compliment to these methodologies, emphasizing effective project communication over undigestible documentation. In fact, this is exactly how the authors pitch this tool, as something that augments your existing practices, not as a replacement for anything you already do.
Overview of the One-Page Project Manager
The OPPM template organizes and tracks what the author calls the “five essential elements” common to all projects:
- Tasks
- Objectives
- Timeline
- Cost
- Owners
Here is how the OPPM Excel template looks in OpenOffice:
One-Page Project Manager Excel Template in OpenOffice Calc.
As you might suspect, tasks–and the successful completion of those tasks–are the main focus of the OPPM. They are mapped to target dates, and they are also mapped to the high level business objectives of the project. Objectives are obviously the desired results of the project and they must be measureable and verifiable. And, if you can’t directly map a task to an objective, you should probably ask some tough questions about why that task should be included.
Perhaps most importantly, tasks are assigned to people who “own” those tasks, people who are accountable for completing tasks correctly, on time and on budget. And the principle owner for a task is always someone directly employed by the organization; an owner can’t be a consultant or an outsourced developer, or anyone else outside the organization. The owner of a task is plainly indicated on the OPPM for everyone on the project, including managers and stakeholders, to see. I think this is an extremely important key to engaging developers on a project, by reminding them that they will be held accountable for the tasks assigned to them. And on a well-planned project with a realistic schedule and achievable goals, having your successes documented for everyone to see is a great motivator.
Finally, the cost versus the budget is tracked as the project progresses. If anything deviates from the plan, the reasons are explained along with proposed remedies. Both performance against tasks and costs against budgets are color coded to easily spot problem areas.
The One-Page Project Manager and Agile Projects
Although the OPPM book does not specifically mention agile software development, it seems to me to be uniquely applicable to these types of projects. In fact, the OPPM has many of the same attributes as James Highsmith’s “project data sheet” (PDS) artifact described in Adaptive Software Development and Agile Project Management. The OPPM is organized in such a way that the information on the page is more easily scannable than Highsmith’s PDS, and the elements are easier to relate to each other.
Obviously, it makes sense to map target dates to the end of iteration cycles, and its at that point that the OPPM is updated and becomes an effective project feedback tool to identify potential problems as early as possible. It is also natural to treat user stories as the “major tasks” tracked in the OPPM, as these represent what is being specified, prioritized, estimated and built on the project. And agile development gives us criteria for specifying when a user story is considered “done,” including that it should be fully tested, functioning and accepted by the client. Within the framework provided by the OPPM, these aspects of the project are fully integrated into assignments, timelines and budgets.
Also, the OPPM scales to very large and very complex projects. For example, I often encounter areas of projects that are mini-projects in themselves. They may be somewhat isolated from the rest of the project, serving specific project objectives, having their own budget, stakeholders, etc. or just having more steps to implement than other tasks. In this case, a separate OPPM for that task can live “under” the top level OPPM and explicitly lists the larger task’s sub-tasks, owners, objectives, costs, etc. For that matter, any supporting documentation, such as PERT charts for example, can live “underneath” a task. Again, the OPPM compliments and supports the tools and processes already used in your organization.
The One-Page Project Manager answers more questions than it generates and is brief but succinct…One of the strengths of the One-Page Project Manager, which may be counterintuitive, is that is has just the right degree of the absense of precision…The One-Page Project Manager navigates between failing to plan and overplanning.
The One-Page Project Manager and Organizational Culture.
Even if the OPPM tool was only useful for “communicating up”, which is what it was originally designed to do, it would still be worth using. I have come to realize that if my boss looks good, I directly benefit in my job, so finding an effective way to communicate with my boss–so he is well informed about projects, he can talk about them effectively with his or her boss, and neither of them get nasty surprises–is very important.
But as I’ve already discussed, the OPPM is an effective tool for communicating with everyone–those on the project team as well as project stakeholders–and its a great way to maintain a handle on the most important measures of a project, such as deliverables and budget.
Because the OPPM was designed to work in a more traditional/generic project management approach, yet also seems to exemplify the agile philosophy, I think that everyone who sees the OPPM used will immediately see the benefits of this minimal, yet organized approach to tracking and communicating about a project. And because the OPPM easily supports other project management methods already used in your organization, the OPPM is not an overly threatening change to the organization.
But like introducing anything new to an organization (such as a new programming language or framework) the less risky and more politically savvy approach is to introduce it on a smaller project, with fewer people who you believe will be open to trying a new tool, so it has a better chance of succeeding, and then that concrete success can speak for itself.
The One-Page Project Manager, the Sequel
In addition to the original One-Page Project Manager book, there is a follow-up book by the same author, The One-Page Project Manager for IT Projects, which presents a slightly tuned version of the original OPPM and talks about its specific application to IT projects. However, I recommend that the original book be read first, or that if you only read one, that you read the original, because the original OPPM template is applicable to a wide range of projects including software development, and the original book gives a much more in-depth explanation of how to use the tool, and the philosophy behind it. In fact, if you are new to project management in general, the original OPPM book also serves as a primer on project management in general.
But, if you find the original OPPM book interesing, then by all means, read both books (they are each less than 150 pages long). And keep in mind that what they mean by “IT projects” is more encompassing than software development.