Late deliveries are a nightmare—especially if you are ”the face” of the team and you have to explain the reasons for it to either your customer or end users.  In this post I intend to list three reasons why your project might be late and some suggestions to a) fix it and b) avoid the same problems in the future.

Reason 1: Your Team Is Not Agile

For some reason your team is following a traditional project management approach (i.e., waterfall, command and control, etc) or, worse, it is not following any kind of explicit process (“let’s just start programming”).  In this case, you are probably not yet aware that your project is delayed because of lack of visibility.  In this case there is not much to do until you figure out a way to assess the team’s progress.

Suggestion: Go agile by doing some basics:

• Identify what’s not really done, missing features and any other activity that remains to complete your deliverable.
• Split your organization into small, cross functional, self organizing teams.
• Split your work into a list of small, concrete deliverables, sorting this list by priority.
• Split time into short fixed-length iterations (from one to six weeks) where you can fit a small, coherent set of functionality.
• At the end of every iteration, demonstrate the progress your team has made and perform a retrospective to optimize your process.
• Celebrate your successes and your failures, whatever is the case.

By doing this, you will have small teams using short time iterations to build a small set of features. Your product functionality will grow steadily and predictably after every iteration.  As a side-effect, tracking progress and identifying and removing obstacle will become easier.

Life’s great, isn’t?

Reason 2: Your Team is Not Delivering

When a team is not delivering on time,  or at all, the most likely “fault” is with the process you’re using (or lack thereof).

In my experience, most of the time the problem is associated to a short list of sources.

• Lack of technical skills in the team (e.g., programming language).

• Too much work in progress, lot of “95% done” functionality that never gets completed.

• The team is too optimistic, being heroes, and they over- commit or accept impossible targets.

• The team commits to a delivery date without measuring the size of the project or the effort needed to complete it.

• Business requirements evolve faster than the team delivery process and features being built become obsolete before they’re finished.

Obviously there are many more additional reasons but I’d first check the list above and do something about it in case you are facing this kind of problems.

• Provide training to the team, or provide technical guidance.

• Limit the work in progress or define some rules like “do not start on new work until you complete 100% of your current task."

• Get to know your team and what are they capable of; you can collect some metrics. Number of features per iteration would be a good one.

• Measure the size of your project, there are several techniques for this like function points, use cases points, story points, hours, but please don’t do an estimate and then write it in stone, revisit your estimates once in a while and make adjustments as needed.

Reason 3: You’re Late Before You've Started

Oh no: You are just starting to work on a project now that you promised to start on a month ago! It should be a no brainer to figure out that you’re going to deliver at least a month later than promised.

The good news is that you finally got started on it, the bad news is that the delay can grow on a daily basis depending on the way you manage your project.  You can now either re negotiate the delivery date or shorten the list of features to be delivered.  The thing not to do is put your team on a death march on the hope that you’ll somehow make up the time. In software development, going slow is the best way to go faster.

Related Posts:
http://www.nearsoft.com/blog/how-to-start-a-project-right.html
http://www.nearsoft.com/blog/da-ja-vu-all-over-again.html
http://www.nearsoft.com/blog/more-da-ja-vu-all-over-again.html
http://www.nearsoft.com/blog/better-estimates-in-10-steps.html