I’ve built a lot of project plans over the last couple of decades. I love a good project plan. I’ll get my coat! The thing is, a proper project plan is a beautiful thing. No really. I imagine many who haven’t built a project plan, even if they’ve seen them, might shrug and say ‘So what? How big a deal is a list of tasks with dates?’.  If you’re not a project manager, but work with PMs, I’d love you to read on and then evaluate your current level of appreciation.

A list of tasks with dates is, for sure, no big deal. But a proper project plan is a very, very big deal and it takes a lot of time, effort, thinking, dedication and determination to build it. It takes some time and effort to maintain and evolve it, but if you take the time to build it properly in the first place, tracking, managing, updating and refining should be straightforward and painless.

I’ve worked with a lot of other PMs and encountered their plans. There’s scope for huge variation in approach and attention to detail and this I have seen. At the more disappointing end of the spectrum I’ve seen plans with tasks that had no due date. I kid you not. I’ve seen plenty where PMs don’t bother to estimate the hours effort for tasks or size them in any way. I’ve seen frequent examples of no use of dependencies and scheduling automation. Simply manually entered dates that therefore require a substantial ongoing effort to update when anything changes, and don’t have any obvious basis to derive the dates in the first place.

There are lots of tools out there and maybe one of the factors in disappointing levels of detail is some of them can be a tad frustrating in terms of how they mess up your plan when you try to automate the scheduling and when you try to size the effort. I sense that might have led to some PMs not bothering to make their plan beautiful, because what’s the point when the software messes with it all the time? Or perhaps there are a few PMs out there that place a lower value on a beautiful plan, and figure it’s more about leading and managing and making sure the work gets done. Let’s agree to differ. You need both and you can be far more effective with the latter when you have the former.

A proper plan needs some fundamental components beyond the obvious list of tasks with dates, as follows:

1. Structure. A structure that reflects the structure of the project itself and the required delivery, whether phases, sprints, master processes or something else. Without this, it’s much more difficult to assess and communicate the health and status of a project in a language palatable to stakeholders.
2. Sizing of tasks. If you don’t size a task, ideally with a level of effort, then any assessment of work complete to date and whether or not you are where you need to be, is going to be much more arbitrary and essentially unreliable, resulting in far less predictable go live dates.
3. Automated scheduling. This is critically important. If you don’t create the dependencies between tasks, the duration and other attributes such as lag, that contribute to dates automation, you don’t have a plan. Those scheduling attributes are the skeleton that holds the whole plan together, that actually make it one dynamic, beautiful entity, not just a list of tasks. And if done well, it makes managing your plan ongoing an absolute dream. Immediately see the impact of any changes you make to dates in tasks and spend your time resolving any scheduling or timeline challenges instead of sitting there figuring out every time which other dates need to move. It also means that you can review and refine task sizing and durations based on ongoing actual performance. In my view there is a balance to be struck here, and weaving a web of many and varied dependencies between tasks can be as challenging as not having any at all. If you can’t immediately decipher why a date further on has changed, then again your plan is inefficient.
4. Tracking of percentage complete, at task level and at project component and overall level. This, as said, is only truly meaningful if you have sized the effort.
5. Actual resource allocation. As PMs we normally are supposed to be the ones that make the ongoing judgement that about how we’re tracking and whether or not our current resources are sufficient and optimal for target delivery. So obviously the plan needs to have tasks allocated to resources.
6. Milestones. Those key targets down the road at various critical junctures in the project that should focus you and your team on where you need to be and what should have been accomplished by now, and how you’re all doing versus those goals.

In terms of the actual plan, those are the main attributes. There are other processes your plan can and should drive of course, such as the resource utilisation and evaluation and refinement thereof, possibly budget management. But consider just the plan itself. It’s not unusual to have a thousand actual tasks and milestones in a plan. Such a plan might have 1200 lines or more, with parent tasks included in the count. In an effective tool and plan, you shouldn’t need to spend too much time on parent tasks, so let’s just talk about the thousand. For each task, you might need the following:

• A phase or project component, possibly two or even three task structure levels. Let’s use two as an average.
• A description.
• Dependent tasks, possibly more than one in some cases. Let’s use 1.5 as an average.
• Probably an additional attribute that defines the nature of the dependency.
• A duration.
• Hours effort or some other sizing method.
• A resource, possibly multiple resources in some tools, but let’s assume one. I’ve built a tool that allows you to still enter one attribute for multiple resources by configuring teams.
• A lag, an additional attribute that allows you to flex the dependency rather than making it completely literal.
• Ongoing you’ll need a percentage complete, but that’s part of the ongoing maintenance, not the build.

So, actual child tasks need 9.5 attributes and parent tasks 3 or 4, when a plan is first built. So  we’re talking in the above example about approaching 15,000 fields to be populated, essentially manually, a lot of them with some thought and consideration. Ongoing we might maintain percentage complete an average of ten times on each task, so that’s another circa 10,000 maintenance points. Tens of thousands of component parts. And if those components are built well, it can and will work like a beautifully oiled machine. if you build it that way, ongoing maintenance will be mainly percentage complete and refining some scheduling drivers. You can watch the ripples running through when you change something. Evaluate what action you then might need to take, and again only make one or two changes and ensure the ripples you then get are the ones you want. It’s like a living, breathing organism.  Because you’ve given it life. If you shortcut the build, you’ll likely be manually maintaining many hundreds of dates many times over. Not a living thing. Not a beautiful thing. A tedious inanimate object.

So if you’re waiting for a project plan from a project manager, and you’re wondering why it’s taking the lazy waster so long to get it finished, you might be right. They might be a lazy waster building a tedious inanimate object. Or you might be in luck. When it is finished it might be a beautiful work of science and art and you might have a highly successful project, to a substantial degree as a result of your beautiful plan.