Using Your Schedule as an Influencing Tool

Using Your Schedule as an Influencing Tool


Developing and maintaining a project schedule is one thing. Turning it into a decision support tool for the team and project stakeholders is another.  This paper explores methods for making the schedule accessible and relevant to the team members, not just the project manager.

Project schedules are dense with information and contain a lot of shorthand to describe complex deliverables and tasks.  Team members often ignore the schedule as it is too abstract and complex for their day-to-day use.  The schedule therefore becomes the sole realm of the project manager and is labeled “bureaucratic,” “useless” or “fiction” by the team.  Unfortunately, that means that team members have only their current experience as a means of understanding their role in context of the overall project as well as the individual components, and are unable to anticipate and forecast the effects of their decisions on others and on the project deadline.

The Project Schedule

Ah, the unloved project schedule.  It began with grim determination and resolve.  The PM stretched her arms and flexed her fingers, and with head down like a concert organist began to compose the masterpiece in Microsoft Project.

She threaded together the strands of the network diagram, coordinating and joining the related components like a beautiful concerto.  At last it was done – a work of art – and she presented her schedule as a lauded symphony.  But when the time came for the team to join in, the other players in the orchestra did not follow their parts.  They seemed to follow the beat of a different drummer.

What happened?

It’s all here: the map to lead us from chaos to completion. Why does no one follow it?  Well yes, there was a divergence here or there, but why didn’t those team members note the variances and improvements so everyone stays on the same page?  The project took on a life of its own, and the lonely project schedule gathered dust in a corner like a forgotten program from a performance long ago.

The Purpose of the Schedule

When analyzing a problem, it helps to go back to the roots.  So what is the purpose of a schedule?  It is to model time so that the team and stakeholders can make informed decisions.  A project schedule is a model of time, and like all models it gives us the opportunity to play with ideas and try them out in a cheaper medium than the final – in this case, time, which is not reusable.  So we substitute the two dimensions of paper (or computer bits) to simulate what will happen over time, weaving the disparate activities of the different team members in a complex diagram.

And why bother to do this?  First, it enables us to try out different scenarios and select the optimal one. Doing this in real time is called re-work, and bosses frown upon it.

Secondly it lets us look at the details. What is missing?  How will this affect that?  What must we be prepared for when we start or complete this part?  We can then work on the other tasks we’ll need completed so that the critical thread isn’t waiting while we run off and find another elusive piece of equipment or information.

Finally, it enables us to look at the big picture. Does this make sense when we look through the wide-angle lens?  Where are resources over-used or under-used? What can be optimized?  Where are the weak parts and risks?  Does this scheme really reflect our priorities and the reality of the world we are working in?

Our goal in creating this schedule is for everyone to understand the nuances, and to see how each individual’s piece ties in with the greater whole.  Like any big picture, it gives us both proportion and context – valuable information to those who will contribute and make a myriad of little decisions every day.  Sometimes we get so wrapped up in the task itself, we fail to see its overall purpose.  This is true not only of the individual tasks of the schedule but of the schedule development task itself. We know we have to do it and charge ahead with the task, forgetting why it is so important and what value it brings to the project.  After all, the schedule itself is not of any value to the project customer – they want the resulting product.  But so often the team forgets why the schedule itself is valuable, and so tosses it on the dust heap in an attempt to give more attention to the individual tasks, assuming their relationship to time and one another is obvious and it is unnecessary to plot and track them.

Yes, yes – we see this time and again but that’s the nature of the beast, isn’t it?  How can we change this natural tendency of team members?

If you ask them, the first thing team members will tell you about the schedule is usually that (a) it is wrong, and (b) it doesn’t make sense.  So how do we fix that?  First, recognize they are right. It is wrong, and it doesn’t make sense – to them.  That’s because the team are the experts, and they did not get to explain how the work should be planned when the PM was building the schedule. She thought she knew all the team member’s work and wrote it herself.   Even if she did ask them all about it before she sat down to create the schedule, they won’t recognize their own words in the distorted view that is an unfamiliar schedule.

Many people ask, why build a schedule if you know it will be wrong? (It will be – trust me.)

The answer is twofold – first, because it will force you to think out the details, and you will never be able to capture and hold them all unless you write it down.  Brains just don’t work like that, particularly multiple brains.

Secondly, if you don’t write it down, you won’t know when you changed it.  In your mind, an idea is an ever-changing thing.  It would be nice if each memory was a photo or movie stored on a hard drive, the same every time you pull it out, but that’s not the way brains work.  They continually revise what they store, again every time they access the memory.  (For more on that, read The Invisible Gorilla by Christopher Chabris & Daniel Simons.)  Besides, as the statistician George E.P.Box once said, “All models are wrong, and some are useful.” 1

