Three common but avoidable traps in software project delivery delays

It can be challenging to deliver a large software project on time. Firstly, it isn't easy to estimate a complex software project. There are many things to consider, many moving parts that affect each other. It's hard to estimate the effort involved without actually doing the work. And to make it worst, we tend to be over-optimistic about our estimates. So whatever the team estimates, the project will most likely go over. Secondly, we can only plan for things we know. There will be unplanned work along the way that will throw the project off track. As they say, "the only certainty is uncertainty."

While there's no magic bullet to avoid these altogether, there are things we can do to help increase the chances of delivering close to the date.

Be wary of feature creep

Feature creep, or scope creep, is when we add a new feature or requirement to the project beyond what was initially agreed upon. Feature creep can come from product or management adding new functionality without validating it's valuable for the user or developers' enthusiasm for improving the design. As a result, new non-necessarily work has been added to the project scope, pushing its delivery date out. While each new feature may sound useful and be potentially small to implement, they can add up when you have too many and add complications that can cause unnecessary delays.

Typical examples of feature creeps include "it'll be nice to have this feature", "it may be helpful in the future if we implement this now", or "it might make our lives easier if we have". Generally, if something looks "useful" for the client, confirm it with the product manager or user first and ensure they are comfortable adjusting the delivery goals to cater for the change. If it might be helpful for the Engineers, ask them to consider the cost and value associated with it. Is it worth the time and risk to project delivery to implement the tech uplift now? For example, is it an occasional pain that Engineers are OK to work with until the current project is completed and then address it in another project to be scheduled next? Will addressing it now help make the rest of the project more manageable? In which case, definitely include it.

One way to reduce feature creep is to clarify the epic or item goals and be pragmatic about sticking to them. This doesn't mean you can't be agile and change. If you learn more information and want to add a new feature, meet as a team (and ideally involve the user) to discuss if it is required, and if so, add it to the backlog. Don't just add it to the current work item. You might still find it unnecessary when you review it during sprint planning.

Another way to reduce scope creep is by having smaller items or epics. Clear and small goals create focus and leave little room for interpretation. When someone wants to add a new feature, it's easier to decide whether it delivers on the original goals.

Avoid assumptions

I would say "assumptions are the root cause of all evil". Well, in project delivery, anyway. Making assumptions is risky. If it doesn't work the way you thought it would, it'll lead to unplanned work. Additionally, if the team has only noticed the assumption is incorrect near the end of the project, there's a potentially much higher cost to addressing it than earlier in the project.

Examples include assuming a feature will work with another system or two items tested independently will work together. Don't assume and instead have a test item to do an integration test or, better yet, automate the test and include it as test criteria. Another example is assuming some new technology will be easy to implement. For these, always do a quick investigation to confirm it early. There will always be unknowns and complications in a project, so the best you can do to de-risk the project is by left-shifting unknowns and uncertainties as early as possible. The earlier you know about the problem, the better you can adjust.

Review progress often

Regularly review the project progress to see if everything is still on track and if the team is still focused on the original goals. Has any new information been learned along the way that might change behaviours or the design of a later item? Has a feature creep been added where everyone thinks it is the main goal and now spending too much time enhancing it?

Checking progress doesn't mean micro-managing the team or constantly checking what your colleagues are working on. Instead, this should be a team effort with a visual dashboard and process to help the team stay focused and improve. Following Agile Scrum's daily standups, retros, and sprint reviews are a great place to review goals and practices and see if anything looks off track.

Last thoughts

Once the project has started, treat the project as though it is already falling behind. Because statistically, it will. So try to do everything you can not make it fall further behind. This means prioritising items of the highest value or dependencies first, being pedantic about not introducing feature creep, and looking at any risk or unknown as early as possible to understand the impact and adapt. For your team, be politely persistent in reminding them about the general delivery traps discussed. And like a ship in open water, while we can't plan for all the unknowns, we can increase our chances of reaching our destination on time by regularly monitoring our direction and progress and adjusting as needed.