60

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?

Improve this question
13
  • 9
    establish a Feature Freeze milestone in development and arrange / negotiate things in such a way that all feature requests submitted after that milestone go to next release not to current one. Key point here is of course to plan for more than one release ahead and share this understanding with clients
    – gnat
    Jan 26, 2012 at 9:27
  • 4
    @gnat You are assuming that the OP works at an organization where putting in place a Feature Freeze milestone would be acceptable to the stakeholders. Based on personal experience working on in-house development teams, if I were to propose such a thing the stakeholders would stare at me and say something to the effect of "Who the hell do you think you are telling me when I can and cannot change my feature requests on a whim? What do you think I am paying you for? Know your place."
    – maple_shaft ♦
    Jan 26, 2012 at 12:48
  • 29
    Have you tried saving the spec in a read-only file?
    – orlp
    Jan 26, 2012 at 14:42
  • 14
    Of course you charge them: every change to the spec delays the release, so your response to a change request should be an estimate of the new release date if the change is added to the spec. Whoever asks for the change is responsible for the delay, and needs to explain it in exactly the same way as one would explain expenditures.
    – Simon Richter
    Jan 26, 2012 at 17:57
  • 7
    Isn't this why Agile exists? You can't freeze the spec so make your process handle a changing spec.
    – Craig
    Jan 26, 2012 at 20:43

16 Answers 16

Reset to default
88

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.
Improve this answer
10
  • 3
    You can also 'freeze' them in phases and push changes into the 'next version'.
    – Grant Thomas
    Jan 26, 2012 at 10:43
  • 3
    Formalising the change process and being clear on scope is great advice - if you are doing fixed scope/price contract work. In other settings, this approach grinds since it gives schedule and price precedence over scope and quality. Maybe that is what you need in a given situation. But then again, maybe it is not...
    – tardate
    Jan 26, 2012 at 15:15
  • 3
    +1 for number 6. I had an excellent experience with the PM implementing that requirement alone.
    – Joshua Drake
    Jan 26, 2012 at 15:31
  • 3
    Short cycles are key. People are much less upset about something getting pushed into the next two-week sprint than when the "next release" is six months away.
    – Adam Jaskiewicz
    Jan 26, 2012 at 18:29
  • 1
    "invest in configurability, encapsulation" is very, vary dangerous advice. It can too easily lead to inner-platform effect and empty layers of abstraction, both of which actually make it much harder to change a system. The most easily changeable system is the one that is most simple.
    – Michael Borgwardt
    Jan 27, 2012 at 8:47
40

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.

Improve this answer
23

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.

Improve this answer
7
  • 2
    NASA does it with some of their software, or at least good enough to send shuttles into space. The thing is that they actually follow the waterfall model. The spec is actually frozen. At least this is my understanding from outside the organization.
    – Joshua Drake
    Jan 26, 2012 at 15:34
  • 5
    I've worked on several projects where we were able to completely spec out fairly significant systems (telephone switch adjuncts). The key in all these cases is that we were targeting hardware that had already been developed, and were developing to published (ITU) specs, so neither could change. So your argument doesn't hold for all projects -- just 99% of them! ;)
    – TMN
    Jan 26, 2012 at 16:06
  • @TMN: I wouldn't agree with 99% either. I think waterfall-like development is far, far more successful than agilists give it credit for. Otherwise, it wouldn't be used any longer. Most projects I've worked on have been waterfall-like. The key is setting a baseline, then any changes that come along are estimated for additional time and money. The customer then decides whether to include the change or not and the schedule and dollars slide accordingly.
    – Dunk
    Jan 26, 2012 at 19:51
  • 1
    @Dunk: I know a big part of our success was our adherence to a methodology developed at Bell Labs. It was real engineering, with complete traceability from requirements to specs to designs to test plans to code to test results to deliverables. When a test failed, you could see exactly which requirement(s) weren't being met, and you knew exactly where to look for the failing code (or failed design). It takes a lot of discipline and oversight to make waterfall work, but you're right, it can work well.
    – TMN
    Jan 26, 2012 at 20:31
  • 1
    @TMN I wonder then which is the key to success. The use of the waterfall model, or your disciplined approach? I am thinking the later is the more important of the two.
    – Ross Goddard
    Jan 26, 2012 at 21:06
19

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.

Improve this answer
3
  • I don't know why this hasn't occurred to me sooner, but the idea that having code allows one to embrace change easier can't possibly be correct. Is it easier and less time consuming to change some diagrams or to change code? Especially when the change is big. I agree you don't try to prevent change, you simply need to point out the impacts and apply those accordingly to the schedule. Agile embraces change no more than waterfall-like methods. I even think it handles change worse than waterfall since it can be quite a bit more expensive to make changes(depending on when the change occurs).
    – Dunk
    Jan 26, 2012 at 19:55
  • 6
    @Dunk You are correct in that it is cheaper to change a diagram then code, but how do you discover that change needs to take place? Often times this will only occur after you have given the user something to use and he realizes either he communicated the wrong idea, this is not what he wanted, or there are these other things he wanted as well. The trick is to figure out how to discover these changes as soon as possible.
    – Ross Goddard
    Jan 26, 2012 at 21:21
  • @Ross:That's one of the reasons for prototypes. You mock up a sort of working system and get feedback. It is a myth that in waterfall the customer does not know what they are getting until it is done. I have been on projects that were large enough where the UI person/people spend the first several months mocking up a representative prototype in order to ensure the customer is getting what they want. One could contend that using the actual system is better, but if it ends up taking much longer to finish because the code needs to be frequently redesigned then it is not a good trade off.
    – Dunk
    Jan 30, 2012 at 22:03
12

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.

Improve this answer
1
  • Yep. To rephrase the original question: "How can we guarantee that we deliver what the client wanted at the start of the project, rather than what they wanted at the end?"
    – Steve Bennett
    Feb 1, 2012 at 2:37
5

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

Improve this answer
1
  • +1 "Change is the nature of what we do" - I like change. Change can be a good thing. It gives me a chance to see if my design skills were up to snuff or not. If change causes a lot of rework then I did a bad design. It also provides the opportunity to make the design more generic. It gives an excuse to fix what you rushed through in order to meet the schedule. It lets me go back and fix other peoples garbage. Just track the change requests and incorporate them in the schedule so when you deliver later than the original schedule you have evidence to show why.
    – Dunk
    Jan 26, 2012 at 20:04
4

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.

Improve this answer
4

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.

Improve this answer
4

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.

Improve this answer
3

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"

Improve this answer
1

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.

Improve this answer
1

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?)

Improve this answer
1
  • :) If customers want a crazy customization, then they shall pay for it with money and time. If sales people absolutely HAVE to make promises to deliver features that aren't there yet most of the time they make a sale, then the company has a bigger problem overall: it has many competitors and is not at the top of its game, e.g. SyBase database vendor. It will either become irrelevant as a company, or it will need a revolutionary CEO & deputies.
    – Job
    Jan 29, 2012 at 18:21
1

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.

Improve this answer
1

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.

Improve this answer
0

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.

Improve this answer
0
0

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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.