Be Prepared for Delays

Be prepared for delays and build them into your project plans. Sometimes, delays cannot be controlled by the developers. When discussing timeline, make sure you ask if this timeline includes expectations of delays from bugs and other variables, or if this timeline is reflective of everything going smoothly.

‍

This is a great question because all timelines should account for inherent delays so you as the client can be best prepared for an accurate launch date. Each milestone deadline should come in with a risk assessment. Ask your developers to identify any risks associated with delivering each milestone or major feature, and the effect on the timeline should the risk be realized.

‍

Building the risks into your timeline

If you have your development team identify these risks beforehand, you'll be prepared if those risks do come around. You don't want to be blindsided by a risk, and you'll be prepared for the potential delay in each scenario in advance.

‍

There are two broad classifications of delays that can occur: developer related and external. Here are two brief examples:

‍

Developer related delays

There was a bug in the code that wasn't caught by unit tests or QA, and was pushed to production. Your development team will need to roll back production to the version without the bug, and fix the bug before pushing another build to production.

‍

External delays

If you need access to a third-party API, let's say to integrate Facebook login on your product, you need to conform to their API limitations. Sometimes the third-party service won't have everything you need, sometimes the provider will revoke your access to their system without warning. The developers don't have control of this, they can only adapt to the hand being dealt to them.

‍

It's much easier to predict and account for developer related delays since your development team is ultimately responsible and in control of the situation. For external delays, you're entirely at the mercy at the provider of the third-party service. The best you can do is to have your development team come up with alternatives to all the third-party services you use should you lose access to one.