How to stop the development spec from changing in mid development?

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?

Answer 1

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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".
6. 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.

Answer 2

Deliver something (I hesitate to use the word anything) early and deliver often. That is - use some sort of iterative development methodology.

This is the basis of Agile development, but can be used with (almost) any methodology.

By breaking the project down into a series of mini projects you get more control as you can put something in front of the client early, you're not locked into a long development schedule that becomes out of date when the client changes their mind (as they will).

When they see the system evolve, some requirements will change, some will become redundant and others will increase in priority. However, by having a short project life-cycle you will be able to cope with these changes.

Answer 3

The theory that it is possible to completely spec out a software project of any significant size is a complete fantasy. This theory has been found not to work in organizations from large to small for pretty much the entire history of software development.

You MUST find some way to accommodate changes as you go! They ARE going to happen, because most of the stakeholders, even if they say 'yea, that's what I want' actually have no idea what they want until it's in front of them. That's why we have so many folks adopting iterative methods.

Whether you iterate the product or whatever, you MUST find some way to accommodate these changes, because trying to find ways to not have changes is just short of asking gravity to turn itself off for a few minutes so you can go flying.

Answer 4

Don't try to prevent change, embrace it. The more you plan ahead, the more likely your plan will change. So, plan less, not more. Adopt an agile development methodology where you deliver small chunks of working code frequently, giving the customer the chance to change the specifications every couple of weeks.

Answer 5

You're asking the wrong question. Spec changes will always happen in software development projects of any size.

Often it's because business requirements change but I've also seen it happen because customers (internal or external) can find it hard to visualise what is possible without seeing something to iterate from, so they have a vision which slowly changes as they engage with the developing solution.

The question you should be asking is not "how can I lock the spec down", it's "how can I structure my code and processes to respond to a changing environment without throwing away everything I've already written?"

This then leads you into the buzzword bingo arena: agile methodologies, iterative development and technical solutions such as component based / modular coding, continuous integration... the list goes on.

I'm not saying these are a silver bullet to all your problems but they all came about because of a desire to manage the very situation you're describing so at the very least they're worth some investigation.

Sorry if that's not offering concrete solutions but I tend to think a mindset shift into accepting and managing change will pay bigger dividends than trying to avoid it.

Answer 6

A change is only a surprise ... if it's a surprise!

I'd suggest thinking about:

• where on earth do these changes come from anyway?
• why aren't you aware of them earlier?
• why aren't you contributing to these changes (and potentially making even more of them)?

Change is nature of what we do. Since when did you code an algorithm exactly as envisioned on day 1?

But if you want to avoid perpetually being the frustrated developer "surprised" by changes, I think you need to find you way closer to the action of where decisions are made. After all, I'm sure you have a bucket load of ideas of how you could make the product better. Get a seat at the table, or forever accept that you will just have to deal with those "surprise changes".

Answer 7

Active user involvement throughout the development cycle, and use of as much Agile methodology as possible really helps us with our products.

Spec changes are inevitable, but by being transparent with users and above all, frequently consulting them means most changes are captured as early as possible.

Answer 8

Well thats a though call, clients always want more but here are a few point you should consider:

HTML Mock-ups: Always create HTML mock ups to define the UI part of an application, show them how will it look like and ask them for their opinions. If you find anything reasonable to change make it happen in the HTML prototype. Using this you will sort out lots of things like UI issues, basic flow and some add ons(like Sorting, Pagination, no. of records to be displayed etc.)

Active Participation from the other end: This is very important if you are developing for a business organisation, get in their business ask them to clarify your doubts and without fail ask them what changes do they want in their flow (if required).

Modular release: Release your code in a modular fashion, release, test, take feedback and release again.

Answer 9

This is why it is nearly impossible to plan too far in advance, but not an excuse to not plan at all. Don't fall too deep in love with your plans and you won't have to worry about them breaking your heart.

