3 ms·

Ask HN: How do you handle rapidly changing requirements for a project

3 points by trustfundbaby 15y ago

A little background ... I'm working with a project where the client will define requirements for us, we'll give estimates, then they'll change the requirements ... maybe drop one or two, refine another one, or change one completely so that we can hit a certain number of (agreed upon) hours for the project. Right now we're tracking these in microsoft word, but its very cumbersome ... sometimes something will sneak in that we weren't paying much attention to (minor disconnect between the project manager and the developer), or we'll lose something and have to search through a bunch of emails to find it. So I was just curious to see how others handle stuff like this, what do you use to track changing requirements before (and sometimes during) a project? JIRA? lighthouse? Pivotal Tracker?

paulhauggis 15y ago
It's a losing battle. I've had lots of experience with this. Here are the possible scenarios: 1) You will never finish 2) you will finish, but many times over the deadline 3) your customer will blame you 4) you will lose money on the project Get the requirements in writing, don't allow the customer to keep changing it. If they want to change it, make sure you let them know how much money/time it will add onto the project.
- trustfundbaby 15y ago
  Ahh right ... I see where you're going but that's not the case with this. Its just a back and forth trying to nail down the specifications for the project. Once those are set, we don't change them unless they go through a change request process that we have. They're good clients I promise :D The issue is just trying to track when a small requirement like "submit button should change color on hover" changes or is removed entirely. just as an example of course.
damoncali 15y ago
I'd be a bad entrepreneur if I didn't plug my own product here: http://trackjumper.com http://trackjumper.com - I took a spreadsheet-based bug tracking system from a previous startup job and made it into an app.
- trustfundbaby 15y ago
  Thanks ... we have bug tracking software, I was just asking about handling changing requirements
rogerbinns 15y ago
It isn't clear if you asking a technical question or a social question. For the latter the usual problems are visibility and acknowledgement. Visibility means the client doesn't really know what is going on. Sure you can email a Word doc whenever it changes, but that is unsatisfying. If the client can go to a URL and see the live state of things, especially a prioritized list of outstanding work then they will have a far clearer picture of the current state, how it changes over time and the impact of their changes. Acknowledgement is how you deal with new requests. The client is being creative (in a good way) and have yet another idea of how to improve things. Saying "no" to them (it wasn't in the original requirements) is not something they want to hear. It is a good idea to always add new requests to the list as this acknowledges the client and makes them feel better. I always have a milestone/version/release called "Blue Sky" which is where most of these go. But if the client wants it elsewhere then they have to look at the list of outstanding requests and work out which ones get demoted. Be careful with the granularity of items in the list. Having one item be "Add LDAP" and another "Change title colour" when the former takes 4 weeks and the latter one hour may be apparent to you, but not to them. You can either break big ones down into pieces that are at most a few days, or change the title eg "Add LDAP (4 weeks)". Once you have visibility and acknowledgements it will become a lot clearer to both parties on the impact of change and what can be done about it (change priorities, spend more/less, reduce scope of items etc). And sometimes those Blue Sky items turn into gems.

3 points by trustfundbaby 15y ago

paulhauggis 15y ago

It's a losing battle. I've had lots of experience with this. Here are the possible scenarios: 1) You will never finish 2) you will finish, but many times over the deadline 3) your customer will blame you 4) you will lose money on the project Get the requirements in writing, don't allow the customer to keep changing it. If they want to change it, make sure you let them know how much money/time it will add onto the project.

trustfundbaby 15y ago
Ahh right ... I see where you're going but that's not the case with this. Its just a back and forth trying to nail down the specifications for the project. Once those are set, we don't change them unless they go through a change request process that we have. They're good clients I promise :D The issue is just trying to track when a small requirement like "submit button should change color on hover" changes or is removed entirely. just as an example of course.

damoncali 15y ago

I'd be a bad entrepreneur if I didn't plug my own product here: http://trackjumper.com http://trackjumper.com - I took a spreadsheet-based bug tracking system from a previous startup job and made it into an app.

trustfundbaby 15y ago
Thanks ... we have bug tracking software, I was just asking about handling changing requirements

rogerbinns 15y ago

It isn't clear if you asking a technical question or a social question. For the latter the usual problems are visibility and acknowledgement. Visibility means the client doesn't really know what is going on. Sure you can email a Word doc whenever it changes, but that is unsatisfying. If the client can go to a URL and see the live state of things, especially a prioritized list of outstanding work then they will have a far clearer picture of the current state, how it changes over time and the impact of their changes. Acknowledgement is how you deal with new requests. The client is being creative (in a good way) and have yet another idea of how to improve things. Saying "no" to them (it wasn't in the original requirements) is not something they want to hear. It is a good idea to always add new requests to the list as this acknowledges the client and makes them feel better. I always have a milestone/version/release called "Blue Sky" which is where most of these go. But if the client wants it elsewhere then they have to look at the list of outstanding requests and work out which ones get demoted. Be careful with the granularity of items in the list. Having one item be "Add LDAP" and another "Change title colour" when the former takes 4 weeks and the latter one hour may be apparent to you, but not to them. You can either break big ones down into pieces that are at most a few days, or change the title eg "Add LDAP (4 weeks)". Once you have visibility and acknowledgements it will become a lot clearer to both parties on the impact of change and what can be done about it (change priorities, spend more/less, reduce scope of items etc). And sometimes those Blue Sky items turn into gems.