Developer Exchange Blog
Have You Seen the Schedule?
"The project schedule isn’t right anyway."
How many times have you heard that? The reality of the statement’s implications is far reaching and has really shaped my feelings toward what a project schedule is and how it should be used. Following, are my ramblings on a couple misconceptions that I’ve hit over the years that help create the environments where this statement is made.
Now, before going any further I feel compelled to let you know that I don’t hold a CAPM, PMI-SP, PMI-RMP, PMP, or PgMP certification, but I have had countless hours of project management training from all of my various employers (Doozer, Accenture, BellSouth, Southern Company, ProSoft, and Harris Corporation) over my 17+ years in software construction, but more importantly I’ve been a part of and led teams from 1 to 45 with budgets from a few thousand to a couple hundred million dollars hundreds of times in my career to successful completion. And, yes, I’ve Experienced some that didn’t make it for various reasons, but, isn’t that the way of the world? Show me someone who has done any serious amount of work in any field and has never worked on a project that didn’t make it and I’ll be amazed. I have to admit that I've learned more from those failures than anything else.
The first misconception is that the project schedule is and should be a rigidly enforced document. Everyone needs to realize that in the real world of projects, any kind of project, schedules must be LIVING documents. It’s unrealistic to think that once it is all planned out perfectly, that that is how things are going to happen-- perfectly. This is actually why schedules were created in the first place, to be used as a communication tool that helps everyone understand the impact of decisions made during development. Schedules are the basis for adjusting expectations of everyone involved in the project. If I never hear again "We can’t change the schedule because that’s what we told the customer!" - life will be good. In fact, that is where a good schedule shines. You can use it to talk to the customer since it pictorially represents the list or block of tasks affected and the impact changes have on the project’s timeline. After all, isn’t the end date of the project what everyone is most interested in? It’s the big day I get to deliver this great thing I built to my customer, the day I get my new tool that is going to make my life so much better, and the list goes on.
We all want success.
That is why we put the schedule together in the first place, to be used as a tool for effective communication to chart the path to completion and success. No, really, I mean it. You’ll never find anyone anywhere recommending it as the perfect weapon with which we shall bludgeon the project team. I know it’s been used for this on numerous occasions, but that was never the intent for which this wonderful tool was created. Although many a programmer may argue otherwise, since most hate building them anyway and really haven’t seen how one can truly help.
The second misconception and commonly heard refrain about project schedules is "Only the PM can change the schedule." Why?
- Only the PM has the project scheduling software.
- People don’t know how to use the project scheduling software.
- Updates to the schedule are only done in project status meetings and there isn’t one until next week.
- Again, most folks hate building them and it’s seen as a decent cop-out. Especially, if 1 through 3 are true of the situation.
- Isn’t that the job of the PM? I don’t want them thinking I’m trying to do their job.
Ahem, excuse me? The schedule isn’t the PM’s. They just happen to be the custodian of it, just as developers are the minders of the code. On really efficient teams, everyone changes and updates their part of the schedule and sends it back to the PM to be integrated into the whole. This is where tools can help or hurt. I am not an advocate or hater of any particular tool, they all have their places, and in the proper hands, with the right mindset, they can be lifesavers. Microsoft’s Project is a great example of a good tool that is in widespread use and that’s fine, but not when deployed only to the PM essentially locking up the schedule, building a roadblock and one reason for the paragraph’s opening statement. Hang on, hang on, don’t start the flames yet. I know there are tons of ways around this like extracting the schedule as a spreadsheet, saving it as a PDF, and more, so use whatever fits your environment to unlock the schedule for collaboration. The key point is to unlock it and get everyone feeding and maintaining it. It should be so helpful that you see it on peoples’ desks. Even if you use tools that at first glance appear to be a bit brute force like, *gasp* Excel or a web-based tool like JIRA with GreenHopper, it doesn’t matter. What does matter is the schedule is relevant, accessible and useful to all project members.
There are plenty of other reasons and topics on this that I haven’t covered, but in the interest of not boring anyone to tears or outliving my own attention span, I hope I’ve plead the schedule’s case well enough for everyone to re-evaluate how we think about them and how critical they are to a project’s success. So, if you are on a decent size project and don’t see a schedule on some team members’ desks, including the primary customer’s, you should ask why and do your best get the situation changed.