Why I love and hate project management methodologies (long)

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)

1. Drop in an off the shelf system (nice in theory, rare to find a good match)
2. Customised off the shelf system (the breeding ground for big methodologies)
3. In house IT team developed ‘mainstream’ system (often relational database CRUD with .net/java/whatever business logic and presentation layers.)
4. 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))
5. 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)

cheers

Simon

Schoolboy Error

As you may have noticed and as I mentioned the other day, I’m pretty busy.

I was just busy, then I got an email mentioning that the Codematic site wasn’t working right.

A quick investigation showed that I had used mixed upper and lower case addresses, and not used them consistently. And of course Linux is case sensitive unlike Windows. I tend to maintain my site on Windas, but it is hosted on Linux. So its kind of understandable, but still  a pain, and still technically a schoolboy error.

Much of the site is generated from building up text snippets in workbook cells and concatenating into .htms in VBA. But its all a bit higgledy piggledy.

I did contemplate moving it to a dynamic site but actually the content is not that dynamic and to me it makes sense to generate it as .htms rather than burden the server with processing a load of php and sql for every page request. I think what I need is a better way of managing and generating the site, one day. (suggestions welcome though…)

In the meantime I have updated the site to use just lowercase addresses and have added a 404.php to attempt to redirect anyone using a mixed case address to the lowercase equivalent, or the home page.

If anyone spots any more problems (I know I still have one directory reference to update, but that will have to wait) please let me know.

I’ll post more about the other things keeping me busy in the near future, I think this one is resolved for now, unless anyone tells me different…

cheers

Simon

Busy Boy

Sorry for the post slow down.
I am as busy as chuff.
Hope to pick things back up in a few days.
cheers
Simon

Pareto gave me whiplash

Hopefully you all know the pareto principle, the 80:20 rule. The idea is that the first 20% of effort gives 80% of the benefit, and a million other combinations all suggesting that there are worthwhile benefits even in just doing part of a job. Its the rallying call of half job harrys and bodgers everywhere, and all under the guise of increased return on investment.

Don’t get me wrong, I think there are many areas where the 80:20 principle is completely valid. But I’m here to tell you skateboarding is not one of them!

This is a reconstruction obviously, I was actually skating the bowl at the local park. A proper skateboarder came up and did a back side kick turn, where you go up the ramp, and as you slow down, lift the front wheels, rotate around the back wheels in the direction your heels are pointing 180 degrees and come back down.

I did at least 80% the same as him, same approach speed, same angle, similar stance, same smile, but I got my weight slightly wrong and went flying – my board nearly decapitated him, and I landed on my arse, hard.

I got sent a spreadsheet recently to review, it was the same thing, on the surface it seemed reasonable, the formulas were a little long but not to bad, the VBA was long but seemed understandable, there were lots of sheets, but the names seemed to make sense, etc etc.

When I came to properly investigate it though, it was incomprehensible, the developer had used 80% reasonable practice, but had really fallen on his arse. I won’t go into the gory detail but the model was a monster.

I’m all for 80/20, maximising return on investment, cutting out features where the cost outweighs the benefit, but I think its important to recognise that you can’t do that everywhere. In most of the work that I do a system that is 80% right is 100% wrong and 100% useless, or worse.

What areas are there that you can think of, where pareto does not apply?

cheers

Simon

And yes, thanks for asking, I can move my head again finally.