Accenture announced on April 12, 2015, that they won a ground breaking “As-a-Service” deal with Rio Tinto, a UK based $45B dollar diversified mining company. Under the deal, Accenture will migrate all of Rio Tinto’s core information technology systems to an “As-a-Service” delivery model in the public cloud, leveraging Accenture’s cloud platform. Although terms of the agreement were not released, this is likely a multi-billion dollar deal and definitely a program worth keeping an eye on. According to the Accenture news release, the new model being implemented incorporates consumption based pricing to ensure costs are fully flexible and in line with the business demand. Under the terms of the agreement, Accenture will manage the maintenance and upgrade of Rio Tinto’s application landscape along with the related infrastructure and transformation of the global service desk and site support functions. This deal likely exposes both parties to a significant amount of risk regarding the program estimate and the unknown, unknowns.
A poor estimate is often cited as the root cause for cloud ERP failures. The estimate itself is obviously not the cause for failure. Rather, it is the behaviors and actions that are driven by the poor estimate which ultimately deem the project a failure. Failure to develop an accurate estimate with the appropriate contingencies can lead to:
- Attempts to lower costs by assigning less capable talent than was assumed by the estimator resulting in flawed designs / execution.
- Reductions in scope to meet budget targets resulting in the inability to achieve the established business case.
- Flawed participation plans put in place leading to the inability to apply talent on time. Resulting in cascading of additional overspend.
- Questioning of management’s competencies by senior leadership. Resulting in a dysfunctional governance model as the delegation of decision making becomes inhibited.
In February 2002, Donald Rumsfeld, then U.S. Secretary of Defense, stated at a briefing: “There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we now know we don’t know. But there are also unknown unknowns. There are things that we do not know we don’t know”. Confused? Rumsfeld was lampooned for these remarks as most people interpreted them as nonsense. However, these statements, upon careful examination, make sense and can be directly correlated to poor estimates. More often than not, poor estimates are a direct result of unknown unknowns.
Half of the battle of discovering your unknown unknowns is developing an understanding of the questions you should be asking that will drive the behaviors needed to discover the unknowns. Here are eight questions we recommend Rio Tinto’s CIO ask of Accenture and his own project team prior to pushing forward with the lion’s share of the work.
1. Is there a fundamental understanding of the case for change and a clear definition of the capabilities that are required to operate the business at the transformative level desired?
The answers to this should take the form of a complete scope definition that outlines the business processes involved, the geographic / business unit scope, the legacy systems involved, and the interactions with other corporate programs.
2. Have we considered the cost of capture?
Have we accounted for the additional costs required to maintain a new capability and capture the savings associated with a change? Costs could include new business functions created to maintain master data, or business process designs, the changes associated with new hiring or severance, or quick hit projects targeted at capturing short term wins?
3. What are the consequences of our assumed deployment approach?
Have we considered the costs of temporary bridges that need to be accounted for? Have we accounted for interim support and who will provide it? How do these assumptions impact the estimate?
4. How have we developed our bill-of-material for construction and deployment?
Have we established this bill-of-material utilizing a complete cloud based program cost template? What were baselines that we used for comparison purposes? What were the standards used for estimating? How were those standards validated?
5. What is the expected business / 3rd party vendor engagement model with the transformation?
Do we fully understand the amount of participation that is expected to support data cleaning, training, deployment practice, support etc.? Do we have an appreciation for the types of decisions that will be required, as well as who and how those decisions will be made? Is there a clear RACI matrix that outlines all party’s responsibilities and deliverables?
6. What project productivity is planned for the estimate?
How have we accounted for productivity improvements over time? What is the level of talent required to achieve standards for productivity? What are the assumptions regarding asset leverage as the project moves through its life cycle? How have we accounted for deliverables that provide assurance that productivity assumptions will be met?
7. Have we taken into consideration special accounting considerations with large programs?
Have we appropriately handled contingency budgets? Do we understand the potential impact of exchange rate fluctuations? Can interest payments be capitalized; will it be charged to the program? Is there a clear definition of capital and expense on program activities? Will there be write-offs required of any existing company assets?
8. How have we accounted for biases in the estimating process?
Estimates are derived by formula and experience. Experience implies that judgment is a key factor. The quality of one’s judgment is the product of training, environment, past projects, and peer influence. Understanding the biases that might have factored into the estimate will help in the identification of any potential blind spots.
Utilizing such a rigorous and diligent approach to understand and answer these questions will likely result in an estimate that is quite higher than the original estimate. However, given the premise that low estimates often result in failed transformations, program leaders will have increased confidence in the probability of success with an estimate that has been properly vetted.
The task of converting unknown unknowns to known unknowns can be a humbling undertaking. Recognizing and acknowledging your own blind-spots can be tough to swallow, but wouldn’t you rather understand your blind-spots before you start your journey rather than when you reach the precipice of a failure?
We welcome your comments and discussion. At UpperEdge, we see our blog as a forum for communicating practical and actionable insights that are grounded in relevant experience. You may contribute directly to the discussion by commenting below. If you would prefer to discuss separately, please do not hesitate to contact our Governance and Risk Practice Leader, John Belden, at email@example.com.