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

Advertisements

14 Responses to “Why I love and hate project management methodologies (long)”

  1. teylyn Says:

    Wow, what a rant! Feel better now?

    I work in a utilities company in NZ, with encrusted structures and not much willingness to change. Nevertheless, the call for the all-encompassing egg-laying-wool-milk-pig (sorry, I’m German, and it’s “Eierlegende Woll-Milch-Sau”, the beast that produces everything) is ever so present.

    Yes, we’ve managed many projects in the waterfall methodology. Yes, many of them were late, over budget and did not deliver the full spec.

    Recently, though, we’ve been working to adopt Agile, and not just for software development. At the same time, we’re moving from a PMBOK shop to a Prince2 shop.

    And what can I tell you? Forget about the SLAs and the documentation and the Change Requests. If you do Agile Software development (we’re using Scrum), it actually marries quite nicely with Prince2.

    The reason for this is the focus on the Product. Prince2 is all about Product. Describe, break down, create, quality check, deliver. Agile is all about bits and pieces of code that deliver value. Describe, break down, create, test, deliver.

    Bewwdiful.

    There is a certain amount of administrative and documentary overhead, though. But each Agile project requires a lot of planning, anyway. Epics, stories, product backlog items, sprint backlog items. Documenting the planning is about 95% of documenting the product. The key thing is that you don’t have to do it twice. Just jot it all down as you iterate through the sprints, plonk it into a Word document, fine tune the formatting and away you go.

    Prince2 can be suffocating. A mountain of paperwork and administrativa to do. But the thing with Prince2 is that you can decide on a project by project basis, how intensely you want to apply the process to the project. For 2-week quickies, there’s hardly more than 5 pages of written material. The PID is on the back of an envelope. The Project Mandate is delivered in two sentences in an elevator ride. Or on a cigarette pack, if that’s still PC. The 18 month, NZ$ 2 Million whopper will take a bit more, of course. But then, there’s also more at stake.

    Agile is about delivering production ready code in iterative cycles. Functionality that has been defined by the Product Owner, available every x weeks. Developed, tested, ready to show, ready to go.

    Prince2 is about delivering quality approved products. It can work in iterative cycles. Developed, tested, quality checked, signed off, ready to go.

    Beautiful overlap that you would be hard tasked to match using waterfall methodologies. Both Agile and Prince2 focus on the product and its quality.

    And the most important thing: At any point in the course of a project can the governance group decide to pull the plug. They always know what stage the project is at, and they can see the development and results that have been achieved so far. Because it can be demonstrated and it’s working. Agile-developed, production-ready code can be demo’ed and proven to deliver value. Prince2 methodology with defined stages and reviews of targets achieved and tolerances exceeded match up with the agile iteration cycles, so if a project proves to be no longer viable, because the benefits can not be achieved within the agreed budget or time frame, the project can be stopped before even more money is burnt.

    Unlike the typical waterfall project that sits at 80% complete and 80% still to do. (Yes, 80% in both cases. That’s the point)

    Deep in my heart I’m a geek and a developer. I’d just LOVE to sit in my cave and hack away all day. Unfortunately, there are the requirements of the outer world. Unfortunately, these requirements also tend to change during the course of a project. The scope changes as the users learn what else could be had. The resources drop away to other jobs. Costs explode. Recession hits. Whatever.

    As a Project Manager, Prince2 gives you an excellent set of tools to make informed decisions and escalate issues beyond your call to the next higher level.
    As an developer, Agile gives you the satisfaction of a finished piece of code that meets the defined requirements and can be ticked off the list of things to do.
    As a C-level manager, a combination of Agile and Prince2 gives you the reassurance that your company’s money is spent in the best possible way. You will get benefit while the project is still running and you will discover early if and where things go wrong, so you can take action if required.

    I agree that Waterfall and the common SDLC leave much to be wished for. But just wishing for Agile instead is not enough. The Agile/Prince2 combo can actually demonstrate to upper and middle management and to the IT team, how a project can be successfull without the rigid phases of the traditional approach.

    Change is hard. I know. But it can be tackled.

    cheers

    teylyn

    Change Manager
    Project Manager
    Prince2 Practicioner

  2. Will Riley Says:

    “Isn’t SAP the one that no-one has actually finished implementing yet?”

    ROFL….. took the words right out of my mouth!! :)

  3. Mel Says:

    Hi Simon – ref your comments:

    * quickest and cheapest……..agreed – hence proliferation and popularity

    * but their lifetime is often short…..and often long….I am looking at spreadsheets developed 5 years ago that are so embedded in the business I have no way of knowing the risk

    and they can be a maintenance burden…..traditionally yes but….

    …you should take a look at EASA…really…it adds another dimension to your list – which offers your options 4 and 5 a structured approach to change control, version control and auditability. The business owns the app – the business or pro support supports the app – the app lives inside the core IT architecture and not on the desktop.

    With EASA its OK to use Excel as a development platform – thats got to be good for you guys….?

  4. Mike Woodhouse Says:

    I did waterfall for years, before it had acquired the name, even. Hell, in my consultant years (the mid-80s) I taught “structured methodology” courses.

    The gap between what business units need and what heavy-process IT departments are able to deliver in a timely and suitably-costful way seems to be growing in many organisations. That’s a major contributor to my decision to decamp from the cost-centre IT world to being the tame geek in a business unit. Here I do all the quick/nimble/agile/iterative (fun) stuff that our horribly ponderous IT people can’t. Excel/VBA, C#, Ruby on Rails, mostly. Colleagues bring me problems and I get to choose how I solve them. Which is nice.

    Plus I get to use the business knowledge I’ve accumulated over the decades. Plus I get to work with a bunch of insanely smart people from whom I learn a lot. Plus I get insanely well paid (just now, I actually couldn’t afford to go back to contracting, which is not something I ever thought I’d say).

    • Mel Says:

      You too Mike – take a look at EASA – given your role you could make yourself even more valuable to your client(s) and secure a blissful future for EUC built using your vast accumulation of business knowledge. Make contact and I can show you EASA. Mel.

    • Biggus Dickus Says:

      “tame geek” Love that !!!

      Great blog and thread Simon – My thoughs later when time permits.

      Biggus

  5. PM Hut Says:

    Simon,

    I’m not sure if I understand your post correctly, but it seems to me that you are favoring one methodology (Agile) over another (Waterfall). While on the other hand, your are labeling what I believe Agile as “snake oil methodology” (it can’t be waterfall because waterfall as a concept, not as a word, existed for thousands of years).

    PS: Here‘s an article that you might be interested in.

  6. Harlan Grove Says:

    [Re]Read ‘The Mythical Man Month’ and reflect on the fact that project management, like most everything else software-related, hasn’t really advanced in 4+ decades, we’ve just given it a flashier visual interface.

    The problem large organizations have with major software systems development is that the design phase is best handled by a FEW, VERY EXPERIENCED people who prefer to explain their decisions rather than the process they took to arrive at those decisions. Bureaucracies prefer many people documenting process and letting final decisions speak for themselves. And HR departments prefer less experienced employees who work for a lot less who can follow procedural checklists whether or not they actually have a clue what they’re doing.

  7. Bob Phillips Says:

    @Simon, wow, what a rant. Something really rattled you this week.

    @Harlan, just re-read that book myself. I was amazed at how it still holds up just as it did when I first read it (many years ago).

    Generally, my impression is that most management think that project management can be process driven, add the process and a monkey can do it (that is, lower paid admin people). The reality is that all well managed projects have people in there who have exeperience, can understand the challenges, and are capable at making intelligent, fact based decsioins – in other words they are experienced.

  8. Ross Says:

    …The real WFT is why am I working on a green field COBOL development effort in 2010!!!!

    Good post and comments…

    FWIW, regardless of method, if the project is ill conceived and unrealistic to start with, it really makes little difference, you in for a lot of stress anyway!!!

  9. Simon Says:

    you win again Ross!

  10. AlexJ Says:

    @ teyleyn – re: “Unlike the typical waterfall project that sits at 80% complete and 80% still to do. (Yes, 80% in both cases. That’s the point)”

    I’ve often used “AlexJ’s rule of software implementation”: The first 80% of the work takes the first 80% of the time…. and the last 20% of the work takes the other 80% of the time.

    I’ve used this as an anecdote to get management attention BEFORE the project starts. I’ve never really seen it in the way you report though. Think I’ll keep it in play.

  11. Scott Says:

    Excellent post. If one takes it as given that your organization will choose the ponderous ERP system route, really the last option is the best. The users who cook up their own spreadsheets are unlikely to be asking the IT department for any assistance with Excel. The best that one can hope for is that IT will let you have access to CSV files with the data you need.

  12. Why spreadsheet software is essential « Wheatland Computing Says:

    […] Why spreadsheet software is essential Posted in Uncategorized by Scott on June 30, 2010 Why I love and hate project management methodologies (long) […]

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: