Make an educated guess
In their hugely successful book ‘Rework‘, Jason Fried and David Heinemeier Hansson write “planning is guessing“. Wow. Hang on. Imagine a project management methodology without a planning process, a Project Manager without a plan… This would probably get you a ban-for-life sentence from PMI, yet, there is something logically true in Fried & Heinemeier Hansson’s statement: planning is guesswork and as PMs we need to make an educated guess (all those known/unknowns unknowns…). So when it comes to communications, this makes project plans amongst the toughest – and vital – pieces of information we need to share with our stakeholders.
By the way, even if you could manage a project without a plan, you’d still need one because your stakeholders would struggle giving you any time (or money!) if you didn’t have a plan to show them. People want to see plans: they represent something tangible, something that gives people confidence that there is (some form of) direction and control. Of course by nature a plan is pretty much out of date by the time someone has seen it, so it’s essential PMs can communicate very clearly about changes.
Whose plan is it anyway?
In practice, not everybody has the same information needs when it comes to project plans because not everybody cares about the same things: some milestones critical to some may be of no significance to others, and some people may need to understand a lot of details whilst others only want a high-level picture. The reality is that (most) people are only interested in the part of the plan that affects them.
Consider the following examples on typical IT projects:
- implementation of a new sales force automation system: the infrastructure manager is not interested in the date training materials are due, yet needs to know when training delivery starts in order to plan for servers to be set up on time. Meanwhile the target delivery of those training materials is critical to the sales director who needs to ensure her revamped sales methodology is finalised on time so that it can be included in those same training manuals (and she doesn’t care about servers…).
- major upgrade of an existing accounting system: the test manager needs to establish detailed test activities and dependencies for each of the test phase in order to engage the different parties involved. Meanwhile the CFO has little time to look at those intricacies, yet needs to approve availability of his teams to perform user acceptance test and make sure this doesn’t conflict with busy accounting periods.
In both examples the various stakeholders have different needs, expectations and concerns: they don’t see the plan in the same way.
Keeping your plan simple and clear
Project plans are a bit like treasure maps: a somewhat cryptic map (sometimes with bits missing) that few people understand, with lots of steps, obstacles, detours and arrows pointing to the treasure (project completion!). And it’s your job as PM to guide people so they understand the plan and how it affects them, particularly when you are asking them to make decisions.
Guidelines to communicating about project timelines:
- Less is more: when you communicate about the project schedule, keep it at a level that says enough (ask yourself how much people need to see). As a PM , you may find that the devil is in the details, and thousand-tasks strong plans are not uncommon. However most of your stakeholders don’t care about all those details: unfortunately, there is always a tendency to show a lot of information, and this tends to be counter-productive. When communicating information, it’s always easier to show a high-level picture and drill-down if needed than working bottom-up. Besides, nothing stops you using the detailed plan with people when you need to tackle a specific set of tasks.
- Keep it simple: adopt a simple, common language to help your stakeholders understand the whole picture and remove any ambiguity. Select the important activities and milestones, make sure they are meaningul, stick to simple representations of timelines, and avoid crowding your plan with too much text.
- Make it relevant: consider your audience and what matters to them. If you need to go and present the plan to a group of sales directors, focus on those milestones that are relevant to them: for example ensure you highlight business requirements workshops, user acceptance and training (all these tasks that involve them and their teams) but condense technical activities like technical design documentation, system configuration cycles, and technical testing phases.
- Give it purpose: when you send out the project plan or present it, be clear about what you want out of it. Communication works both ways, so tell your audiences what you want from them: whether you are informing them, asking for review, requesting approval, etc. When it comes to changes, you don’t need to tell the whole world every time a task’s schedule changes, but you need to inform your stakeholders when there are significant changes that affect them. Be clear about impact: communicating an updated plan saying “this is the new schedule” doesn’t help anyone if you don’t tell them what this actually means for the project, and for them.
- Keep it current: it may sounds obvious but keep your plan up-to-date and ensure people know when there are changes that affect them. Always date-stamp your plan and make only the current version available to your project teamy and your stakeholders (older versions can be archived under a clear label in your project library).
Making your plan visually effective
It is worth spending a little time on making your plan visually effective so you can draw attention to what is important about the plan and help your stakeholders understand it and communicate back to you. Much progress has been done in various project management planning tools to include reporting and visual representations capabilities. Even MS Project has upped its game a little by introducing a “visually enhanced timeline” in its 2010 version.
I tend to use whatever tools are available to me and used by the organisation running the project, but when it comes to presenting high-level pictures, I simply draw my own visual representation (I often use MS PowerPoint for high-level pictures) because I like to select what I want to show and how I want to show it, particularly when it comes to showing the plan to senior stakeholders or broader audiences. Below is an example of a visual representation for a global system implementation timeline: this was aimed at a wide audience and needed to act as the high-level reference point for the project. I kept it simple, bundling technical activities together, and putting the emphasis on who was leading what activities in order to make it clear to the different stakeholders which periods of time were critical to them. This picture was widely used throughout the project, and the “less is more” approach worked very well.