« Supporting Frameworks for Successful Program Management - Risk Management
Managing the Project Time - Introduction »

The Fine Art of Scheduling - The Format of Project Schedules - A More Complicated Example

May 24, 2008 | Author: admin | Filed under: Scheduling, Project Management Best Practices

The Fine Art of Scheduling - The Format of Project Schedules - A More Complicated Example (#31 in the Hut A Project Management Primer)
By Nick Jenkins

Why the fine “art” of scheduling?

If it were a science then every project would be delivered on time!

This sadly is not the case. Overruns are so common that most people have no faith in project deadlines. In truth, the art of scheduling is based on experience and the more experience you have, the more accurate your schedule will be. However, you can still produce a good schedule by following some simple rules.

In the following, more realistic example, a project is broken down into a number of phases and the start and finish of each phase is recorded separately. Columns have also been added to include the duration of each phase and the deliverables to be completed at the end of that phase.

Phase Start Finish Duration Deliverable
Scope and plan 01-Jan 10-Jan 7 days Project proposal
Specify requirements 13-Jan 24-Jan 10 days Requirements spec.
Production phase 1 3-Feb 14-Feb 10 days Alpha
Production phase 2 24-Feb 7-Mar 10 days Beta
Production phase 3 17-Mar 28-Mar 10 days Final candidate
Acceptance testing 7-Apr 11-Apr 5 days Release system
Implementation 21-Apr 25-Apr 5 days -
Launch 28-Apr 28-Apr 0 days -
TOTAL   67 days  

This new project schedule includes three scheduled iterations of the production cycle of design-develop-evaluate. In reality the three cycles may be many more as prototypes are rapidly produced during the cycle but the schedule imposes a minimum of three cycles. The deliverables for these production cycles are an “alpha”, “beta” and “final” version of the system.

The first thing to note is that the “Duration” column does not exactly match the number of calendar days between the scheduled start and finish dates. This is because the duration column indicates the number of working days between the two dates. For example in 2003, while there are 10 calendar days from the 1st of January to the 10th of January (inclusive) there are only 7 working days due to the fact that the 1st is a public holiday, New Year’s Day, and the 5th and the 6th are a weekend.

The next important point to note is that the phases of the project no longer occur contiguously. That is, there are distinct gaps between some phases of the project. For example between the specification of requirements (which concludes on the 24th of January) and the commencement of the first production phase (on the 3rd of Feb) there are 5 working days unaccounted for. These days are held in reserve by the project as contingency.

In the likely event of things not going to plan, the project can use this contingency to maintain the schedule and original delivery date. If things go exactly to plan the project can simply scrap the contingency and move the schedule forward to the next phase (with subsequent reduction in delivery time). Either way, everyone is happy!

How much contingency to include is a matter of experience. While it can inflate delivery times considerably it can also save the project from damaging and costly failure. In the above example contingency amounts to nearly 50% of the overall production time and represents an excessive amount of caution on the part of the project manager. As a rule of thumb 10-20% is normal, although more is not uncommon. Take as much as you think your project can live with.

One of the problems with contingency is that as soon as people become aware of it they naturally want to use it. Designers, developers and testers will all want to take advantage of the maximum available time to ensure they deliver the best job, even though your schedule may not permit it.

You can’t pretend the contingency doesn’t exist; all of your team will know about it anyway. You have to appeal to their professionalism to avoid intruding on time which is scheduled for genuine emergencies.

One effective but often neglected method of ensuring that contingency remains untouched is to offer success bonuses for on-time delivery or introduce financial penalties for late delivery. The latter often proves unpopular but effective!

Next in the Hut A Project Management Primer:

The Fine Art of Scheduling - The Format of Project Schedules - Gantt charts

Previously in the Hut A Project Management Primer:

The Fine Art of Scheduling - The Format of Project Schedules - A Simple Example

Nick Jenkins is an IT manager with 10 years experience in software development, project management and software testing. He’s worked in various fields of IT development in Australia, Britain and the USA and occasionally he learned something along the way. Now he lives on the banks of the Swan River in Perth, Western Australia, and he publishes the odd guide to help aspiring IT professionals. Nick’s website can be found at www.nickjenkins.net.

Share this article:
  • StumbleUpon
  • Digg
  • del.icio.us
  • Technorati
  • Reddit
  • YahooMyWeb
  • blogmarks

Related Articles

This entry was posted on Saturday, May 24th, 2008 and is filed under Scheduling, Project Management Best Practices. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

2 people have left comments

[…] The Fine Art of Scheduling - The Format of Project Schedules - A More Complicated Example […]

PM Hut » The Fine Art of Scheduling - The Format of Project Schedules - A Simple Example wrote on May 24, 2008 - 9:47 am | Visit Link

[…] The Fine Art of Scheduling - The Format of Project Schedules - A More Complicated Example […]

PM Hut » The Fine Art of Scheduling - The Format of Project Schedules - Gantt charts wrote on May 30, 2008 - 12:32 pm | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories