What even is a project plan?

Or perhaps the more important question is, what should a project plan be?

I could have availed myself of a lot of the existing literature before committing pen to paper on this but I have chosen not to. After the best part of 20 years creating, maintaining, publishing and delivering on plans – I should be able to wing this. You, the audience, can be the judge.

I’ve maintained for some time that the project management domain has a habit of supplying 100% of the information required to 5% of the people that need it (and only some of the time at that). Surely we want one plan for everyone not lots of different plans for just a subset of the organisation which invariably is what we have now. I should know – I am just as much a contributor to this froth as anyone.

What are the hallmarks of a good plan?

1. A plan must be easy to understand and clear
2. It must be sufficiently detailed and up-to-date enough. Too much detail is probably as big a problem as not enough.*
3. It needs to be dynamic with low friction mechanisms for updates as revisions are made to the plan.
4. It must communicate and engage. It must inform**.
5. It must not be prohibitively costly
6. The plan shouldn’t demand too much from consumers. If the cognitive load is high – it’s going to to be a barrier to adoption.
7. We should exploit existing data sets and wherever possible, not create new ones.
8. Just like street map – we don’t have multiple different versions.
9. It should support stakeholders who want the headlines and those that want the detail (ideally, in the same plan).
10. We want some level of traceability. Where did this activity come from? Who’s sponsoring it? What is the status of this activity?
11. I might want to tailor or customise my plan so that it supports my preferences and priorities.

*I haven’t come across a setting in which there is a demonstrable requirement for real-time project plans. Does such a setting exist?

**Sounds simple but it’s amazing how many plans don’t do these simple things.

This is a long list but it isn’t an exhaustive list. What have I missed?

Something else to reflect on is that the requirements listed here are not functional requirements (what the plan does). They are non-functional requirements (i.e. what the plan is). You might think you can enhance your existing plans and planning tools to serve these objectives and maybe you can. But if the architecture of your software solution won’t support these non-functional requirements – then you’ll be going back to the drawing board.

If you get your plans right, things that typically are difficult become easy (or easier at least). Stakeholder engagement and communication, smoothing and optimizing the portfolio, capacity and capability management and a host of other things.

Omnivisto recognises that few plans address the objectives described here. The main reason for this is that there genuinely hasn’t been the means to do so. Not easily, cheaply or sustainably at any rate. That is why Omnivisto is conspicuously different. It’s not a gimmick. It has been architected to meet the breath of challenges that face those trying to create, maintain and publish plans. To do that, Omnivisto went back to the drawing board and the Vistogram either supports the requirements above or the means to do it is already baked in.

How do your project plans measure up in comparison?