CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Darrell Norton's Blog [MVP]

Fill in description here...

The Golden User Rule

It should be a well-known fact that user involvement is one of the most important factors in a successful software development project. If you get the wrong user, like someone who is not representative of the real end users, then you get the wrong system. This was summed up nicely on a web page I recently read (no link, sorry!):

“The 'Golden Rule' is 'The User you need is the one they won't let you have!'”



Comments

Scott Galloway said:

So many of our cases are where the end user actually has no idea what they want beyond a vague notion...which is in many cases worse than none at all...
# July 29, 2004 4:39 AM

Darrell said:

Scott Galloway - been there, done that, got the t-shirt! The usual result of the "vague notion" syndrome is constant requirements spinning, which is demoralizing to the development team in most cases. Constantly changing things and having "users" tell you that you aren't doing things right, when you are but they just don't know what they want, can wear down even the most upbeat developer.
# July 29, 2004 5:09 AM

Eric Wise said:

Which is precisely why I'm enjoying consulting. You want to change the spec every day? Hell go ahead, the more changes I make the longer I get to bill. =)
# July 29, 2004 6:06 AM

Darrell said:

Eric - which is why consultants should bill BY THE HOUR, not by results. Results that are hard to measure give customers a reason not to work too hard on the project.
# July 29, 2004 6:11 AM

Jennifer said:

I believe it's a bit unethical to bill people while they are figuring out what they want. Maybe lawyers do some of this with what they work on; divorces come to mind.

The profession has a duty to help users (especially non technical ones) figure out what they want and keep it like that for a series of deliverables. Every work product is a rough draft, and there is a "done" point on a rough draft. You do need to move to rough draft #2 at some point, but you must find the "done" point. It might take you 5-6 rough drafts, but each one can be working toward the end product. If you have to scrap the entire draft, you have to start over.

There is a difference between substantive editing, and fixing grammar. Most of these small changes in development are like fixing grammar. The big changes are like rewriting an entire section (aka substantive editing); you have to determine what you are working on and when. Even great works of literature or books on the shelf (published as they are today) are probably not "done," and the author could still make improvements or changes.

The users need a semi-finished product, and we need credibility in the industry. Or otherwise, you get the CRM, ERPS, and huge disaster projects that spend tons of money and waste resources. These hurricane-like projects are giving people reasons to outsource, in addition to affecting team motivation, energy, and attitude.

We have an obligation to do quality work, manage the requirements process, and get user feedback in a tightly integrated approach, so users and customers experience value.
# July 30, 2004 1:17 AM

Darrell said:

>> I believe it's a bit unethical to bill people while they are figuring out what they want. <<

I don't if they are taking up my time figuring it out. If they want to figure it out on their own, and then call us in, fine. What happens if you don't charge users while they "figure it out" is they continually change their minds back and forth because there is no cost to it. Even when there is a cost to it, the frequently waffle back and forth (I have witnessed it way too frequently for it to be a chance occurence).

On the other hand, if they are paying, then it is our job as consultants to help them figure out what they want as quickly as possible. As long as the consulting company is ethical (both of my employers so far have been), then this will proceed as quickly as possible. I agree that there are other consulting companies (big ones) that really just want to ramp up staff as much as possible. That's why I would never work for one of them. :)
# July 30, 2004 1:42 AM
Check out Devlicio.us!