Software Development Project Management: 5 Tools and Tactics for Preventing Schedule Delays

Several statistics relate that the majority of software development projects fall behind schedule.  One source relates that 75% are delivered late while another source cites a different percentage, and so on.  It’s hard to know what percentage to accept as most accurate.  However, to avoid being a part of the statistics, we are once again motivated to review our lessons learned for ideas about preventing schedule delays.

There are ten common factors that contribute to schedule delays.  There are many others, but these ten to be most common:

1. Unclear Requirements
2. Changing Requirements
3. Expanding Scope
4. Inability to Track Progress
5. Failure to Account for all Project Tasks or Events
6. Poor Quality
7. Discontinuity
8. External Dependencies
9. Insufficient Resources
10. Failure to Work to Schedule

The top four (40%) of the most common factors are attributable to breakdowns in gathering, tracking and monitoring project requirements.  The next three (30%) are directly attributable to problems in planning. The good news is that all ten (100%) are capable of being mitigated, if not eliminated.  In other words, there are ways to avoid these factors that contribute to delays rather than inflate the schedule to account for them.  Below, we’ll look at the top five factors, and then provide some analysis aimed at preventing or at least mitigating them.  In a follow up post, we will examine the last five.

An example of an unclear requirement is one that is vague, overly broad, or subjective.  One obvious example would include a request for a “classy website.”   Here, the requirement is so subjective that it’s unclear.  It’s unclear because we don’t know what the client thinks is “classy” and, without later feedback from the client, we won’t know whether we have completed it.  For obvious reasons, it’s also overly broad.

Unclear requirements create project delays because development effort is spent guessing what a client desires.  If they guess wrong, re-work is required.  From the developer’s perspective, it’s like nailing Jell-O® to a wall. Hence, from the scheduling perspective, it’s also like nailing Jell-O® to a wall.

Analysis

If the desired result is a list of clear and concise requirements that are easily understood and easily verified for completion, you must be able to break the unclear ones down to their smallest, most concrete parts.  They must be decomposed.  Here, some interviewing skills are valuable.

In the case of the classy website, ask to be shown examples of sites that the client deems “classy.”  Look for commonalities.  Do you identify color preferences?  If not, you should discover them.  If it’s blue, does that mean baby blue, cobalt blue or something else?  Can they show you an example of the blue they like? Can the Pantone number be identified? Do you identify the client’s preference for the absence of flash media? What do the homepage layouts have in common? On the preferred sites, what exists above the fold? Do the images and graphics have anything in common? How many pages or tabs appear in the default navigation? How are sub- pages found? Are the pages content-heavy?  What typeface communicates “classy” to the client?  Is there a preference for font size? What about font color?

The dialogue should continue until the requirements are small statements that are easily understood and capable of being verified for completion.  The smaller requirements now define what is meant by a “classy website.”  When the project tasks are understood, they can be sized for scheduling.  If there is information that remains unknown or unclear because the client is unsure, that can be planned for as well.

A changing requirement includes one that becomes altered or replaced with something else.  To use the scenario above, after development begins; the client decides that instead of using Sodalite Blue, PANTONE 19-3953 as the background color, they would like to use Blue Curacao, PANTONE 15-4825.  The best planned schedule can experience delays when the work to be performed changes after the schedule is published. Changing requirements can create delays because they are capable of adding additional work that wasn’t accounted for in planning.

Capturing requirements in a detailed list may help prevent delays. Our Requirements Register template may be helpful to you.

Analysis

Changing requirements present a two-pronged problem.   First, the changes must be identified when they are presented.  Secondly, if approved, the schedule should be reviewed for possible revision and republication.

To identify changing requirements when they are presented, the pre-existing requirements must be clearly defined and logged.  When the current requirements aren’t clearly understood or can’t be found, it’s difficult to determine whether additional information has caused them to change.  Before development begins, a system of logging and tracking project requirements should be implemented.

The second prong involves knowing what to do with a changed requirement.  If it’s automatically accepted as part of the project work, and nothing more happens, the schedule will be affected.  If, however, a change control system is implemented in advance of development, all stakeholders will know what happens with a changed requirement.  In most cases, a changed requirement becomes identified, logged, sized, and presented to the client for approval.  If approved, the changed requirement is worked into the project.  Failure to size the changed requirement and make necessary schedule adjustments adds more work to the project without accounting for the time required to complete it.

Our Change Request Log template may help you prevent some delays by tracking changes closely.

The project scope becomes expanded when additional requirements are added to the project, after initial planning.  Needless to say, when the amount of work grows mid-project, schedule delays abound.

Analysis

Once again, scope control is essential.  Before the first line of code is written, implement a system for gathering, logging and tracking clear requirements.  Likewise, put a clear change control procedure in place.  When new requirements are sized and approved, check the schedule for necessary revisions.  If the project schedule is inflexible, you may have identified a need for additional resources.

The inability to track progress does not necessarily create schedule delays.  However, it does prevent the project manager from monitoring the schedule and implementing planning techniques, in the event delays appear likely.  Without the ability to verify progress, the ability to monitor schedule is lost.

Analysis

If a twelve month project doesn’t have a deliverable until nine months out, the first notice of schedule delay is placed in a period where there is little time to recover.  If, on the other hand, development projects are planned with several small deliverables and frequent, regular reviews, schedule slippage can be identified more quickly.  While planning, ensure the frequent ability to verify progress.

If a project task isn’t accounted for; it can’t be sized and scheduled.  An example from one of our most meticulously planned schedules failed to account for the obvious; a developer on vacation and an upcoming holiday season.  This oversight caused a schedule delay.

 Analysis: 

Particularly on larger projects, it’s easy to become absorbed in calculating schedule for the work and failing to account for all non-work items.  It is best to keep a checklist nearby to assist with schedule planning.  The list includes reminders to account for: vacations, holidays, average sick days, travel time, meeting time, lead time for external dependencies, and a reminder to consider the sufficiency of the project resources.

Do your lessons learned present a different top 10 list?  If so, we’d love to hear from you! The remaining five factors will be examined in our next post.