Organizations put a lot of accountability structures in place to make sure that people do their jobs correctly, and that projects succeed. These accountability structures include reporting hierarchies, project plans, documented responsibilities, and performance metrics.
These structures can have an unintended consequence: by holding people accountable for specific tasks and outcomes, they may discourage folks from holding themselves, and one another, accountable for their collective success. The small issues all have owners, but the big issues can slip right through the cracks.
Who is accountable, in your world, for the effectiveness of the accountability structures overall? Who has the job of looking for weaknesses or failures in these structures? Each time an issue erupts into a crisis that requires drastic action, that’s a sign that a big problem slipped through the cracks, or flew under the radar, for far too long.
Lets think about accountability in terms of business processes. I take the position that:
a. everything that happens in an organization is part of a process
b. When a result is not satisfactory, that indicates a defect in a process.
c. when there is a defect in a process that no one is addressing, there is a lack of accountability for the process.
I’ve been involved in lots of process improvement projects, and I’ve seen many of them fall far short of their goals. In my experience, the most common cause of failure is that managers turn a blind eye to early warnings of a problem. This happens especially when the early warnings suggest a problem that is too big or too awful to contemplate.
Jerry Weinberg calls this “The Titanic Effect.” When your project is too big to fail, people refuse to see the warning signs, and they forge ahead at full steam - right into an iceberg. The belief that failure is not an option, or that “we’re too indestructible to sink,” is strongly correlated to catastrophic failures.
What can we do to address this kind of unwillingness to face unpleasant possibilities? There’s a concept widely used in product design processes called Failure Mode and Effects Analysis, or FMEA. It seeks to identify known ways that a product or process can fail, understand the severity of each type of failure, and decide how to prevent such failures.
What do you suppose you and your colleagues would learn if you conducted a Failure Mode and Effects Analysis of the way process improvement projects (or information technology projects) can fail? What kinds of failure would your colleagues agree are absolutely predictable, but continue to happen anyway?
I’ve heard people say countless times that a critical success factor for their project is strong executive sponsorship. But how can you test the strength and effectiveness of your executive sponsorship before a crisis occurs?
I’m suggesting that you all come together and share your experience by means of a Failure Mode and Effects Analysis. If strong sponsorship is critical to the success of your initiative, then why would you not take every reasonable step to make sure you’ve got it?
These structures can have an unintended consequence: by holding people accountable for specific tasks and outcomes, they may discourage folks from holding themselves, and one another, accountable for their collective success. The small issues all have owners, but the big issues can slip right through the cracks.
Who is accountable, in your world, for the effectiveness of the accountability structures overall? Who has the job of looking for weaknesses or failures in these structures? Each time an issue erupts into a crisis that requires drastic action, that’s a sign that a big problem slipped through the cracks, or flew under the radar, for far too long.
Lets think about accountability in terms of business processes. I take the position that:
a. everything that happens in an organization is part of a process
b. When a result is not satisfactory, that indicates a defect in a process.
c. when there is a defect in a process that no one is addressing, there is a lack of accountability for the process.
I’ve been involved in lots of process improvement projects, and I’ve seen many of them fall far short of their goals. In my experience, the most common cause of failure is that managers turn a blind eye to early warnings of a problem. This happens especially when the early warnings suggest a problem that is too big or too awful to contemplate.
Jerry Weinberg calls this “The Titanic Effect.” When your project is too big to fail, people refuse to see the warning signs, and they forge ahead at full steam - right into an iceberg. The belief that failure is not an option, or that “we’re too indestructible to sink,” is strongly correlated to catastrophic failures.
What can we do to address this kind of unwillingness to face unpleasant possibilities? There’s a concept widely used in product design processes called Failure Mode and Effects Analysis, or FMEA. It seeks to identify known ways that a product or process can fail, understand the severity of each type of failure, and decide how to prevent such failures.
What do you suppose you and your colleagues would learn if you conducted a Failure Mode and Effects Analysis of the way process improvement projects (or information technology projects) can fail? What kinds of failure would your colleagues agree are absolutely predictable, but continue to happen anyway?
I’ve heard people say countless times that a critical success factor for their project is strong executive sponsorship. But how can you test the strength and effectiveness of your executive sponsorship before a crisis occurs?
I’m suggesting that you all come together and share your experience by means of a Failure Mode and Effects Analysis. If strong sponsorship is critical to the success of your initiative, then why would you not take every reasonable step to make sure you’ve got it?
No comments:
Post a Comment