Why are Project Managers Allergic to Schedules?

Imagine bakers that didn’t like ovens, because they are too hot, or surgeons that, when facing an open patient at the OR think “this is too hard, let’s close the patient and get him back on meds.”

Sounds absurd, but this is what many project managers do when it comes to maintaining a schedule, the central tool of our profession.

Many project managers have flocked to agile just to get away from the need to create and maintain a schedule. I am an agile practitioner and trainer myself and can tell you that it is true that agile doesn’t require a schedule, but agile is not equivalent to “cowboy management.” The discipline required to carry out an agile project is sometimes more stringent than in waterfall.

I have used Microsoft Project for twenty years now (yup, it has been around that long, and other than introducing the ribbon in 2010 that drove everyone crazy, Microsoft hasn’t done much to the tool, for which they charge over $1500/license). I have used it to manage projects and programs, even portfolios. I have been an instructor in MSP and also a trainer and coach, helping PMs to learn the tool.

---

{module ad 300×100 Large mobile}

---

I can say that, for the most part, I have tamed the beast, but from time to time it lashes at me. Microsoft Project is not an easy tool to use. It is not like Excel where all the tables are in sight. Microsoft Project is composed of many tables that you don’t see or even know exist, so any false move and you are doomed. A 10-day task jumps to 60 days, your filters don’t work, or worse.

Most project managers have no problem creating a schedule during the planning phase of the project, so they can define milestones, request resources and make commitments with stakeholders. Then they go through the moving ceremony of printing the schedule and posting the pages on a wall. Apart from impressing everybody at the office with their knowledge and sophistication, posting a schedule on the wall is completely useless.

At the start of the project, a schedule is always wrong, and you will only know how wrong it was when you finish the project. The schedule will and is expected to change every week if it is to remain relevant. The printout on the wall is nothing else but expensive and ugly wallpaper.

The main challenge with MSP or any other scheduling tool is during execution. Some project managers try to update the schedule, they do it wrong, get absurd results and finally give up. Some examples I have seen over and over are:

• Today is July 20, and you are updating a task as complete. The task has a start date of August 03. Congratulations, you have travelled in time and completed a task in the future.
• Today is July 20 and a task scheduled to be completed on July 17 remains at 0%. In this case, help to go back to the past to complete the task.
• Today is July 20, and a task is scheduled to start August 17. For valid reasons, some work for that task was done last week and, to avoid the problem mentioned above, you change the start date to July 13 and report progress. In response, MSP splits the task, and now you have a dotted line followed by a bar, which you don’t know what it means. Nice.

These three examples are typical situations that are very simple to prevent, but you need to know what to do. If you don’t do it right, you are introducing technical debt to the schedule. After a few weeks, the results will not reflect where the project is in terms of milestones or percent complete, and it will get progressively more difficult to update, as you will get unexpected results you will have to fix. At the end you don’t know what to do, you are frustrated, it’s late, you want to go home, so you give up and go back to your old friend Excel, which doesn’t have a mind of its own and follows orders.

MSP is a modeling tool that can predict future state as in when milestones will be achieved and when resources will be needed. Excel simply cannot do that, and can be dangerously misleading on the real status of a project. Yet, the majority of PMs revert to Excel to different degrees, instead of sticking to the tool of our trade – the schedule. For a good PM, the schedule is the core tool. Guiding decisions for execution and management of resources, It contains all the relevant information from risks, issues, and changes.

When the team is involved during planning, and the schedule is kept visible to the team week after week, they not only get used to the schedule, but the tool plays the same role as the “project wall” in agile. The end result is the same – a team that moves towards self-management. It is a beautiful thing when you watch a team discussing and trying different scenarios of what to do to get the next milestone back on track. Of course, for this to happen, you need a schedule that works.

Many companies are embracing agile as the approach of choice, but there are, and there will always be projects that do not fit agile, so the schedule is alive and has many more years to live. Furthermore, you can combine approaches like using agile for one major deliverable and a traditional waterfall for other deliverables.

I was consulting with an insurance company that wanted to do agile not matter what. They had a major program that involved a front end that nobody understood and for which they couldn’t make up their minds, which was perfect for agile. The project also had to deliver all the “piping” between the new front end and the back-office applications. This part had no volatility, was predictable, and could be planned using traditional methods.

My recommendation was to start with the piping, using a traditional approach, and then do the front end using agile, using the agile principle “procrastinate, procrastinate, procrastinate”. They followed my recommendation and built the backend with no problems. In the meantime, the direction changed three times, so it paid to procrastinate. The front end was then delivered using agile. A success story that required an overall schedule to manage all these components, and a detailed schedule to manage the back end. Long live the schedule!

So what should project managers do?

• Never push team leads or resources to update the schedule. If it is hard for a PM, imagine what they will do if left unsupervised.
• If you have a small project, you, the PM, must be the bridge between Excel, napkins, backs of envelopes, and the schedule.
• If you don’t have the skills to update schedule properly, get help. The built-in help will not address these topics. What you need is training and maybe coaching from your PMO or local PMI chapter.

A well-tracked schedule can and should become the core tool the PM uses to manage the project. It integrates all the relevant information (actuals, resource availability, risks, issues, assumptions, constraints, etc.) into one tool that can model the expected results and tell you the most likely dates for your milestones. For this, you also need an organizational culture that encourages transparency and early warnings that dates may not be met. Other organizations prefer the “head in the sand” approach and deal with the problem when it blows up, usually throwing more time and/or money.

The majority of project managers think that they can manage all the relevant project information with sticky notes on their foreheads. This approach, while valid and very frequent, has two problems:

• Too many sticky notes, they won’t fit on your forehead
• The sticky notes will fall when you start sweating

Being a good scheduler will elevate your career as a project manager, particularly when you use it as a tool for collaboration and team self-management. Maybe it will not become your favorite video game, but it shouldn’t be the monster under your bed either. A good project manager that is also good scheduler can have a brilliant future.