The causes of big problems in IT, part 2

In this, the second part of the mini-series previously named ‘Living In The World Of Big’, we’ll continue to have a look at where I think some of the big problems originate from within IT. Today we’ll start with the very beginning of the Software Development Lifecycle (SDLC) and in later posts, we’ll follow ideas as they travel through that process, right up until the point of release.

In the last blog, I poked fun at those people who when confronted with a ‘big’ problem introduced by their customer dismissed breaking it down in to more palatable pieces because it was hard. Following a recent conversation with a colleague, I shall temper my previous message somewhat, and acknowledge that there are those problems that a customer introduces that come with such a degree of dependencies built in, that they are impossible to break down. In an example I was given, financial regulation had been introduced to an industry and compliance was essential. My argument at the time was that not all of it was essential – some of the fines might have been an acceptable trade off, but I had to concede that if their business depended on their compliance, that was not an acceptable trade off. Those types of problems aside – and they are far fewer than in number than others – let’s look at where ‘big’ problems are created within IT.

Let’s start by reviewing a couple of examples of funding processes that I have seen. In one company that I worked for previously, funding for IT projects was scarce. The budget for IT work was apportioned in one of two ways, Keep The Lights On (KTLO) work and so called “strategic projects”. Simply put, very small or very large with no perceivable middle ground. Consequently the people wishing to get projects approved that seemed to fall in the middle of this categorisation, seemed to believe that the only way to do so was to have a large project that would carry the strategic label.

That’s where the fun began. One person with an idea would essentially take it on a road show, attempting to prove its worth to others and to collect further ideas along the way so that a) it would definitely make the grade as a strategic project and b) so as to get their backing when the funding discussions took place. This might seem strange, but that wasn’t the half of it. Somehow word spread of such projects and more people came out of the woodwork to offer their support for the project in exchange for the ability to add some of their own requirements. All along the idea was morphing and snowballing in to something much bigger until eventually, what had started as an idea to connect two systems had ended up as an enterprise wide SOA implementation whose vision was to create a technological mono-culture (and have big software vendors the world over salivating at the very prospect).

What’s really sad in all of this was that the original intent to solve a very real problem for somebody was lost – sure it might have got fixed somewhere down the line, but by the time the idea was presented for funding the benefit case was drastically different to what it started. However, the project had made the grade as a strategic project and the benefit case for those was always sold as not being as important – the project was of strategic importance you see.

In another company, funding was apportioned differently: an IT person acting as the liaison between a business division and IT (there’s a whole other mini-series…) was required to write up the ideas they’d heard from the respective heads of business into a one-page description so that IT had a better idea of the pipeline of work. Part of the one-page description was an approximation of how much it would cost to develop. There were four options available: 1 – 10,000; 10,000 – 100,000; 100,000 – 500,000 and 500,000+. Each of these four options had a different funding approval process associated with it, with those projects costing in excess of 500,000 seeing the most draconian measures and meaning a lot more work for the IT / business division liaison. Can you guess what proportions of projects were classified in that bracket? If you’re thinking it was low, think lower and you’re probably about right. But in this case, that wasn’t the real problem; instead it was the projects in the two middle categories. For example, knowing that the funding process would be the same for projects that were 20,000 as those that were 99,999 meant that lots of things were lumped together to avoid having to be exposed to the funding process multiple times. You might think though that the funding process also meant that projects that were around 100,000 would be broken down to get in to the lower category and you’d be right; those though that found it difficult or simply couldn’t be bothered to do so saw the size of their projects grow too.

Here, we’ve seen just two examples of how a small problem expanded in to something much bigger when confronted with a funding process, and I’m sure there are many more examples of your own that you can come up with.

It would trivialise the problem to suggest that we could solve it in a single blog post. There are some things to think about though: how more focus could be given to the benefits of each idea within a project presented; how the funding process could be set up in such a manner to give a greater precedence to those ideas that are smaller (assuming similar benefits cases) and how to make benefits cases that are vague (perhaps those that are aligned to a strategic project) more transparent and questionable by everyone.

Related content