While the schedule will never be perfect, it can be a better prediction of what work will actually happen if we ask the experts, and alas, that is not the project manager.  Who is the expert?  This is usually the person who will do the work, particularly for those of us in the knowledge business, which undoubtedly includes you.  Team members on projects are not illiterate drones, hired to complete non-thinking tasks by supplying human energy. Those days are long past.  Team members are experts, they have particular knowledge and skills and know intimately what it takes (and how long it takes) to complete a piece of work.  (They, like project managers, are really bad at estimating how long other peoples’ work takes, though.)

Getting a Good Start

The best method for getting a good start on a project schedule is to start with sticky notes and a big wall.  IT people and techie types want to bypass this and go right to the software, but don’t let them. It’s a bad practice.  Working on the wall with the team members lets people talk about the details more effectively, and to sort out the alternatives with their teammates.  Even at a conference table the conversation is different – it becomes more theoretical and less specific when people are in “meeting mode.”

Once the network diagram is on the wall it is easy to capture it in a scheduling package.  Keep the language as close to what is on the sticky notes as possible (ask for more detail when writing the notes at the wall), so that people recognize their own ideas.  Take actual pictures of your network diagram – those pictures will trigger many memories of the conversations that were held.  Now that line in the schedule is not some vague idea that the project manager wrote down, but a symbol for a much bigger idea that was hashed out in that conversation.

Next Round – Applying Estimates & Resources

The next iteration — adding in the estimates and resources and seeing where all the assumptions fall out — is often done by the project manager.  You’ll find people scheduled at 800% and a schedule that goes out a year past when you have to have it done.  Now the refinement work begins.

Break the schedule down into smaller, meaningful chunks, and work with the people involved with those particular chunks to prioritize resources and revise estimates.  Here is also where you may start making “versions.”  Make a copy of the schedule and try it different ways.  This is the point of using software. It enables us to lay different alternatives next to one another to compare and contrast, identifying the pros and cons of each, and enabling you to make trade-off decisions.

Presenting the Schedule to Management

Now things get really tricky.  You’ve worked out the optimal way to get from the current state to the desired state, and the boss says, “Do it in half the time.”  Great. You knew this is going to happen. It always happens.  Be prepared.  Have a rolled up version of the schedule handy and use color coding to highlight the unchangeable parts and the optional parts.  You may have a few versions ready to present.  “With more engineering resources the schedule will look like this, and here is the list of trade-offs.” (costs, risks, etc.)  Have the statistics ready – calculate your critical path with a PERT method and quote the statistical likelihood of hitting the date you have.  Make sure you have pictures – use graphs, Gantt charts, bell curves — whatever it takes so that the differences between methods A & B are visible. If the boss comes up with a method C you didn’t anticipate, be sure to set a date for when you’ll be back with the diagrams of that method for comparison sake.  If you don’t think that you’ll get out of the room with a promise, bring someone else to do the calculations right there in the background so you can make those choices visible.

Once you come to an agreement, set your baseline and send out information about it to team members. Include the diagrams so people know what you’ll be working from.

Using the Schedule with the Team

Schedules are visual tools, and yet most people never look at them.  To be sure that people are looking, keep putting them where they can be seen!  It is a great idea to keep one on the wall, just be sure you update it religiously.  If the view isn’t changing, people will ignore it.

Post the current segment in your regular meeting agendas and status reports.  You can plot progress on a high-level Gantt chart or milestone chart for outsiders, but the team should see the work they are doing right now in schedule format every time they talk about that work.  Use the less detailed diagrams of the big picture to provide context and an understanding of how this work affects next week’s work and next month’s, and so on.


Track and Label Your Schedule Slips

Slips will happen. That’s why we have to write all this stuff down!  Every time the “actual” bar is longer than the “baseline” bar, pin in a note about what happened.  Review these periodically for trends: is the work underestimated, or have decisions been delayed?  Is this a one-time event or is this likely to happen again? How should we prepare for that risk?

Celebrate Your Progress

It will also help if you notice and celebrate completed deliverables and laud the stuff that’s on time.  It costs you nothing, and is more appreciated than you realize.  Seeing progress fuels our motivation.  It also helps to remind yourselves why you are taking on this project in the first place.  The most important motivator is for people to feel their work is meaningful and their contribution is important.  When people see how their contribution ties into the bigger picture, they have a sense of context and place.  Nothing replaces a great attitude, but it requires ever vigilant leadership and nurturing to keep attitudes healthy.  Don’t take them for granted or expect them – the attitudes of the team will only reflect what the leader has earned, not the quality of the team members themselves or anything else.

Capture Everything