Inside your company there is a cost to using the IT resources whether anyone admits it, tracks it, or has to budget for it or not. The reality is, your team can only create so much code in a certain amount of time. All departments and projects are sharing in this budget.

You can't prevent anyone from wanting to change the requirements, but they cannot escape the consequences. Changes can significantly increase development times. That is a fact they have to deal with or decide not to make the change. Does a request from one department affect another? You may have to completely move their project behind another departments because the change request will encroach on another group's time schedule.

Answer 10

For me it's quite easy.
Tell the one, the "Product owner", who have ordered the features that this is OK, but he have to choose a couple of planned feature he could be without for this deadline.
Think of it as a half sprint meeting with the PO where you tell him that the sprint wont burn down to 0.

Ps. If it's not the "PO" I would say don't talk to me go thru the "PO"

Answer 11

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

There are no best ways. It is up to the management to limit the changes to spec in the certain phase of the development.

However, you should design your software in such a way to expect the changes. Then the impact of changes would be much less. Iterative and incremental development is a good start.

Answer 12

I've found that, directly or indirectly, customers are the cause of most changes (and also most critical bugs, BTW). So the obvious solution is to eliminate customers. (What good are they anyway?)

Answer 13

Since you cannot prevent change, you need to embrace it. I think the most important thing you can do is: you need to try to get the change requests from the customer as early as possible, because it is less costly to change things when there is only little code. So you need to present your design as early as possible to the customer by using prototypes (perhaps even a paper prototype), use agile methods and so forth.

Answer 14

You could consider introducing some discipline in the development process using a methodology like SCRUM. In SCRUM, a team makes an initial plan by splitting the implementation of features into stories, and assigning each story an effort estimate (number of working hours or days needed to implement that story).

If a late change is requested (for a story that's already been implemented) you need to create a new story and estimate the implementation effort for it. Then you can go to your manager (the product owner) and simply explain that the new feature is going to cost that extra time. The project manager then has the responsibility of accepting the extra effort and adjusting the schedule (possibly cancelling other not yet implemented stories).

Even if your team is not going to fully implement SCRUM or another development process, you could at least introduce the planning based on stories, estimate development effort for each story, and adjust the schedule as new stories are requested.

Answer 15

http://teddziuba.com/2010/05/why-engineers-hop-jobs.html

I spent too many after-work evenings stressed and unhappy because yet another chap does not understand or care how software business works. I have no problem confronting anyone higher up, but I do not have the backing of my fellow nerds. Having kids is a bitch, eh? I will likely quit soon.

Frankly, I wish programmers in general had more balls. Let's look at this:

"""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."""

If you were dealing with a $-paying client and if you covered your ass by having a contract (http://vimeo.com/22053820?utm_source=swissmiss), then changes in spec would cost this client more time AND more money (or potentially same or less time but exponentially more money). Your company is trying to get away with changing the spec without incurring the cost of more time and more money.

In the mean time, trying to hit deadlines causes you and your co-workers UNNECESSARY stress; you cannot spend a quality weekend with friends/family. It really is unnecessary, because whoever is throwing work at you probably do not even know it, which is sad.

My proposed solution: collectively have the balls to confront them and explain that there is no free lunch and everything has cost, that an auto-mechanic would take longer and charge more if specs were changed mid-work, that a contracting agency would take longer and charge more if specs were changed mid-work, and there is a good reason for it. If they are not willing to work with you in a reasonable manner, then you as a group will get up and leave, and they will have to hire developers who can pick up the project where it was left off and deliver on time.

Then there is also a promise of agile development, which implies no hard deadlines.

I am yet to see programmers go on strike, but this would have been something. Incompetent managers are too abundant in software companies. Way too many people want to get something for nothing, on Craigslist or within an actual company. http://teddziuba.com/2011/07/the-craigslist-reverse-programmer-troll.html

Programmers need to have more balls.

Answer 16

An approach I have found that works sort-of OK (not with all managers obviously) is "I think I can do that, yes. It depends - how much extra time are you assigning to this project? It's a fairly major change you are requesting."