Wicked, Wicked IT Strategy Problems

Some IT problems can't be solved - these are wicked problems.
Some IT problems can’t be solved – these are wicked problems.

Some problems just can’t be solved. As an IT guy with an engineering background, I find this hard to believe – it goes against my grain. I mean, back in school I encountered lots of problems that at first blush appeared to be impossible to solve. However, once I had gotten a little deeper into whatever class I was taking at the time things started to become more clear. New tools that I had learned could be used to solve what had previously appeared to be unsolvable problems. In the world of IT, the IT department can even help keep a company out of an economic stall and so I though that there was no problem that an IT department couldn’t solve. It turns out that real life is not nearly so neat.

Dr. John Camillus has spent the past 15 years studying how companies create their own strategies. During this time he has uncovered what he likes to call “wicked” business problems – strategy issues that are difficult because our traditional processes for solving problems just can’t resolve them. IT departments face these types of problems internally as well as facing them as part of a company’s overall strategy planning process. Wicked problems can be especially trying for IT departments because they seem to resist being solved by our standard techniques of gathering more metrics, revisiting the core issues and creating a more detailed definition of them, or even the time honored technique of breaking the big problems that we can’t solve down into smaller problems that we hope that we can solve. Dr. Camillus says that not only do our traditional ways of dealing with problems not work on wicked problems, but they can also make things far worse.

Dr. Camillus recently wrote an article for the Harvard Business Review in which he discussed wicked business problems. In it he stated that organizations, like an IT department, will most likely encounter a wicked problem when they are facing either a period of constant change or have encountered challenges that are bigger then they have ever seen before. Within an IT department, it won’t just be the technological complexity that make a problem a wicked problem, but rather all of the social issues that come along with it that will turn it into a wicked problem.

How can you tell if your problem is a wicked problem? It would be nice if wicked problems came labeled as such. However, they don’t. Having the ability to identify a wicked IT problem early on can save any IT leader a significant amount of time and grief. You won’t be able to tell just by looking at the problem itself, but rather you have to take a look at what surrounds the problem. Specifically, if a problem is causing confusion, discord among your IT team, and there has been a distinct lack of progress in creating a solution for it so far, then there is a good chance that you are looking at a wicked problem.

Just to make sure that you really do have a wicked problem and not one of those more common really, really hard IT problems, there are some additional criteria that you need to check before you can call an IT problems a wicked problem:

  1. Too Many People Are Involved: A problem that has too many people who are impacted by it starts to look like a wicked problem very quickly. Each person who has a different vested interest and is working on a different set of priorities will contribute to making a difficult problem into an unsolvable wicked one.
  2. The Cause Of The Problem Is Not Clear: There is no single cause for the IT issue that you are dealing with. Generally there are multiple sources that have fed the problem including competition, issues with employees & staffing, company strengths that have become decrements, and a traditional domestic vs. international focus can also compound the problem.
  3. The Problem Is Shaped Like A Blob: This is an especially tricky characteristic to deal with – the problem seems to change shape everytime you try to deal with it. This makes it hard to “get a grip” on the problem and so you may not have any idea as to where to start.
  4. You’ve Never Seen Anything Like This Before: How can you solve a problem that doesn’t look like any other problem that you’ve ever seen before? When you face a problem that you’ve never seen before, the question of what tools or techniques to use to solve it becomes even more critical.
  5. There Are No Signs Showing You The Right Direction: Most problems come with some sort of indication of what the correct next thing to do in order to solve it is. However, wicked problems have no such indicators. You are truly on you own here.

So what’s an IT leader to do once he/she has spotted a wicked problem? One key thing that Dr Camillus has learned is that wicked IT problems can not be solved. Instead, you need to find ways to mange them. How to do that is what we’ll talk about next time…

Have you encountered any wicked IT problems? Did you know it was going to be a wicked problem right off the bat or did it take awhile to discover this? What did you do about it? Were you ever able to solve it or does this problem still exist? Leave a comment and let me know what you think.

