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

Let’s continue a review of common tools and tactics for preventing schedule delays on software development projects. Hopefully, something here may be good preventative medicine for your next project.

In our first post on this topic, we discussed the first five factors that can lead to delays in a project schedule. Below, we address another five.

If you think testing adds time to the project schedule, try delivering defects.  Software defects, especially those discovered late in the project, can throw a wrench into the best plans.  Defects can trigger major re-writes and they can delay or prevent project acceptance.  Planning for quality is a necessity for schedule control.

Analysis

Before development begins, there should be a quality plan in place.  The plan will vary greatly, depending on the project type.  For small, simple projects the plan may be that the sole developer tests as he or she goes and implements the occasional fix.  A final testing will be performed prior to delivery.  On larger projects, where multiple developers are working with the same code, the need for more thorough quality planning becomes heightened.

For example, there should be a procedure in place for controlling the source code.  Where code is being added to existing work, there should be a plan for regression testing.   Likewise, the quality requirements must be identified and there should be a process for performing audits, implementing fixes and re-testing.  The earlier defects are discovered, the less likely they are to affect the project schedule.

Discontinuity is what causes work to start and stop before it is complete, multiple times.  It presents itself in different ways, though one of the more common ways is through task switching.  When developers are tasked back and forth between multiple, ongoing projects, time is spent remembering where they left off. In some cases, time is also spent relearning.  This may not cause problems for lower-level thought processes, but when higher-level thinking skills are involved, inefficiency abounds.  This inefficiency can create schedule delays.

Analysis

One way of avoiding the problems presented by task switching is to plan shorter periods of development so that logical stopping points are easily identifiable. Then, provide opportunities for the development team to identify when they are at good stopping point and able to switch  to a different task.

An external dependency exists when one event must be completed before another event may start.  In the scenario of the classy website, an example would include presenting the first home page mock ups for client acceptance, then waiting for the stakeholders to have an internal meeting about the design and then develop consensus before moving forward with development.  In this case, the developer will be waiting for feedback before he or she can move forward with the code behind.  Because we may not know when the client stakeholders can meet and how long they will take to reach a consensus and report it back to the project team, this external dependency is capable of creating unknown schedule delays.

Analysis

In the planning stages, identify all known dependencies and investigate what lead times may be required, and then plan accordingly.  Where possible, plan for shifting the development team to tasks that can be completed without the missing information.  Additionally, remain pro-active in obtaining the feedback that’s required.

For large projects with many stakeholders, simply listing them gives a helpful reference document. Our Stakeholder Register template can be useful at the outset of a project.

Insufficient resources, on the development side,  can mean not having the number of developers required to complete the project under a specific schedule.  It can also mean working with development resources that do not possess the specific experience required. Because technology changes rapidly, the later is not uncommon.

Analysis

Once the project team is determined, work to evaluate their experiences and levels of expertise.  Identify specific resources that may serve to assist with new learning curves.  If training or subject matter resources can be assembled, make them available.  Where necessary, remain conservative in schedule planning and monitor the schedule for early revisions.

If a developer is unable or unwilling to work to schedule, the project will experience delays.  Sometimes, factors beyond anyone’s control can present themselves.  Examples include lack of motivation, illness and cross-prioritization.  If you are fortunate, this problem will present itself early in the project.

Analysis

Where this problem presents itself early on, take swift action to assess the situation.   Perhaps a little motivation or encouragement is all that’s needed. Providing an Activity List to all developers at a project beginning can be helpful in their understanding their role in the project overall. Sometimes, sharing the full project vision can eliminate that “cog in a wheel” feeling.  On the other hand, if your assessment leads you to believe the problem will persist and cannot be alleviated by your efforts, such as the case with chronic illness, work quickly to identify additional development resources and to protect the project knowledge and work that is already in place.  Make plans to transition additional or alternative resources to the project.

There are certainly many other factors that contribute to schedule delays; however, these are the ten most common for which we plan.  Does your top ten list look different?