On Fri, 2004-04-23 at 22:38, Wayne Wilson wrote:From my experience, both of these comments are often true. I wasn't so much interested in the "best practice" claim of the article as the other points made in the "key success factors" section of the BCS paper, particularly: Evolutionary project management, Requirements management, Change management, Measuring progress, all of which are mostly done badly in places I have worked.
|
I find 'best practice' to be most often a management technique, rather
then an engineering practice. Having engineering practice available is
no guarantee of success, it all depends upon the people doing the work
and the managment support structure in place. These day's engineers do
a lot of work finding the 'marginal' limits in order to reduce costs.
It seems to me that 'best practice' in IT projects very often ends up as
a slavish adherence to some formulaic design or management
"methodology", in a focus on process takes over from a focus on outcomes
and after a while, everyone switches off their brains and just follows
the prescribed script. Huge reams of design documents and other
"essential" paperwork are spewed forth (often by automated tools). If
the project is lucky, after a year or 18 months, suddenly someone wakes
up and says "Hey, all this stuff we've been doing doesn't look right".
Tim is right that 'best practice' is often a paper-laden attempt to make a generic, recipe-driven approach to software work, and fails to take into account creative discussions and other human communications.
- thomas
