As explained in my introductory post on the Exception-Tolerant Organization, ETOs do not tolerate waste, stifling of innovation, or inflexibility. These are the corrosive agents that prevent an organization from smoothly handling exceptions, maintaining a competitive edge, and operating effectively.
When I was at IBM Research I knew of a research Fellow who would monitor the keystrokes made by his administrative assistants while they were typing, and would spend quite a bit of time with them working on utilizing the fewest keystrokes possible. This is intolerance of waste taken to the extreme, where a few burning trees are saved while sacrificing the forest. Although it is quite easy to disdain waste made at this low level, this is not the kind of intolerance we are discussing here.
While the canonical definition of waste is anything that does not add value, what exactly constitutes waste for the Exception-Tolerant Organization? As previous posts have mentioned, exceptions happen to organizations, to customers, and to people every single day. Those organizations that cannot handle the exceptions and improve from them will fight a constant perception of lower value in the eyes of their customers.
For those who understand the benefits of mapping a value stream, waste would be anything that slows the velocity of movement through the value stream. The inability to swiftly handle exceptions can bring this velocity down to near zero. Being Exception-Tolerant can keep the value stream moving at the pace of innovation.
Waste for the ETO, then, is the set of roadblocks to handling exceptions: inflexibility combined with the stifling of innovation.
Inflexibility is tough to exhibit while being Exception-Tolerant, but is even tougher to recognize in an Exception-Intolerant organization. After all, there are certainly industries and products where strict and rigid standards must be constantly and consistently adhered to (watch-making, food preparation, chip manufacturing, aerospace), but these should not be mistaken for inflexibility. Chip manufacturers, despite adhering to the use of 30+ year old computer code, have been able to find avenues of flexibility in many ways over the past few years - from lower-voltage conduits to hyper-threading to multi-core pipelines.
Stifling of innovation is perhaps the touchiest subject when it comes to organizations who may be looking to become Exception-Tolerant. The urge to suppress innovation is strong in risk-averse environments, and is often exercised in such forms as:
- the boss consistently saying "No"
- a departmental control group demanding that a potential innovative division look and operate the exact same way as the existing divisions
- new ideas whose implementations are unduly laden with process, direct-to-archive documentation, or extreme executive input
The stifling of innovation is often a by-product of culture, and the effects may not be felt in world markets until long after the key culture-makers have moved on. Strong cultures that stifle innovation are not often discovered by the outside until the effect in the marketplace becomes obvious. ETOs, even ones with strict standards, have a tough time saying "No". Inflexible organizations find it all too easy to say "No" and close doors on new ideas and customer needs by stifling innovation.
But with all the good work that we as people do, and all the work that we endeavor to do, how do we let ourselves get into a mode of inflexibility and resistance to innovation? The hard truth here is that we most often become inflexible and stifle innovation when we put self-interests above working together as a team. There is good reason that this struggle is often labeled as the war within.
But the other side of this hard truth is that ETOs are given credit by their customers for handling the exceptions and increasing the overall value proposition. And when credit is given in this fashion, ETOs give their people, who have worked together as a team, every opportunity to take the credit and reap the rewards - thus making team achievement in the best self-interest.
Wednesday, December 31, 2008
Friday, December 19, 2008
Valuating Technology System Delivery
A well-worn but still prevailing theory of system delivery states that a system can be delivered according to three main factors:
- the system is of high quality and functionality (a "good" system)
- the system runs speedily under all conditions and usage loads (a "fast" system)
- the system can be built and delivered inexpensively (a "cheap" system)
The conventional wisdom is that a system can be delivered possessing AT MOST two of the three above factors. In other words:
- a good and fast system cannot be delivered cheaply
- a good and cheap system will not run speedily
- a fast and cheap system will not be a good system
You may or may not hold this view yourself, but many still do. Of course, it is quite possible (and rather beneficial) to have all three factors represented positively in a system delivery. But you need to look at the entire lifecycle of a system to understand this, not just the planning and construction stages.
Many under-weigh, or ignore completely, the usage and maintenance portions of a system's lifecycle when evaluating TCO and ROI. If the system's features, functionality, and construction are underrepresented before the system is delivered, higher costs will be made apparent later in the lifecycle:
- the system's users will invent workarounds to their normal business processing, just to accommodate the system's lack of performance or mis-matched view of the world. This usually leads to weaker controls and gaps in business processing, which leads to anywhere from higher operating costs to lost revenue.
- the system performs poorly or contains only a few compelling features, but just barely enough to be useful. While there could be no justifiable loss in cost, the cost to keep-alive the system plus the cost to improve and re-architect the system could easily be more than double the initial funds promised. Building a more desirable and well-performing system might have cost more up front, but still could have been less than the funds needed later for repairs.
- the system performs so poorly, or contains such a lack of compelling features, that it will not be used at all. This represents a loss equal to the cost of construction of the system, plus the difference in current operating costs that may have been saved, plus the cost of lost opportunity to improve and be competitive.
So how do you deliver a system that is good, fast, and cheap? Stating the system's costs and its benefits over the ENTIRE system lifecycle, both with equal precision, will help you arrive at acceptable definitions for "good", "fast", and "cheap" for your organization. But without the equality in precision, someone is bound to be disappointed upon delivery of the system.
So which lifecycle phases and cost factors are you accounting for in your system delivery analysis? Do you feel that you have all the bases covered? And how is the precision measured?
- the system is of high quality and functionality (a "good" system)
- the system runs speedily under all conditions and usage loads (a "fast" system)
- the system can be built and delivered inexpensively (a "cheap" system)
The conventional wisdom is that a system can be delivered possessing AT MOST two of the three above factors. In other words:
- a good and fast system cannot be delivered cheaply
- a good and cheap system will not run speedily
- a fast and cheap system will not be a good system
You may or may not hold this view yourself, but many still do. Of course, it is quite possible (and rather beneficial) to have all three factors represented positively in a system delivery. But you need to look at the entire lifecycle of a system to understand this, not just the planning and construction stages.
Many under-weigh, or ignore completely, the usage and maintenance portions of a system's lifecycle when evaluating TCO and ROI. If the system's features, functionality, and construction are underrepresented before the system is delivered, higher costs will be made apparent later in the lifecycle:
- the system's users will invent workarounds to their normal business processing, just to accommodate the system's lack of performance or mis-matched view of the world. This usually leads to weaker controls and gaps in business processing, which leads to anywhere from higher operating costs to lost revenue.
- the system performs poorly or contains only a few compelling features, but just barely enough to be useful. While there could be no justifiable loss in cost, the cost to keep-alive the system plus the cost to improve and re-architect the system could easily be more than double the initial funds promised. Building a more desirable and well-performing system might have cost more up front, but still could have been less than the funds needed later for repairs.
- the system performs so poorly, or contains such a lack of compelling features, that it will not be used at all. This represents a loss equal to the cost of construction of the system, plus the difference in current operating costs that may have been saved, plus the cost of lost opportunity to improve and be competitive.
So how do you deliver a system that is good, fast, and cheap? Stating the system's costs and its benefits over the ENTIRE system lifecycle, both with equal precision, will help you arrive at acceptable definitions for "good", "fast", and "cheap" for your organization. But without the equality in precision, someone is bound to be disappointed upon delivery of the system.
So which lifecycle phases and cost factors are you accounting for in your system delivery analysis? Do you feel that you have all the bases covered? And how is the precision measured?
Act Like An Owner
Does your organization ask you to act, and think, like an owner? Does your organization ask this of you when you come aboard?
What would an Owner do in your organization? Would an Owner carry a vision? Innovate? Seek improvement and new opportunities?
Would an Owner cut corners? Cut costs? Maintain the status quo?
Would only an Owner understand the key drivers to the business? Or could anyone else in the organization achieve such an understanding?
Does your organization educate and allow you to understand the key drivers to its business?
Does your organization allow you to cut corners and costs? To maintain the status quo?
Does your organization allow you to carry a vision? Innovate? Seek improvement and new opportunities?
Your organization may ask you to act like an owner - but does it allow it?
What would an Owner do in your organization? Would an Owner carry a vision? Innovate? Seek improvement and new opportunities?
Would an Owner cut corners? Cut costs? Maintain the status quo?
Would only an Owner understand the key drivers to the business? Or could anyone else in the organization achieve such an understanding?
Does your organization educate and allow you to understand the key drivers to its business?
Does your organization allow you to cut corners and costs? To maintain the status quo?
Does your organization allow you to carry a vision? Innovate? Seek improvement and new opportunities?
Your organization may ask you to act like an owner - but does it allow it?
The Exception-Tolerant Organization - Part 4
As explained in my introductory post on the Exception-Tolerant Organization, ETOs practice daily Risk Management. Another concept that sounds quite simple, but organizations find it difficult to sustain due to these key factors:
- lack of inertia and momentum
- lack of systematized and/or automated assistance
- key-man risk and blame
Lack of inertia and momentum comes from not instilling review activities into the organization's daily operations. Just asking these fundamental questions on a daily basis goes a long way towards an effective review process:
- What did I accomplish yesterday?
- What am I working on today?
- What obstacles or problems am I facing?
- How confident am I that the current goals will be accomplished on-time?
For many organizations that rely on reviewing large amounts of performance or other time-sensitive data, having a systematized and automated collation and presentation of this data is key to establishing a daily momentum. The systems and processes supporting them should have the appropriate fail-safes and redundancies to handle exceptional processing cases so that timely delivery (and thus Risk Management momentum) can be maintained.
Automated assistance is also key for the human side as well. In reviewing an organization's performance or exception conditions, leaning on automation can clear our heads of the mundane and manual steps, and allows us to focus on the exception conditions. Plus, what Director of Risk Management wants to arrive at work at 7 am just to push a button, or wait for reports 1 through 10 to finish running and printing before tackling the issues of the day?
Being a Director of Risk Management is a tough proposition to satisfy for an organization. Not only must you have volumes of data and information at your disposal, you must have the prescience to understand what is going to happen seconds from now in both your own building and halfway around the world. A Risk Management Director could be hailed as the heroic steward of the ship that avoids the icebergs of a competitive landscape, or could easily be the goat when the ship is steered right when perhaps it should have turned left.
For an organization, it is easy to both funnel singular responsibility and cast blame on one person when things blow up. But why do this, when after the blame subsides, the organization is still in an unfavorable situation when a risk materializes? Risk Management is one of those cross-cutting activities that the entire organization can practice effectively on a daily basis via continuous review and improvement. Allow your Risk Management Directors to get the support of the entire organization, and the Director will support the viability and competitive health of the organization in return.
- lack of inertia and momentum
- lack of systematized and/or automated assistance
- key-man risk and blame
Lack of inertia and momentum comes from not instilling review activities into the organization's daily operations. Just asking these fundamental questions on a daily basis goes a long way towards an effective review process:
- What did I accomplish yesterday?
- What am I working on today?
- What obstacles or problems am I facing?
- How confident am I that the current goals will be accomplished on-time?
For many organizations that rely on reviewing large amounts of performance or other time-sensitive data, having a systematized and automated collation and presentation of this data is key to establishing a daily momentum. The systems and processes supporting them should have the appropriate fail-safes and redundancies to handle exceptional processing cases so that timely delivery (and thus Risk Management momentum) can be maintained.
Automated assistance is also key for the human side as well. In reviewing an organization's performance or exception conditions, leaning on automation can clear our heads of the mundane and manual steps, and allows us to focus on the exception conditions. Plus, what Director of Risk Management wants to arrive at work at 7 am just to push a button, or wait for reports 1 through 10 to finish running and printing before tackling the issues of the day?
Being a Director of Risk Management is a tough proposition to satisfy for an organization. Not only must you have volumes of data and information at your disposal, you must have the prescience to understand what is going to happen seconds from now in both your own building and halfway around the world. A Risk Management Director could be hailed as the heroic steward of the ship that avoids the icebergs of a competitive landscape, or could easily be the goat when the ship is steered right when perhaps it should have turned left.
For an organization, it is easy to both funnel singular responsibility and cast blame on one person when things blow up. But why do this, when after the blame subsides, the organization is still in an unfavorable situation when a risk materializes? Risk Management is one of those cross-cutting activities that the entire organization can practice effectively on a daily basis via continuous review and improvement. Allow your Risk Management Directors to get the support of the entire organization, and the Director will support the viability and competitive health of the organization in return.
Subscribe to:
Posts (Atom)
