Problem: It seems with almost every development effort I\'m involved in, no matt

Question

Problem: It seems with almost every development effort I'm involved in, no matter how much time is spent planning prior to starting development, there is always a large amount of changes required either midway or towards the end of the project. These are sometimes big changes which require alot of re-development.

I don't work for clients who pay money, this is an in-house development team on in-house development websites. So, it's not like I can charge for it or anything. And at the end of the day, we have to try to hit deadlines.

Questions: What are some of the best ways you guys have found to minimize and prevent spec changes from cropping up midway or after development?

Explanation / Answer

There's a famous military saying, attributed to Helmut von Moltke: "No battle plan survives contact with the enemy". In the same vein, I do not think it's possible to make a spec that will not have to be changed - not unless you can predict the future and read minds of the stakeholders (even then they may not have yet made their minds, even if they claim they did). I would suggest instead approach it in a number of ways:

Make a clear distinction what can be changed and what can not. Communicate it clearly to the stakeholders, make them explicitly sign off on unchangeable things as soon as possible.
Prepare for the change in advance. Use code methodologies that allow to change the changeable parts easier, invest in configurability, encapsulation and clear protocols that would allow parts to be changed and replaced independently.
Talk to the stakeholders frequently, solicit feedback and approval. This would both keep you in sync and avoid them claiming "oh, that's not what we wanted" when it's too late. As noted in other answers, agile methodologies and frequent mini-releases would help you with that.
Put into the schedule the time to accomodate the inevitable changes. Don't be afraid to say "we will need more time" early if you think you would - if the schedule you're given is unrealistic it's better to know it (and have you on the record saying that) at the start than at the end.
If the changes are too extensive and threaten the deadline - push back and say something like "this change is possible, but will push the deadline by X time, make your choice".
Make a formal process of requesting changes, prioritizing changes and assigning changes to versions or releases. If you could tell people "I can not do it in this release, but will be happy to put it on schedule for the next one", it's much better than saying them "you're too late, your change can't go in, goodbye" and would make them your friend - they'd be happy for you to release in time so you could be free sooner to get to the next release which will have their change - and not your enemy.

Related Questions

Navigate

• Browse (All)
• Browse P
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.