Things go wrong all the time, be it life or a project (More so in projects). Nonetheless, we need to be able to handle it rather than just putting more pressure on the team to work more hours. The delay reasons could be multiple and in the end, it doesn’t matter what or who caused the delays. What matters is you are at the helm of it (or your neck is on the line) and you have got to make it work.

There are a multitude of things one can do to improve the situation and bring back the project to green. And the changes or improvements can be brought on different facets of the projects. Here are a few things on the requirements front that you can check to salvage the situation or prevent it from going bad to worse.

  1. Ban Scope Creep – A very usual reason for delays is scope creep. Due to the rush and/or negligence there, the team forgot to check what was agreed. The moment the project timeline starts to slip, that’s the first area where we should look into. Was that fancy button in the agreed designs? The complex business rules being implemented are they part of approved user stories or have they been introduced recently? Are the developers enjoying making the look and feel good a little too much? Get someone to audit the scope against the implementation and from hereon assign a SPOC who guards the scope with his life (ok maybe not his life).
  2. Negotiate on the ‘Must-Haves’ – If you can’t build everything in time then it’s always good to conduct the MoSCoW exercises to ascertain what are the must-haves for the project deadlines. Often these conversation begins with a blanket statement that ‘everything is a must-have‘. Sensitize the stakeholders about the timelines and ask them to revisit, or offer them a tradeoff of functionality vs the timely delivery. You should at least be able to shave off anywhere from 25-50% functionalities for the first deliverable scope. Note that this exercise can and should be done in multiple iterations.
  3. Offer Incremental feature builds – When you negotiate the must-haves, often there will be resistance from the business or end users. The key is to make it clear that you are not getting rid of all non-must-haves but can offer those as part of the incremental builds after the first deliverable has gone to production. You can chart a plan for incremental builds which will show when after the first release the business can expect the remaining features. This could put them at ease and the team can also focus on the first release.
0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Inline Feedbacks
View all comments