

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

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.<p>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.<p>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?<p>JIRA? lighthouse? Pivotal Tracker?
======
rogerbinns
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.

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

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

