Wicked Problems and IT strategy

Wicked problems are now a well discussed and an on-going subject in various disciplines - predominantly public policy and design.

They do apply to IT strategy as well. I am consciously using the term “IT strategy” instead of something more tactical as software development or even more strategic as “Business strategy”. I will explain my choice later in the post.

Introduction to Wicked problems

There are several resources to explain wicked problems.  Please refer to the following resources as well: 

https://www.wickedproblems.com/

http://www.cognexus.org/id42.htm

http://www.ac4d.com/home/philosophy/understanding-wicked-problems

Wicked problems have the following characteristics:

1. The problem is not understood until after the formulation of a solution.
2. Wicked problems have no stopping rule.
3. Solutions to wicked problems are not right or wrong.
4. Every wicked problem is essentially novel and unique.
5. Every solution to a wicked problem is a 'one shot operation.'
6. Wicked problems have no given alternative solutions.

Relevance to IT strategy

IT strategy has long been considered either a collection of individual software project priorities or a off-shoot of the business strategy.  It has not been seen in the light of being a independent contributor to the business till recently. 

The reason is simple. With several established organizations, IT as a term and as a discipline was yet to achieve maturity. This precise expectation that IT should mature before being taken seriously led to several issues that did not help IT strategy being a contributing force.

Several problems that plagued software project failures would clearly fall under the umbrella of wicked problems. Projects that run over budget - because of change in requirements, change in stake holders, change in goals , Projects that get closed because of change in guard or change in the eco-system itself.

These are some generic examples - a lot of the software development efforts - projects or products - fall under these.

There have been several attempts at processes that could help us work through these challenges. However, a lot of them like spending time on detailed requirements, having a change review board etc, do not help address the situation. Instead, they end up bloating the cost of the IT organization and the projects.

This leads us back to where we started - IT organization is still not mature enough to be trusted to contribute.

Sounds like a wicked problem??

Choice of “IT strategy”

One of the key challenges in working with a wicked problem is being able to structure the problem at the right level and making sure both the depth and breadth are included.

Describing it as a problem only within software development projects would lead to formulating solutions like more overview of practices within a project - that would end up bloating the cost of the project. Even it you would take it to the level of IT organization, the processes would still lead to processes like change review board that would end up bloating the cost for the entire IT organization.

If we end up describing problems at a more higher level say at the business level, this would end up making the problem more generic and the solutions that might come up might not really be detailed enough. Some examples are introducing roles like software development managers that introduce hierarchy in an organization that might not really need one.

IT strategy is at a level that is enough to include the breadth of the organization but still remain relevant to the discipline that helps us go deep into the details.

Steps to handle Wicked Problems

• Callout implicit and explicit objectives to any software project / program
• This is one of the most important activities that needs to be carried out. Any divergence or hesitation to callout objectives of a specific project or program could be a good sign of turbulence and hence the existence of a wicked problem.

• Identify any unknowns and state intent of the experiment / action
• Once we are past the ability to solicit objectives, we have to state any unknowns - any expected volatility in project or program’s inputs - and suggest actions to mitigate them
• This step is in itself a paradox since we might not know all the unknowns to start with. We will have to be more flexible as and when we find unknowns during the course of the project or program
• Keep placeholders in plan to re-engage stake holders when we have findings that impact the project / Program
• The key thing here is to make sure that stake holders are engaged in the plan as we have learnings through our project or program
• Any learning from our actions could contribute to several decisions . Stake holders need to be engaged in the whole process
• Present clear cost benefit analysis based on past, present and forecast
• As we go through the whole journey, we need to be presenting the cost and the benefit to stake holders. 
• This might help us gauge the importance of the project / program and alleviate the confusion around why a decision was taken
• Have a clear and collective decision making unit
• This is perhaps the most important step. 
• Lack of decision making has led to a lot of cost overflows in projects and programs.
• Having a clear decision making units - that is not only responsible for the decision but also for the consequence - is very important. 
• More frequently it is the Project Management office or any such unit in the IT organization. 
• However, it needs to be communicated to the entire stake holder organization as well

Conclusion

This post is only to get started at making people aware of how to identify wicked problems. For a detailed note on how to handle some of those challenges, please refer to this post by Mary Poppendieck: http://www.leanessays.com/2002/01/wicked-problems.html

Of course, her article is pretty old. The use of adaptive processes have gained more main-stream prominence since. However, the fact that once you start using the adaptive processes, the nature of the problem changes and you have to take ownership of the impact. That is the real wicked problem.

Use of adaptive processes like Scrum, Extreme Programming, Lean PMO or SAFe would take us only so far. The support of IT leadership along with other business stakeholders in being able to support the experiments and the outcomes of each action taken to tackle a wicked problem is very important.