Services
.jpg)
ENTERPRISE RISK MANAGEMENT
The ITABHI Corporation has been at the forefront of Enterprise Risk Management thinking and practice for over 25-years. ITABHI’s unique approach to ERM can help you identify, understand, communicate and mobilize against risks and pursue quality opportunities across your enterprise.
Problems, Risks and Opportunities Coming from Every Direction – What Do I Do?
The risks and opportunities faced by businesses today are both polycentric and polymorphic in nature. Every business decision now affects multiple financial, operational, technical, and organizational choices as well as a myriad of other issues, together forming a tightly woven tapestry. Averting a risk in one decision may increase the risk in another or exacerbate existing problems. Failing to exploit rapidly a successful opportunity can mean conceding a long-term strategic advantage.
Andy Grove, the legendary former chairman of Intel, says, “People formulate strategy with their fingertips. Day in and day out they respond to things by virtue of the products they produce, the price concessions they make, the distribution channels they choose.”
Therefore, effective enterprise risk management (ERM) is about individuals making smart choices. Enterprise risk management is about helping individuals and teams make intelligent, realistic choices across the enterprise in a coordinated and cooperative manner. ERM is a means to ensuring problems, risks and opportunities can be managed consistently across the enterprise.
What is ERM?
ERM is a systemic approach aimed at integrating the management of problems, risks and opportunities across the entire enterprise. Traditionally, risk/reward management has been the responsibility of several different organizational units (e.g., the finance, treasury, insurance, planning and/or marketing departments), whereas the operational risks and opportunities related to project or product efforts have been the responsibility of line management. Risks have been treated as individual trees in a very large forest. Most risk management within the enterprise has been concerned with the risk posed by tangible physical or financial objects, like buildings, rather than things like intellectual property, reputation, brand, business model or human capital. This “individual tree” approach to the management of risk and rewards has several problems associated with it.
For instance, it is nearly impossible to understand the cumulative risk exposure of the business. Therefore, the additional risk or benefit that any individual business decision has on the organization is difficult to determine. Additionally, traditional risk management is “balance sheet” oriented, meaning that only losses to hard assets are actively protected against, usually through the purchase of insurance. Losses to “soft” assets, such as a company’s reputation/brand, intellectual property, or human capital, do not directly appear on the balance sheet, leading them to be overlooked as sources of risk that need to be managed vigorously and financed. Risks or opportunities that cut across many different business units are also hard to mitigate (or exploit), not only because of the organizational coordination issues involved, but also due to the diverse set of knowledge that must be brought to bear.
For instance, it is nearly impossible to understand the cumulative risk exposure of the business. Therefore, the additional risk or benefit that any individual business decision has on the organization is difficult to determine. Additionally, traditional risk management is “balance sheet” oriented, meaning that only losses to hard assets are actively protected against, usually through the purchase of insurance. Losses to “soft” assets, such as a company’s reputation/brand, intellectual property, or human capital, do not directly appear on the balance sheet, leading them to be overlooked as sources of risk that need to be managed vigorously and financed. Risks or opportunities that cut across many different business units are also hard to mitigate (or exploit), not only because of the organizational coordination issues involved, but also due to the diverse set of knowledge that must be brought to bear.
Ecological ERM
To be successful, ERM needs to be ecological in nature, where the full range of problems, risks and opportunities - technical, business and social - are considered as one. That is, the information regarding all the different types of problems, risks and opportunities need to be gathered from many diverse internal organizational units, appropriately filtered, and then pulled together to form a complete picture of the organization’s risk/reward profile. This profile shows how much risk the organization is carrying, whether it is too little or too much, and how well the opportunities now being pursued, and whether current operations offset them. Putting together such a problem, risk and opportunity profile requires cross-departmental support and an organizational culture that supports fact-based decision making.
Ecological ERM addresses problems, risks and opportunities in a coordinated and cooperative fashion to create an adaptable and resilient enterprise. Although the investment in new opportunities creates much of the need for risk management, the greater risk is often from not recognizing which business opportunity creates the most value for money. It is common to discover that a promising opportunity, one that might have turned a company’s fortunes around, was starved of resources resulting from a general cut in operating expenses. In other cases, a promising opportunity is overlooked because the risks were overestimated, or the potential benefits underestimated. Ecological ERM can help avoid these situations from occuring.
Program and Project Management
The ITABHI Corporation has been involved in management of program risk – especially for large scale, complex technology programs – since its inception in 1986. Programs usually involve either a focused effort to create organizational change or are a collection of individual projects aimed at accomplishing an organizational mission. ITABHI can help you assess and manage risk across either type of program to ensure that they achieve their objectives.
Most Difficult Task of All
Program managers have probably the most difficult task of anyone in today’s leaner and resource limited organizations. First, program managers must translate the political into a reality. What we mean is that they are responsible for transforming organizational strategies and expectations into not only technical but also politically feasible, suitable solutions.
Second, program managers must make resource allocation trade-offs – both in terms of risk as well as opportunity costs – among a collection of projects. He or she must determine the best allocation among competing projects.
Next, program managers are responsible for finding answers to any conflicts, clashes of assumption or lack of resources associated with the execution of strategic plans that they had little input into but are constrained by. Program managers often have responsibility and accountability functions, but not full authority over what must be accomplished. Similarly, program managers must ensure that they can adapt their programs to external events which they also do not control.
Additionally, program manages must ensure that none of their projects get out of control and affect current operations or future strategic positioning. They must balance the risks of the program against the benefits that each project brings individually and collectively.
Further program managers must be both advocates for and skeptics of the projects within their programs. They must tirelessly support their projects to senior management but, also be wary of over-optimistic assessments of any individual project’s progress.
Finally, program managers must ensure that the projects under their control work well with other projects of other program managers. With organizations moving toward system-of-systems solutions, it is imperative that whatever is implemented is flexible and adaptable to future, yet unspecified requirements. In addition, this flexibility must be created with little if no additional program resources.
Managing Program & Project Problems, Risks and Opportunities
Program risk management fits into an ecological to enterprise risk management (ERM) approach aimed at integrating the management of risk and opportunity across the entire enterprise. It is a subset of ERM, but one that must execute properly. If program risk management fails, the organization will also likely experience some level of failure.
Program risk management brings management, systems engineering, financial engineering, software engineering and a whole host of other disciplines to bear to attack risks that are polycentric and polymorphic in nature. Since risk symptoms often mask the true causes of risk, the assessment and proper treatment of risk can be extremely difficult unless approached in a highly disciplined fashion.
Succesful program risk management must be both broad and deep in its application simultaneously. It must be aggressively pursued, lest small risks turn into large problems. In addition, program risk management must create factual information for program managers to make quality risk decisions.
Software Intensive Systems Risk Management
The ITABHI Corporation is a pioneer in software intensive systems (SIS) risk management. ITABHI’s founder Robert Charette, often called the grandfather of SIS risk management, has continually broken new ground in the application of risk management to SIS projects. He continues to forge the connection of enterprise risk management with SIS risk management. His two classic books, Software Engineering Risk Analysis and Management and Applications Strategies for Risk Analysis in 1989 and 1990 respectively were the first complete treatments of SIS risk management. ITABHI has helped dozens of organizations improve their SIS management of risk. We can help you lay the foundations of sound SIS risk management in your organization through training, education or advising.
Are You Vulture Meat?
Imagine that you somehow have gotten yourself stranded in the desert. You can successfully find your way out if you can successfully manage your water supply. How carefully do you think you would treat your canteen?
For government organizations and commercial enterprises, SIS are their equivalent to water in a desert. Few organizations can meet their organizational objectives without the extensive use of SIS. Given this dependence on SIS you would expect them to treat their SIS investments very carefully. Surprisingly, this is not the case. Despite at least 5-15% of SIS projects are canceled before their completion, 35-55% of SIS projects overrun by 135% or more of their original estimates and only 10-25% of SIS projects completed on time and within budget, the formal practice of risk management on SIS projects is often not performed in either government or commercial organizations. Most SIS projects are merely vulture food. In fact, the lack of rigorous risk management on SIS projects should be considered grounds for charging project management malpractice.
Need Help?
Our experience in helping organizations shows that successful SIS risk management needs to be broad and deep, as well as address all the issues shown in the diagram below. It must also be able to address difficult questions confronting SIS projects today throughout their life cycle, such as:
- “What is a project’s true value to the enterprise— yesterday, today and tomorrow?”
- “What opportunity cost does the project represent to the enterprise— is there a better project in our portfolio we should pursue?”
- “What emerging risks and opportunities does the project avert or help exploit, or poses itself to the enterprise?”
- “Is the project being set up to fail by the enterprise?”
- “Can the project be saved if it is failing or should it be stopped?”
Software Intensive Systems Lean Development
Dr. Robert Charette developed the principles of lean development (LD) in the early 1990’s as an outgrowth of ITABHI Corporation’s project software intensive systems risk management, program management and enterprise risk leadership efforts. While none of lean development's basic principles are new in and of themselves, their coherent integration under the banner and goals of LD make them particularly powerful. In fact, it is the emergent "virtuous cycle" property resulting from the interaction of its total set of principles where lean development's power lies.
LD is not for most organizations since the process requires foresight, deep understanding, and significant commitment on the part of an organization's senior management. Lean development challenges business executives, marketing managers, program managers, software managers and developers, especially those wedded to capability maturity models, to rethink their assumptions regarding delivering business value to their customers through information technology.
Why Do You Develop Software the Way You Do?
Have you ever questioned the assumptions that underlie your software development practice today? If not, why not? Have you asked yourself whether there is a better way to create and use software-intensive systems? If so, have you looked at lean development?
Lean development (LD) is a strategic as well as tactical business approach for the creation of change-tolerant business software intensive systems—i.e., systems that can rapidly adapt to or help in the creation of business change—in at least:
- 1/3 the human effort
- 1/3 the development hours
- 1/3 the time
- 1/3 the defect rate
- 1/3 the investment in tools and methods
- 1/3 the effort to adapt to a new market environment
Principles of Lean Development
Lean development is a principle-driven approach, and is part of the agile approach to software system development. However, LD is a strategic, business-down approach whereas most agile approaches are tactical, program team-oriented in nature. The twelve core principles of LD were developed in the mid-1990s, and first published in an interview with Jim Highsmith for a Cutter Consortium newsletter in October 1998 (over two years before the Agile Manifesto). They are
1. Satisfying the customer is the highest priority of the organization.The lean development team must focus on determining the customer's business value proposition. The goal is maximizing customer satisfaction through creating real business value at an acceptable level of technical quality. Not meeting customer value expectations is viewed as failure.
2. Always provide the best value for money.Software intensive systems should help eliminate a customer’s risk, solve a problem or provide them a new opportunity at a reasonable cost. Value is the goal, not perfection. Value is a combination of product features which meets a customer’s needs at a specific time in a specific situation for a specific price.
3. Success depends on active customer participation.Active participation is a collaborative, joint effort, not token integrated product teams. Customer participation is more than just “buy-in;” active participation is essential to adapting to change and making real-time business and technology trade-off decisions.
4. Every lean development is a team effort.Multi-disciplinary teams rather than isolated individuals are needed because diversity is critical to innovative, fast-cycle time development.
5. Everything is changeable.For software intensive systems to be useful, they must meet rapidly changing business conditions. Lean development assumes that requirements changes will be continuous and that learning to adapt to changes is a better strategy than trying to control them. The constant questions asked in a LD effort are, “What kinds of changes could occur? What would we do if they occurred? How can we build the system to be more tolerant of this type of change?
6. Domain, not point solutions.One-of-a-kind software systems are too expensive in most cases. Software intensive systems that are applicable across multiple domains—companies, markets, products—spreads the cost and therein contributes to the value equation.
7. Complete, don’t construct.Construction of software systems is time-consuming, costly and fraught with error. Buy rather than build has long been a viable strategy for most application development groups. Whenever possible, use pre-existing or prefabricated software elements to minimize organizational opportunity costs.
8. An 80% solution today instead of 100% solution tomorrow.Markets are moving too fast to provide 100% customer solutions.
9. Minimalism is essential.Lean development eliminates needless overhead and waste. LD seeks to eliminate waste by minimizing paperwork, keeping development teams small and co-located, and keeping the product scope focused.
10. Needs determine technology.Chose the objectives of lean development then the technology to support it, not visa versa. The technology options today are so vast that it is easy to spend more time changing technologies than creating business and customer value.
11. Product growth is feature growth, not size growth.The critical factor in LD is delivering change-tolerant features. When evaluating new features, the team should always consider how business practices might change and either effect or be effected by the software application. Size is not the issue.
12. Never push lean development beyond its limits.Lean development aims to increase revenue, reduce costs and increase profits by creating increased customer value. If there are better ways of doing so than lean development, use them.
There is an unwritten but important 13th lean development principle that supports the concept of humanware as well. In performing lessons-learned studies, the Japanese discovered that process and technology improvements on the factory floor contribute only 25% towards the overall improvements lean manufacturing creates. Humanware issues account for the rest. Like lean manufacturing, lean development depends on an ideology that engages those involved in it mentally and emotionally. Those using lean development need to achieve satisfaction through their work.
You can also read more about LD in Jim Highsmith’s book, Agile Software Development Ecosystems or in the Cutter Consortium Executive Report, "Challenging the Fundamental Notions of Software Development."
ITABHI Services Summary
ITABHI Corporation provides advisory, coaching and diagnostic services in various aspects of improving risk ecological decision management including:
In addition to our advisory services, we offer on-site training in our areas of expertise or through our training partner, Group Atlantic.
- Risk entrepreneurship, risk leadership and profit & innovation leadership
- Enterprise, program and project risk & benefit assessment
- Management husbandry
- IT and corporate governance
- Portfolio creation & management
- Large-scale program and project risk assessments
- Large-scale program and project management coaching
- Organizational risk-ethic culture change
- IT due diligence for mergers and acquisitions
- Technology investment assessment
- Software intensive systems engineering including systems-of-systems
- Software system lean development
In addition to our advisory services, we offer on-site training in our areas of expertise or through our training partner, Group Atlantic.