How to create and use predictive project scheduling

I was a bit naïve when I accepted the challenge to manage my first software project. I didn’t quite understand the “wink-wink, nod-nod” I got from the software veterans when I began asking for their input to the project task detail and schedule. Now many years and many projects later, I understand their skepticism. They had too often been victims of schedules that were not worth the paper or time used to develop them. They had seen schedule chicken played by professionals and had worked countless hours of overtime trying to meet unrealistic, unattainable deadlines.

However, I continue to believe whole-heartedly in the value of predictive schedules. To me, a predictive schedule is one that accurately reflects what has happened in the past and is a good predictor of the future.  It gives a believable prediction of the project end date and an accurate level of effort estimate to completion.

What are the necessary pre-conditions for a useful predictive schedule?

Let me tackle the most challenging requirement first—corporate or organizational culture. If your company has a “shoot the messenger” ethic, then predictive scheduling is doomed! Like a military plan, the initial project schedule rarely survives contact with the enemy. Staff changes, requirements creep, and vendors miss shipment deadlines.  Your project schedule must be detailed enough to identify potential problems and dynamic enough that you can reforecast to accommodate the real world. AND, senior managers need to be willing to hear the impact of changes on the project schedule.

For predictive scheduling to be useful, there must be trust on all sides of the equation:

  • As project manager, you do the best you can to create an accurate and meaningful schedule of tasks with an estimated level of effort (LOE).
  • Developers and team members work hard to meet schedule requirements and accurately record their time to each task as well as update estimate to complete (ETC).
  • Management trusts that everyone involved is doing their best and reporting accurately.  They provide support when needed.

What content is required for a useful predictive schedule?

Developing a predictive schedule is a top down and a bottom up process. You must start with the top level vision and goals for the project to set expectations and scope.  Then each deliverable is broken down into tasks that require no more than one or two week’s time to complete (that task may include the effort of several people or it may require less than the full-time effort of one developer). The point is that you need to be able to assess the project’s status weekly.

Now we come to the one of the most powerful features of predictive scheduling—task dependencies. Your schedule must show these dependencies. What must be completed before “Task X” can begin (predecessors) and what tasks depend on the successful completion of Task X (successors). Getting the task dependencies correct is 50% of the requirement for creating a useful predictive schedule.

The other 50% is estimating the effort really required to complete the task successfully. As project manager, you will want the input of others on the project to define tasks, dependencies, and effort. Then, you have to make a judgment on their input. First, you need to make sure that there is enough detail so that the schedule can document the project status and second, you will likely need to adjust the estimated level of effort (LOE).

Why do I believe that the initial effort submitted by developers will need to be adjusted? Developers and other team members often make errors of omission and commission in defining LOE for a task. (Dan Mitchell offers some insight into what may be left out of developer’s estimates on his Software Developer’s Guidebook blog). Some may be too optimistic—assuming all of their time will be dedicated to writing code when in reality the schedule needs to include time spent in meetings, unit testing, and working with temperamental hardware and software. Or, they may assume that the level of productivity is the same for all developers or IT staff, when the truth is that some developers are significantly more productive than others (usually based on experience or skill).

Finally, either through misplaced self preservation instinct or lack of knowledge, developers may over-estimate LOE believing that if the estimate is cut during its migration through senior management reviews, they will still be able to get the work done because they padded their initial estimate.  So you, the PM, must assess the estimates and try to get them to be as accurate as possible!  No one said this was easy.

What benefits does a project manager receive from a real predictive schedule?

  • Ammunition to define and defend resources needed to be successful
  • Knowledge of project status with sufficient time to avert disasters
  • The ability to answer status and planning questions from senior management
  • A final project that predicts cost and schedule throughout the project’s life

One last thought: predictive scheduling tells a PM what he or she needs to know, not what they may want to hear.

Please comment and share your thoughts on predictive schedules.


(If you want more on why you need predictive schedule check out the earlier post at

Why doesn’t anyone listen to the customer?

The tired cliché about the customer always being right does not always sit well with IT professionals, software developers, or even project managers. In private meetings, I have heard many contentious thoughts expressed:

“The customer does not know what he wants.”

“The customer does not understand what he’s asking.”

“The client is stupid.”

“This client is a flake.”

Wow! What’s going on here? Part of the explanation for this “failure to communicate” probably stems from the way that requirements are often generated – especially in projects. The customer begins with a problem, a need, or an itch to be scratched by a new software solution. He presents his challenge to—usually— marketing or business development professionals who assure him that XYZ Company can make his pain go away.

I can’t help but think of the classic picture of the “Tire Swing Cartoon” that depicts the mis-communication of requirements.  How the initial requirements are created depends on who is in the room while dream and reality crash together. In all likelihood, the company bidding for the project will include project management staff in putting their bid together to provide creativity and a dose of reality—although this is often done under the duress of a fixed cost and delivery schedule.

Eventually agreement is reached on basic deliverables, schedule, and cost among these parties (with emphasis on the soon forgotten “basic” word). In the pleasure of the moment, future problems are expected to be resolved through requirements management by the PM.

The customer’s role is not over when the contract is signed, however. Most good projects call for concept demonstrations, prototypes, and beta-test versions of the software before the customer accepts delivery and the contract terms are fulfilled. It is in these feedback sessions between the users and the developers that frustrations may manifest and charges fly: why doesn’t anyone listen to the customer?

Now, don’t get me wrong, I believe the stepped process in developing, refining, and final acceptance is an essential best practice in creating software for good project management. But as the proposed solution begins to emerge and be displayed, it is typical that users will want more and want it differently. Because users are not coders or system architects, they will express their desires in ways that do not appreciate the level of effort required or the implications of what they are asking. Nor do they understand the effect on cost and schedule to comply with their requests.  Even with new software methods like Agile development, a customer is not going to understand software problems any better than they do in a traditionl project management methodology.

That’s the PM’s job. It is also the PM’s opportunity to work with the users to better understand their needs and to explain in non-technical terms how the user can get what he wants, what the changes and additions will cost, and how they impact the schedule, cost, and quality/scope (see the Project Triangle)

“Good project managers recognize that every decision has opportunity costs. If you decide to add more features, quality must drop, or the schedule must slip. If you decide to cut the schedule, features must be drop or quality must drop. There is no way around the natural tradeoffs of resources, time and quality.”  – Scott Berkun in The List of Reasons Ease of Use Doesn’t Happen (November 2002)

The PM must also be adept at translating the user’s world to the developers. He or she must listen to the customer and try to discern what is really meant by, “can I download this on-line data to a database on my notebook?”

One effective technique to gain a handle on real customer requirements is to create a “Concept of Operations” or use- scenario before a line of code is written. This user-centric step helps the customer understand what they will be getting and provides feedback to developers when the cost of change is much lower – as opposed to later in the development process. You can read Karen’s paper on “The Performance-Centered Design & Development Methodology” for more information.  Company XYZ may also find that it is very helpful in this early part of the process to call in an outside professional to facilitate the dialogue between the end-users and the developer and PM staff.

If you have any tricks or techniques that facilitate listening to the customer, please share them via your comments.  Everyone benefits from sharing good ideas.


The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts

Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management


Pushing the Edges Out ...


Just another site