"Phlip" <phlip_cpp@yahoo.com> wrote in message
news:1Iled.22839$Qv5.2784@newssvr33.news.prodigy.c om...
Quote:
Scott Kinney wrote:
Quote:
|
Maybe, maybe not. You'd need to evaluate the risks of the specific project, and the volatility of the requirements. Believing that all requirements change willy-nilly is as misguided as believing that
|
|
none
Quote:
|
of them can. You may actually have understand the specific project at hand to make those assessments. You keep saying "nobody collects requirements like that".
|
I suppose what I should say is that neither I nor the 20 or so project
managers I've worked with over the past 18 years manage requirements
like that. Ron continually suggests that I've had an unusual and sheltered
career.
http://news.com.com/Avis+blames+IT+...ml?tag=nefd.top
Not to put too fine a point on it, but there was no mention of a
requirements
process, how requirements were collected, or even *if* requirements were
developed by Avis.
Quote:
|
When you buy an off-the-shelf ERP package, you endure a requirements phase committed before the code's authors ever met you.
|
True, but trivial, in that it is also true of any software package one buys
from ERP to Photoshop. If your purchase isn't guided by some notion of
what you need to be able to do, why are you buying it?
Quote:
|
That might be a reason these things have a reputation for providing little more than an eternal IntegrationHell...
|
I think there are better reasons. I've seen two basic approaches to
'big software' implementation succeed. There are probably others, but
these are two that I've seen succeed more than once (each.)
1. There are clear, explicit statements of business functionality and
evidence.
"I need to be able to do........" This set of (gasp) requirements drive the
implementation and customization. When the vendor complains that the users
'just don't get' the sheer brilliance of their concept; the users reply that
they
don't give a f*k about the sheer brilliance, they need to be able to do 'x'.
This works well when the user population has a lot of experience in their
business process.
2. The implementation team, being cruel to be kind, implements a very basic,
workmanlike set-up. The users play with it, use it in its current state,
develop
ideas about how to 'grow' the applications, then they jointly embark on an
approach to evolve the system to something more sophisticated. This works
well when the users aren't terribly experienced in the processes embodied in
the
package; and I think ERP tends to fall into this category.
Big Requirements Up Front
Linear Mode
