Some background on my philosophy and approach
An analysis of problems shows that there are three types: Tame, Complex and Wicked.
The characteristics of a Tame problem are that the problem is well understood and the solution is well defined. The solution to a Tame problem does not significantly disturb the solution space.
It must be possible for the problem to be analyzed, understood and a set of criteria established in order to identify and define when it is solved. In addition, when implemented, the solution should not create additional problems that diminish the value of solving the original problem.
A sequential methodology can be applied in the development of a solution to a Tame problem in the knowledge that over time, progress can be made without the need for re-work. Decomposition of the solution development should be possible without the risk of introducing unknown, critical or unmanageable dependencies.
The characteristics of a Complex problem are that the problem is well understood but the solution is unclear and/or uncertain. The solution itself will probably have a significant impact on aspects of the solution space. The problem can be analyzed, understood and a set of criteria established in order to identify and define when it is solved.
While it is clear what the solution to a Complex problem must do and the criteria against which it is to be measured are specified, it is not known what the solution should be, how it can be implemented and/or what the consequences of implementing the solution will be.
In addition, there may be requirements of the solution to a Complex problem that are not derivable from analysis of the problem but which arise because of the solution itself. This is a common situation in information systems where solving the problem requires particular application functionality. However the application needs to run in a technology environment which supports non-functional requirements such as availability and performance. The environment required to support non-functional requirements both enables and constrains application functionality. It also has key relationships with other areas such as cost and on-going support and maintenance.
Other examples include when the solution needs to be integrated into an existing environment, when new technology is being utilized and/or when the project team has not encountered this type of problem or solution before.
It may also be that, although the problem criteria are clearly stated, some of the requirements may be mutually exclusive. One solution might be small and cheap, and quick to implement and another one large, complex, expensive and time consuming to implement, however a large, complex, cheap and quick to implement solution is unlikely to be achievable.
The characteristics of a Wicked problem are that the problem is unclear, the solution is unclear and the solution has an impact on the problem itself. The solution significantly disturbs the problem space.
The term "wicked" problem was originally coined by Horst Rittel in the context of a general theory of planning and was applied to problems that had a high degree of social complexity.
A Wicked problem is difficult to model and understand. Entities and concepts can be difficult to define and their relationships may be unclear or change radically as events occur or over time. Selecting the best way to approach the problem becomes a problem itself.
A significant challenge in trying to solve a Wicked problem is that it is difficult to confirm that a proposed solution will fully or adequately solve a Wicked problem. In addition, what compounds the situation is that when a particular solution is considered or implemented, the problem itself can change.
There are usually many consequences to implementing a solution. Managing these consequences can lead to new Wicked problems. Sometimes the solution appears to be simple, but the wickedness lies in the difficulty of implementation.
A Wicked problem cannot be partitioned for analysis; a problem cannot be disconnected from its potential solutions; the solution cannot be partitioned for implementation without major risks to implementation and nature of the problem.
In the context of information systems, it is useful to assume that, if there are a significant number or variety of users and/or stakeholders, especially outside the direct control of the business, then the behavior of those users may change in ways that impact the problem and hence the solution options. This, alone, is sufficient to make the problem Wicked.
Is your project going to fail?
Considering most large scale IT projects fail, there is a better than even chance that yours will not deliver, will cost many time more than its budget and be late.
If you are hoping your project will be an answer to your business needs, if you are in charge of a major project, or just involved, then this site is for you.
If you have an open mind and are willing to learn from the past failures of others, there is a possibility that you can make your project a success. On the other hand, you may just cancel your project because too many bad decisions have already been made.
If you are a business person who desperately need an Information System to keep your enterprise ahead of the game, the first questions you need to ask yourself are "Do you trust those working on your project?" "What makes you think they are any better than the rest of the IT industry that has such an abysmal track record?".
As a business person, you have the right to expect competence and value for money when developing your solutions. This site aims to help you assert your rights.
This evolving and changing site is about large scale IT projects and why they fail.
The answer, in simple terms, is because most large IT projects are about solutions, not about solving problems.
Russell Ackoff said in 1974:
Successful problem solving requires finding the right solution to the right problem. We fail more often because we solve the wrong problem than because we get the wrong solution to the right problem.
Many organisations, in both the private and public sectors, have not recognised this. Neither have the IT and consulting industries.
Why Problems First?
This site has been developed after a number of years of frustration at the way modern IT projects are conducted. Old methods and approaches are being applied to modern problems and projects and failing.
I decided that there must be a better way and I think I've developed one.
The tipping point came when I was working for a large government organisation that wanted to migrate its primary data centre to a new location while also consolidating a large number of data centres and implement virtual desktop technology. The approach of the project manager was to run a number of workshops, gather requirements and issue a Request For Tender. As the lead architect on the project I was appalled. I could see so many interlocking issues that I could not believe that a simple set of requirements would define any sort of solution that a systems integrator could implement.
The project manager was adamant that his approach of requirements workshops was the best way to go. I wanted to analyse the problem, work with the many stakeholders to identify a strategy, determine the best solution and then define the requirements for an RFT.
Unfortunately, on this sort of project, the project managers have all the power. When the RFT was issued I managed to move to other work.
The project is still bumbling on. It did not meet its deadline of vacating the existing data centre and will probably not do so for many years.
The virtual desktop project will fail to reduce costs, because the original business case did not cost realise the impact it would have on their particular approach to Disaster Recovery.
In thinking about this project I came to the conclusion that the standard approach to business projects is broken at the most fundamental level - not understanding the problem.
If you are intending running any sort of technology project, you really need to understand that the project will be implementing a solution. Questions you should ask are
- "Do we understand the real problem?"
- "Do we understand what type of problem it is?"
- "Do we know enough about the problems we will be creating when we implement the solution?"