How to deal with frequent requirements changes?

Question

I'm dealing with pretty stressful (in my opinion) situation in my current work place.

We've started developing new project, get some requirements, implemented it and then show to someone you can call a 'business advisor' (person who knows business requirements but will not use the program). That person is supposed to evaluate application from customers point of view, test it etc.

Here how the 'process' looks:

1. business advisor talks in the evening with my boss for hour or two on windows messenger
2. the next day I receive email with copy of that conversation. I am supposed to choose tasks from that, check reported bugs (which often aren't bugs, just poor testing and forgetting about past establishments)
3. I implement changes, implementation gets accepted and then in a week or two it turns out that isn't want they want (they talked with some potential client that have seen software for 5 minutes and he suggested changes) - I have to do new changes

Don't get me wrong, I understand that sometimes requirements change. What upsets me is how often the change occur in my workplace and how easy for 'management' is two give new requirements or sometimes fundamental changes to existing features.

At the same we working on tight deadlines and I have impression that instead of going forward with our software we're running circles.

I seek advise from you how to deal with this situation? Is this normal situation and I'm just hypersensitive about it?

Answer 1

If at all possible, take the conversation you're emailed and turn it into a requirements document. List the tasks that you can glean from it and order them by what you perceive to be the priority and assign an estimate to each. Then ask which features they want for the next release.

Basically, force some kind of feedback loop where the management is aware what is it that you're going to build. Write your own requirements documents until such time as they get the message.

Story Cards

I think your situation is well suited to introducing user stories. They're really helpful in providing an ongoing, interactive way for your manager to set priorities and he can even throw them away when he comes back to the idea a week later and realises it's not workable.

Answer 2

In the real world, requirements change routinely. On the plus side, you find out about it before you finish building the software and ship it out - you have a tight feedback cycle from the direct user of the software, which is actually great.

It seems like the biggest problem here is the very ad-hoc way that change is managed. You have what agile / Scrum consider a "product owner", who gives feedback, but the process is poorly documented, and poorly thought out.

You probably want to look at the models in Scrum, and their view of what an effective product owner is, to help inform your next steps.

So, instead of having this ad-hoc process, aim to move to a world where you have a closer and more useful relationship with the "business advisor", and where everyone is on the same page about the outcomes of the changes they are discussing.

Answer 3

Your current process makes it too easy for these people to just brainstorm ideas with no reguard for the resources and money this will consume. If they want all these features, they need to get some "skin in the game."

Take that email of the conversation and put it into some sort of feature/bug tracking application even if it is just a spreadsheet. Send the new additions back to the business advisor and ask him/her to sign off on each item or provide corrections. Along with the sign-off, they should prioritize (Which ones do you want first?).

After they approve, send them back your schedule on when the items will be completed for testing and get them to commit to a time to do the testing/approval of completion.

I know creating this type of documentation is not why you became a programmer, but you can either risk throwing these lists away or keep throwing your hard-earned code away.

Push back. Those in charge need to see how much these requests are costing.

Answer 4

Requirement changes are not always bad. The key thing is to remember your customer. Likely your boss is your customer in this case. You need to notify your boss that you thing these constant requirement changes are limiting your ability to produce the product which is most useful to him. It is entirely possible that the business benefits from you constantly reacting to changes. If so, that is their business model, and you are doing nothing wrong, though I recommend running for the hills in that case!

People who are frustrated with requirement changes are often valued by how well they manage each change. This metric of "number of changes sufficiently handled" is probably the source of your real trouble. Consider discussing better metrics with your boss. When I am facing constantly changing requirements, I strive to write content that lets me adapt to constantly changing requirements. Instead of running a simulation and analyzing the data every day, I will write tools which make the process of running the simulation and analyzing the data cheaper, and reap the rewards over time. If that is still too crazy, I might even write a tool to write tools!

Answer 5

Your process might benefit from some agile principles, like locked in iterations. I think a week is reasonable with such fast paced changes you're describing. 2 weeks might work better eventually.

Once important enough requirements have been identified, have the person who is in Project Owner role sign off on them and lock them in for a period of a week while you build them. Allocate enough work for yourself to where you will be busy and let powers to be know of your allocation. i.e. if per week you can produce work of 16 points, and you have 16 points of work, then you are fully utilized for that week. (The points concept comes from agile work-stream)

If changes come in in the middle of the week, utter these magic words:

I can do [this new feature], [this new change], [etc], but what do you not want done?

That is, you are a limited resource, you can only take in so much work. If a new item of work comes in, you are allowed to be the limited resource that you are and assign points to the new item and drop/change other items in lieu of this new coming-in change. Re-prioritize your iteration list together with the project owner and you should be better at dealing with change.

If requirements change more frequently than that, you may need to negotiate more stability in your environment.

Answer 6

The phrase "Requirements change" is sometimes abused by IT people. What you are describing is indeed change of requirements but this may be because one or more of the following (I don't know enough about your case, so the following may or may not apply):

1. Management's ambition to make the end user happy as quickly as possible and show quick progress.

2. Lack of detailed analysis. Remember that Analysts need to ask questions about why not only what. The analysts needs to "think" with the end user about a "solution" not only take orders.

3. Lack of a formal process for requirements verification and confirmation, followed by approval.

4. Asking the incorrect person to perform one or more roles they are not necessarily trained for such as Business Analyst or Systems Analyst roles.

5. Limited prototyping.

6. The assumption/fear that it has to be done quickly and if not its IT to blame.

Unless one addresses all of the above properly, the relationship between IT and the business/end user will be stressful. Please note that this does not imply that the above point are conclusive. There are other factors that leads to stressful situations similar to your situation but I think this list should get you going.

Answer 7

I think you should approach this from a few directions:

1. Have all the stake holders (including the entire development team) meet (offline/online) with the business advisor and try to understand the domain, the vision and then brainstorm requirements together.

2. Formalize requirements/user stories, grading each one's:
   a. Priority (urgency/importance)
   b. Maturity (how well defined it is - understood and agreed on by majority of stake holders *)
   c. Complexity (rough estimate)
   
   When choosing which requirement/user storie to work on next, taken all three factors into account. If the requirement has low maturity, add a research mission before it, in which you contact all stake holders, investigate the reasoning behind the requirement and better define the requirement (write use cases and/or create wire-frames and present them) before acting upon it.

3. Try to think a few steps ahead while designing before each implementation - design a flexible architecture that has room to accommodate changes.

4. Try to adapt an agile development process e.g. SCRUM or Kanban - this will provide you with a toolkit for developing a product with changing requirements.

You should also consider asking the moderators to move this question to PM.stackexchange.com (by flagging it) as even though this question fits here, it would fit there better.

(*) Stake holders for agreement: business, marketing, project management, development and QA.