I’m thinking of documentation focused, process map driven, meeting oriented, service level agreement based, gated review, buzzword encompassing, busy work, job-fer-life methodologies. Perhaps there are others but I havent seen them in the wild.
So why Hate?
Well, here is my ‘how to address a business need’ shopping list in preference order (fave at the top)
- Drop in an off the shelf system (nice in theory, rare to find a good match)
- Customised off the shelf system (the breeding ground for big methodologies)
- In house IT team developed ‘mainstream’ system (often relational database CRUD with .net/java/whatever business logic and presentation layers.)
- Professionally developed spreadsheet based system (pro means knows spreadsheets, knows databases, knows coding, knows software development. (funnily enough there aren’t many people who fit this bill))
- and last but not least, an end user developed solution, probably in a spreadsheet (or friendly desktop database).
This list is based on my estimated cost/benefit over the lifetime.
In a great many cases a spreadsheet solution will be the quickest and cheapest, no doubt, but their lifetime is often short, and they can be a maintenance burden.
The purveyors of snake oil methodologies are mainly feeding off their big consulting firm background in implementing massively customised, big fee earning ERP systems in the job-fer-life timescales. End user developed spreadsheet proliferation is the direct response to the gross user neglect that is core part of these big systems. ‘Take the pain now, we have a brilliant system that will fix this’… in 2017! Isn’t SAP the one that no-one has actually finished implementing yet?
In a 100 dev year, assembly coded, man-on-the moon project, yeah, sure bring in a heavyweight methodology suitable for life critical systems. For a two week spreadsheet spring clean? give me a break. For modern business systems tools like .net and java etc I think the tools are powerful enough that if the initial design is good the tools can be used to adapt to the inevitable emergent requirements.
The idea that a burdensome methodology will improve business systems quality is utter nonesense. The handful of systems that finally makes it through might be of some sort of higher quality by some measure somewhere. But the shanty town of spreadsheet hell that sprouts up to cover those things that didn’t make it in or out really really isn’t an overall step forward.
These methodologies always stink of waterfall to me, and surely that is the most discredited swear word in business system development.
I think these plan, document, approve, analyse, document, approve, design, document, approve…. processes really increase the risk of building the wrong thing too late. To me they are just so much more risky than partnering with the business to jointly develop the required system with trust. And they back load all the risk as the customer gets zero value until close to the end when if the system meets their then current need all well and good. Compare and contrast with iterative development where the customer gets a rough partially working system that address their most critical needs first and then is gradually extended and expanded to meet their developing need. These methodoligies don’t consider this because they were all developed back in the 60’s when the waterfall was the bible and C was just a glint in K&R’s eyes. (remember the 60’s was 50 years ago!!)
So when the the IS department implements their SLA based, documentation heavy, change control hell what actually happens?
Crap spreadsheets spring up absolutely everywhere (thats the least favourite from above for the hard of reading (I didn’t put offshoring on there)). Like the most tenacious of tenacious weeds these instantly become a huge support burden. The support effort takes away from the replacement development effort and the whole thing spirals down out of control like a dying fly that got burnt on a (non eco, non carcegenic old skool filament) bulb. Buzzz..t.
So thats why I hate them – they directly cause a massive deteriation in organisational data quality and cause major paralysis, scores of missed business opportunities, and lots of frustrated business people.
And thats why I love them – those frustrated business people who are busy building castles in the sand with their ratty spreadsheets who have just had their confidence in their in house IS team shattered will be wanting someone to fix their spreadsheet hell at some point. Thats a job for us.
The other reason I love them is even more mercenry. Places I have worked that adopted these heavy methodoligies have a rapid loss of their more dynamic staff. So there are normally a few vacancies there too. And as a contractor you don’t normally have to adhere to their box ticking extravaganza.
So: hate they because they kill organisations love because they provide great work opportunities.
My biggest relief is that I didn’t cough up for that Prince2 course I considered years ago – I couldn’t work in a Prince2 environment so I’m better off with it not on my cv.
Any of you hiding behind an SLA? checking your traffic light (or kimball ball these days, fashion, eh?) progress KPI dashboard against the inevitable landscape printed gantt chart? (what size paper is yours?(dot matrix fanfold??))
How many of you have worked on short term systems whilst the customer waits for the ‘big fix’? (I have, loads)