From: Andrew Gabb (agabb@tpgi.com.au)
Date: Thu May 27 2004 - 19:17:00 EST
TUCKER, EMMIELOU (CONTRACTOR) wrote:
> Agree that cost should play a major role. Perhaps some of the
> problem is a difference in organizations. Here we find that
> "everything" is essential and must be done until two weeks or so
> before deployment, when it becomes so obvious no one can ignore
> it that "everything" is not ready. At that point hard decisions
> are made about what is really essential and what is not. It
> always turns out that some of the requirements aren't really
> essential and can be postponed to a later release.
I'm quite familiar with this situation. Unfortunately it happens often, particularly when the user and acquirers are in different orgs (or even different sections). The users suspect that the acquirers are going to somehow sell them down the drain - after all, it's happened before! - or acquire the wrong solution (see more below). It also happens when the acquirers/developers are wet behind the ears.
If they prioritise their requirements, the users feel that this allows a line to be drawn, higher than they would wish it. By insisting that everything is essential, they honestly believe that they'll get everything, even within a constrained budget. By taking this line, they sometimes effectively 'divorce' themselves from the acquirers, the source selection, and any tradeoffs which come up during development. Not a healthy situation at all.
The only solution (partial) to this problem is for the acquirers to spend a lot of time educating the users about the dynamics of projects, and the risks that they (the users) are taking in adopting this 'head in the sand' attitude. I've got plenty of war stories about how this situation has gone badly wrong, for all concerned. Unfortunately, users really have little experience in this area, and are strongly influenced by their own internal scuttlebut about malicious and stupid acquirers. Of course, if the acquirers are also inexperienced, the situation is even worse.
This is one of the reasons that iterative methods (particularly evolutionary acquisition) often work well. The users not only get their hands on the system early, but they learn about how the project dynamics work as well - they have to - it's part of their life.
Finally, I've also seen users with very strange requirements, which they refused to justify in any detail. This normally meant that they were trying to 'position' a particular solution - they had the brochures in their briefcases. Coupled with this was a bias *against* particular solutions, usually planted by rival gun-runners and deceptive demos. Fixing these problems was much more difficult and was really a trust-building exercise. Not at all easy and not always successful.
Andrew
-- Andrew Gabb email: agabb@tpgi.com.au Adelaide, South Australia phone: +61 8 8342-1021, fax: +61 8 8269-3280 ----- ------------------------------------------------------------------------------- To send a message to this mailing list send it to re-online@it.uts.edu.au. To unsubscribe from this mailing list, email majordomo@it.uts.edu.au with the message `unsubscribe re-online' in the BODY of the mail.
This archive was generated by hypermail 2.1.6 : Mon May 31 2004 - 09:00:18 EST