Mon, 5 May 2014 14:59:49
I was going to write this blog-post last night - but then this morning Bruce Durling pointed me in the direction of this article on massive vanity projects and reminded me of the awesome view of the world outlined by Albert O Hirschman. It’s from re-reading this article by Malcolm Gladwell that I get the idea of “Doubt-based action.”
OK, let’s be brutal and make some assumptions about this project that we’re working on.
ASSUMPTION 1
This project will take at least 2 to 3 times as long as expected and also cost at least 2 to 3 times as much.
ASSUMPTION 2
The people who are the customers of this project don’t know what they want.
ASSUMPTION 3
The calculations of return on investment for this project are suspect and wouldn’t bear scrutiny.
ASSUMPTION 4
The people tasked with capturing the requirements of the customers for this project aren’t capable of articulating what the customer wants.
ASSUMPTION 5
The people tasked with implementing the technical solution for the project aren’t capable of implement the technical solution (right now this especially seems to apply to environments).
ASSUMPTION 6
The project will fail for a bunch of reasons which are as yet unknown.
ASSUMPTION 7
The proposed end-users of this project won’t understand it, and won’t use it, or will understand it, and will hate it.
Think I’m being negative? Think I’m defeatist? OK then, prove me wrong! Let’s think about this, how would you go about proving me wrong? Well one way that you might go about trying to prove me wrong is by trying to develop a very small part of the overall system that you’re supposed to deliver. Get the customer to articulate that bit of the system, get the analysts to capture what the customers want, get the developers to implement what the analysts capture, get the DevOps people(if these people actually exist) to actually deploy this to a live platform where it can be looked at by real users? Try to do this with less than a fifth of the overall requirements, ideally less than a tenth. Then look back at these assumptions? To what degree are they true?
How long did it take to do that “tenth of the whole thing?” Really? Nearly half of the time and money you’d budgeted for the whole project? Why was that? Really because there was a lot problems and misunderstandings over the requirements? Because you had trouble procuring the environments and getting them up and running on time? And what was that? A major legislation change and a boardroom reshuffle? And did the users like it? No? Really?
In a way, the degree to which people are prepared to actually test these assumptions, by focusing their activities on minimum viable products that can be delivered and actually put in front of users is the degree to which the people you are working for are actually interested in producing something of value to their users, and themselves. Conversely, the degree they avoid testing these assumptions is the degree to which this is just a vanity project. *
* But as I’m writing this, I’m thinking - what is the actual harm of massive overrunning infrastructure projects anyway? Who do they hurt? Do they really hurt anything or anyone other than our sense of commitment and consistency? Built into the idea that massively overspending infrastructure projects are a bad thing is our old friend scarcity. But if we need something to create demand - aren’t massive infrastructure projects a better idea than illegal land wars? Even a super expensive fighter that goes massively over-budget, isn’t that a *good thing as long as by the time it gets into production it’s too overloaded with unnecessary missile systems to actually be a threat? Isn’t this coming around to Albert Hirschman. Maybe these massive IT projects that will never deliver are exactly the projects that you want to be working on? Is it alright to think like this? Or does that way madness lie?*