Cutting off features or delay schedule (close to code completion) [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

would like to explore what are the general practices in

2. dropping features
3. make a decision to delay the project schedule
4. design the features in a way that can be dropped with lesser pain
5. delay a project s开发者_JAVA百科chedule with good estimation without re-delay again
6. preparation for project completion to avoid delay in schedule

Please note that it is not a question on schedule planning or management but more focus to time frame close to project completion.

I understand this is a question with no absolute answer.

---

If you get to this point and you don't have a plan, you're already in over your head. Most likely people are getting panicked and worked up and probably not thinking straight. That's also why people do fire drills. So that if the time comes to do it, they already have the process in place.

In this case, as soon as you start a phase of the project, you should have a prioritized feature/bug list in place. And then there should be two cutoffs to the list. The first one is the bottom of the list and includes everything. The second one is the minimum allowable for that deadline/release. And yes, they should be different. Think of them as the "must have" and the "nice to have" list.

Now that you have everything prioritized and you've set expectations that "if things run late, we start dropping things from the bottom", you'll have a much easier time in doing so if you have to. And of course, just because you drop it for the immediate deadline, doesn't mean you have to wait until the next big delivery for it... maybe a point release or an interim delivery is acceptable?

Or maybe the things that were dropped aren't all that important anyway? If that's the case, they may always stay at the bottom of the list and you may never get to them.

All of that said, it doesn't necessarily hurt to try to delay the date as long as you deliver what you have to. You can always ask and lay out your case and see what happens.

---

From the business perspective, you might have none, some or all of the above options available, e.g. if your contract says "by date X or you get no money", than you can only try adding resources or cutting requirements. Since you're close to project completion, adding more resources might be counter-productive.

Contract constraints aside, if you want to limit the scope, you should identify dependencies between features and have them prioritized by the user. It should go without saying that you do nothing unilaterally: whatever you do, make sure the customer is on board, even if he/she/they are not pleased by the situation (which is likely to be the case).

Delaying the delivery date is what happens most of the time: the best you can do is to react as soon as possible and keep the customer's expectations realistic. While this is painful, the customer is likely to appreciate the fact that he/she/they can adapt their own plans and avoid damage propagation (cancel or delay marketing plans etc.).

Estimates deserve to be mentioned separately. Estimates should have been available at every stage of the project. If you are not going to be on time, it is because you've spent more time than planned on completed tasks, because you feel the remaining tasks are more complex than anticipated or both. Update your estimates and let the customer know: use them to support your new proposed deadline. Including free support or an unplanned feature or two to make up for the delay might be easier to bear than transferring money, if the option is available.

It's a big subject: this just skims it.