11 thoughts on “Wicked, Wicked IT Strategy Problems”

  1. An interesting topic to say the least! I have seen similar manifestations of really hard IT problems that escalate into ‘wicked’ ones once confusion grips the various stakeholders. In all honesty, I have never viewed the typical non-IT response of ‘throwing more resources at it’ a very sound approach. In several cases I have experienced, this only feeds the complexity, increases tensions and costs, and drives you farther from mitigating the spread or growth of the problem.

    I honestly believe that the addition of resources from the various stakeholders greatly contribute to the aspect Dr. Camillus spoke of, ‘The Problem Is Shaped Like A Blob’. The more hands in the clay mound pushing, pulling, patting, and shaping the more likely someone trying to ‘find’ a root cause(s) becomes impossible. Problems of this magnitude MUST be a carefully managed effort, otherwise, any beneficial effort will quickly be lost due to a rapidly changing problem domain.

    Addressing symptom problems will temporarily provide some manner of resolution, but unless the root problem is addressed, symptoms will only appear in other areas of the system. It is not difficult to understand that when it comes to systems that have been architected with dependencies that once failure in one component begins, others are sure to follow. That is the nature of relational integrity constraints.

    I did not read the article posted by Dr. Camillus, but I wonder if the problems in which he studied were ones where the managerial infrastructure completely understood the underlying system, its dependencies, and had very open and effective communication channels? In my experiences, most of the hard IT problems that became wicked ones were usually the result of efforts from decentralized business units attempting to resolve ‘their’ symptom not fully realizing what the impacts would be in other areas. Insufficient communication is only a precursor as it generally does not include the proper amount of detail needed for analysts/problem-solvers to determine whether or not the efforts of the segregated stakeholders will impact other areas of the system until it is too late.

    Whether or not a problem like this has a solution is up for debate. There has to be some initial cause which in turn triggers a responding effect. In one problem I remember, the firm hired a developer to modify a piece of software to add an additional parameter to a function permitting it to perform ‘additional’ operations. The code modification was a success and the dependent business units altered processes and tasks to leverage the new feature.

    Unfortunately, the modification was done to a COTS system. Aside from the fact that it was probably illegal, invalidated service contracts and warranties, and possibly infringed upon patents or copywrites it was done. What wasn’t taken into account was the fact that the COTS had a built-in auto-update mechanism. When the software producer published a new version, the software updated itself.

    Naturally, the earlier modification was not included in the new version and entire business units experienced work stopages the next day. They were literally loosing thousands of dollars an hour and rapidly approaching service contract defaults. Needless to say, panic was the dominant sentiment and multiple business units scrambled to find resolutions.

    Each unit, fueled by their own self-interest attacked the problem from different angles all thinking the problem was in ‘their’ specific area of concern. Not one thought to check the update logs prior to an all-out assault on the system. Several knee-jerk changes were made, modules were disabled, reconfigured, and network traffic was re-routed.

    All of these things were done prior to the establishment of ‘any’ form of damage control, or emergency response team. Naturally, these activities further degraded the ability of the system to support business processes and the problem grew well beyond its original manifestation. The blob was born. Other problem-solvers from different business units were basically rendered useless because there were so many things happening within the system that it was hard to tell whether they had fixed anything or not.

    This was the state of the system when I arrived. My first response was to establish the response team consisting of member from each of the affected business units so that ‘all’ stakeholders were working in a concerted effort. My second measure, given the complete breakdown of the system was to restore the most recent full backup and run the latest transaction log file against the database to restore the records.

    This quickly brought the system back online and gave us full functional capabilities as the backup was prior to the version update. I asked which business unit first noticed the system was not functioning correctly and began to chase the problem back from there. I had the network administrator pull log files for that night to see who was accessing what and we found the entry for the version update.

    At the time, I wasn’t aware of the ‘modification’ but when I had the system administrator install the system on a temp server and uploaded the code to their versioning database, I was able to run a ‘difference’ function and locate the modification. When I discovered it, I notified the appropriate members of the team, CIO, and CEO. I showed them where the problem had happened and why but refused to modify the code in the 3rd party software. I like my ethics right where they are.

    My job was to isolate and resolve the ‘wicked’ problem and I did. Mission accomplished and I moved on. I can’t be entirely certain they restored the ‘modification’ in the newer version and I honestly feel it is none of my business. I do however feel that they learned a valuable lesson in properly introducing modifications, monitoring software auto-updates, and utilizing a true test platform.

    Just my thoughts…


  2. Jay, as always – good points. However, I think that you missed one key aspect of a “Wicked IT Problem” – it’s so complicated that NOBODY can get their hands around it and understand it (that’s why it’s “wicked”). What this means is that the careful, analytical approach that you recommended (which works with normal problems) probably won’t work here. What you actually need to do is to throw out the standard way of solving problems and try something new. In my next post I’ve got a couple of suggestions. Take a look add leave me a comment letting me know if you think that this NEW WAY would work. Oh, and congrats on solving COTS software modification problem – that sounds like a nightmare!


Leave a Comment