Learn to update and review your schedule every week without fail.  Add in little variance tasks that weren’t planned and reflect on how these change the schedule.  This serves two purposes: it keeps the schedule useful, as it reflects the current situation as accurately as a two-dimensional schedule can, and it keeps you thinking about the potential future possibilities.

Project managers tend to think of schedule maintenance as useless administrivia (those who don’t know how to exploit the scheduling software) or the demi-god of the project (those in love with the software.)  Actually it is somewhere in between.  It is detailed, but that’s where the devil is, as we all know.  The schedule is not an end in itself – you won’t make money packaging it in with the product – but it is a powerful tool for getting you across the finish line.

Projects Need Kill Criteria

Some schedules may make the project look impossible.  That may be important to know.  Where are the “here there be dragons” areas?  Do you have some good, solid criteria that indicates if you can’t find a way to slay the dragon within some parameter, you need to end the project?  Every project should have kill criteria, which are like the counterpoints to acceptance criteria.  If the ROI calculation is less than X, or the project schedule forecast extends beyond Y, the project shall be cancelled.  Kill criteria are the insurance policy for your project, they help ensure that we don’t get sucked into the sunk cost morass and lose our sense of judgment and value.  A project is an investment, which is a nice word for a gamble.  We need to know when to cash in the chips.  Don’t let sunk costs fool you – if it isn’t going to pay off, you won’t make magic happen by finishing the project.

A Schedule Baseline Never Stands Alone

While we talk about having four baselines for the project – scope, time, cost and quality – there is really only one baseline looked at through four perspectives.  The scope baseline is the bottom level of the work breakdown structure, which is a list of the work packages.  Each item corresponds to a due date, cost and acceptance criteria which make up the corresponding other baselines.

Scope is the driver and the trickiest one because (a) variance is not simple math like a cost or a date and (b) we are looking for what is not on the list, which is harder to spot.  Project planning presumes that the project is a sum of the project work parts.  This is true, but it means you must very carefully track all of those parts and understand them in considerable detail.  The other half of the project manager’s job – I describe project management as administrivia and dealing with other people’s problems – is now managing the expectations around all those parts.  You will need to make these relationships and the other contexts of the project very visible for that to work.

To be Prepared, You Need Reserves

We can mathematically prove that you have a less than 1% chance your schedule will work as planned, unless you have less than 10 tasks on your critical path.  Calculating buffer penetration, even if you are not using the Critical Chain Method, will again make your decisions visible and participative.  This isn’t fat and it isn’t optional – unless you prefer to live by the adage that it is easier to ask for pardon than permission.  That belief does more to let people off the hook than managing reserves does.

The Secret is to Make the Schedule Visible

Schedules are complex, and have an eye-glazing quality to those who didn’t develop it.  But the right brain understands relationships and associations, and does so even faster than the left brain works out the logic.  The trick is to present the view that supports the decision of the moment.  Learn to create views of your schedule like an artist, and to help others to see the project through that perspective.  It will enable you, your team and your stakeholders to move from the emotional state of frustration and confusion to one of power and calm, and will become the decision support tool it was meant to be for everyone.


A project plan is a model, and so is limited in its perspective to two dimensions instead of the four of the real world, including time, which is quite important to us!  The disadvantage is that like all models, it will be imperfect, but the advantage is that it enables us to focus in on the area of importance and subordinate the less relevant items that may distract us.

In project management, scope is king. But the schedule becomes the prime minister as it is far more measurable than scope and highlights the urgency of our decisions.  We can also easily translate costs into time, represent risks, include the people and their specific assignments and represent all the other aspects of the project spectrum in this one document.  Further, schedules lend themselves to the cause of visibility as it is easy to use the pictures of project time as Gantt charts, milestone charts and network diagrams.

Influence is the same as sales. Highlight the benefits the other sees as beneficial and you will be successful in selling the idea, the process or whatever needs influencing.  We can use the schedule to highlight the effect of one decision on the other areas of the schedule and simplify the complex relationships of scope, cost, risk and resources over time.

At first, the schedule seems like a complex and indecipherable morass of detail that makes little sense and is too inaccurate to add value.  Like anything, though, it will be more natural and understandable as it becomes more familiar. You’ll find the team makes better use of the schedule and has higher engagement in the entire project as your stakeholders tease out the valuable nuances that will drive good decisions and confidence in your project.



1. More elaborately, Box said, “Since all models are wrong the scientist cannot obtain a “correct” one by excessive elaboration. On the contrary following William of Occam he should seek an economical description of natural phenomena. Just as the ability to devise simple but evocative models is the signature of the great scientist so overelaboration and over-parameterization is often the mark of mediocrity.”

George E. P. Box (1976) Science and Statistics Journal of the American Statistical Association, Vol. 71, No. 356. (Dec., 1976)