Simple is powerful. But getting to simple is a challenge. It’s an interesting challenge, mind you, but it’s a challenge nonetheless.
Last week, I explored the power of simple models. I also made the point that many templates (particularly—but not exclusively—in the field of project management) are often the opposite of simple.
So I thought I would try an experiment of a sort. What would a simple project management template look like? What would the essence of template be? In particular, if you adapted the philosophy that underlies a model like Business Model Generation, and adapted it to thinking about the world of projects, what might you arrive at?
While the over-the-top example I employed in discussing the power of simplicity was a status report, doing that would be a cop out. The essence of status is relatively straightforward, all attempts to add complexity, detail and impenetrable overwork notwithstanding. You can provide a high level comparison of current status to plan, and flag any variances. You can use stop-light indicators. Even a brief highlight of progress, current challenges and next steps (the essence of a good verbal status update) can work.
So let’s tackle something traditionally seen as a little more complex. Something like a project plan, for example. Normally these are complex and cumbersome documents. I’ve seen plans that have filled whole binders. Even when we get our page count below triple-digits, they often still weigh in at 50-plus pages more often than they do 11 or 12 pages. Every once in a while, I’ll see a project plan that is only two or three pages. This isn’t to say that can’t be a viable document. The smaller documents often come with a sheepish expression and a “Sorry it’s not more detailed; we’re not very formal around here.”
There are some fascinating implications there. Somewhere deep in our project management souls, we’ve been coaxed or coached to think that detailed equals good. That the impressiveness of a document is directly proportional to the weightiness of the “thunk” it makes when it hits the desk.
The challenge with that is that it takes a great deal of time to write documents like that. It also takes a great deal of time to read, review and critically think about a plan like that. In fact, that’s some of the criticism that was (legitimately) lobbed at what were perceived as “high ceremony” practices by the agile crowd. Many deliverables required significant effort to produce, without any commensurate delivery of value. Many reviewers—including approving project sponsors—often go for the highlights in the executive summary and ignore the rest.
So what would an optimal project plan look like? How should it be structured? For the purposes of this thought experiment, it should be accessible, clear, and understandable. It should provide sufficient information to be able to comprehend the project, without being overwhelming. Above all, it should be coherent.
Those ideas led me to some basic criteria. Leveraging the structure and value that Business Model Generation demonstrates in articulating business models, I wanted the result to be graphical. I wanted it to fit on one page. I wanted to get to the essence of project plan; to define the essential information you need to manage, and that a sponsor needs to approve it. I wanted it to be comprehensive enough to be formal (if you wanted it to be) and flexible enough that you could have some fun with it.
What I came up with is this:
To tackle first questions first: Why a triangle? Wouldn’t something boxy be better (or at least give you more space to work with)? Arguably, a rectangle could maximize paper real estate. But boxes are boring. And while I could make up some abstract conceptual mumbo jumbo about a triangle representing an arrow that provides direction and momentum in honing in on the north star of your purpose, that would be facile, mocking and largely erroneous. So let’s forget I ever made up that sentence, shall we?
A triangle wasn’t an accident. As I said, I wanted coherence. And I wanted the apex to focus attention on the essential question of, “Just what are you doing this project in order to get?” In building the structure, I’m blatantly ripping off the conceptual framework of Maslow’s hierarchy of needs (which is often presented in a triangular format).
According to Maslow, each underpinning layer of needs is an essential foundation to the next layer; you can’t get to self-actualization if your essential needs of food, clothing and shelter aren’t take care of. Maslow started at the bottom and worked up. Here, I’m doing the opposite. I’m starting at the top, and working down. Each layer is a progressive elaboration on the one before it, and answers the next logical question in defining the project you’re proposing.
From objective we get to value. Once you are clear about what the project is supposed to do, there needs to be a supporting rationale of why you are doing it. And I’ve been very explicit about intangible value taking equal prominence with tangible value. Sure, I want to know hard returns that I can expect. But I also want to understand what else I’m going to get. While business schools might teach ROI, the intangible reasons for doing a project are often the most important ones.
Then we get to the specifics of what will happen during the project, and what won’t. The astute amongst you will recognize this for what it is: scope. In fact, the phrasing implicitly guides the definition of product scope (what you’ll get) as well as project scope (what you’ll do). And you get extra bonus points for recognizing that while the next level represents scope, it isn’t actually called scope. In fact I very deliberately haven’t used any project management term (with the possible but defensible exception of “objective”) in the entire structure.
After defining what you’ll do, we need to know what it will take to actually make things happen. And so we have spaces for time, money, people and stuff. The essential definition of the resources required to make the project happen. Here, as in every other part of the model, you don’t have a lot of space. You’re going to have to be concise. There will be no Gantt charts or spreadsheets reduced to micro-dots and placed in those boxes. I want simple, clear definitions of what you need in order for the project to get done.
Lastly, we talk about what might happen. In other words, we consider risk. And this is again a deliberate foundation, one I’ve chose as the base platform for my plan model. Research demonstrates that managing risk is one of the most essential and valuable tools in the arsenal of project managers. We ignore it at our peril. (See what I did there?)
Again, I’ve avoided using the formal terms of risk management. There is no consideration of avoidance, transference, mitigation or acceptance. And again, that’s a choice. In my view, the essence of what matters is understanding what might happen, and then making some fundamental choices: what are you going to proactively do in advance, based on what might happen? And for the rest, what are your plans to respond if the factors of uncertainty become a reality?
As with all models, we need to think about what is getting highlighted, and what is being omitted. This is my personal view (the result of ruminating over the last week, and a short stint in a coffee shop) on the essence of project plans. Someone else would invariably produce something different. But you need to defend your choices: both what you include, and what you omit.
So what’s not there? There is no detailed schedule. There is no detailed budget. There is no work breakdown structure, or activity plan or deliverable register. I haven’t included a RACI chart, and I haven’t even dreamed of doing a resource loading. There is no critical path analysis. And you couldn’t get to an earned value analysis from here if your life depended on it.
All of the above is deliberate. And there’s another consideration at work here: if I was presenting a project plan to an executive team or sponsor, none of that information would be on the table. Or on a presentation slide. In fact, what I would present is pretty much what I’ve defined.
That highlights an important point. The plan as I’ve outlined it is a communications tool. It is not a working document. Just like the business model template that it inspired it, this is a way to summarize and highlight what matters, while not distracting from the detail that—if we are very honest about it—doesn’t matter right now.
So what about the detail? Yes, you need to know it. You can’t get to this level of clarity about a project without having done your homework. You need to do your analysis. Somewhere, there will be a work breakdown structure of sorts (mine is very often a hand-drawn mind-map). There will be estimates of effort and time (and again, I’m usually relying on handwritten notations on that self-same mind-map). At some point, you’ll need to lay out the work over time to figure out if the schedule is workable.
While the working through is necessary, that doesn’t mean it needs to show up in the plan by which you represent—or present—the project. Doing so is essentially the same as (and, in my humble opinion) equally annoying as having to show your work solving an algebra equation. If the problem is solving for ‘x’ then let me get to the answer. How I get to the answer is less relevant (and caring about how smacks a bit too much of micromanagement).
As I said at the outset, this is a thought experiment. It’s a deep dive into how we can take the principle of simple models and apply them to our work in a way that is meaningful and relevant. Would I recommend actually using this plan? Quite possibly. While that wasn’t my objective in building it, the result is workable. And if it’s relevant and appropriate, then there is no reason not to.
Choosing to use something like this is about exactly that: making a choice. Does this help, or does it hinder? Does it highlight what matters? And does it remove to the background the things that are less important or unnecessary distractions to getting a good decision. That’s the essence of what good models do. And it’s exactly the problem that long, weighty and voluminous documents lose sight of.