You are likely to have heard about the project methodologies known as Waterfall and Agile. These are different approaches to project delivery. In this blog we consider the implications on risk management and risk approaches when using either one.
A project following a Waterfall process tries to eliminate all uncertainty about what is being built before tackling the uncertainty of how it will be built. On the Waterfall side [of the diagram below] the downward arrow shows a traditional team’s attempt to eliminate all end uncertainty at the start of the project. This means that before any development begins, there will be no remaining uncertainty about the end that is being pursued.
Contrast this view with the Agile approach to reducing uncertainty which is shown on the right side [of the diagram below]. Agile teams acknowledge that it is impossible at the start of a project to eliminate all uncertainty about what the end product is to be. Parts of the product need to be developed and shown to customers, feedback needs to be collected, opinions refined and plans adjusted. Whilst this is occurring, the team will also be learning more about how they will develop the system. This leads to simultaneously reducing both end and means uncertainty.
One of the greatest risks to most projects is the risk of building the wrong product. This risk can be dramatically reduced by developing early on those features that will best allow us to get working software in front of or in the hands of actual users
A Finance system implementation
A finance system implementation has a very rigid structure for delivery. The requirements for the preparation of the chart of accounts, the analysis structure, management reporting pack, financial reporting pack and so forth have been documented. Finance systems have been implemented for many years and there is a level of maturity known about the required deliverables.
The methodologies used are tried and tested. Finance personnel understand what the ultimate design needs to look like (End Uncertainty). The organisation who are employed to deliver the system will have their own proven approaches (Means Uncertainty).
A Business Intelligence implementation
Contrast this with a Business Intelligence implementation. In recent times these have started to become popular as organisations realise they have large quantities of data which, on analysis, could yield valuable business information. As a business, TouchstoneBI have a proven approach to delivering Business Intelligence projects (Means Uncertainty). The area requiring clarity is the End Uncertainty (what the end result needs to look like). To achieve this there has to be dialogue with the ultimate end users.
At the start of the project we recognise and accept that there is this level of uncertainty, for the end user is unlikely to know, or be able to explain, what they want to see. Instead of trying to resolve this through the writing of a design document, which the traditional Waterfall method recommends, we start to develop the product early on in the delivery lifecycle.
Options such as Tree Map, Filled Map, KPI, Multi-Row card, Scatter Chart, Line and Stacked Column Chart all have their place. Which one to use depends on the situation and the user’s interpretation of the data.
Taking a representative sample set of data, importing it into a data warehouse and using a modelling tool, like BIRST, Tableau, or PowerBI can give a graphical representation of the information.This is then reviewed with the end users. There is a discussion on what is learnt from the content and whether further refinement is needed.
For those who are risk averse, the initial thinking is that we need to reduce uncertainty by designing the requirement upfront. Yet the paradox is that this is more risky. It is through the demonstration of the art of the possible, the collation of feedback, and refining of opinions that the user will have a solution that ultimately meets their needs.