Top 10 Ways to Make a Bad Decision

I'm usually a positive thinker, but I've observed that many leaders have an easier time committing to real change when there is a clear disadvantage to the status quo.  In that spirit, here's a quick Top 10 covering sure-fire ways to make a poor decision in your organization.  Have you seen others?  Share your comments and stories about what you have experienced.

10.  Make a decision based on money and time you've already spent.

9.    Play up information that confirms your current point of view.

8.    Ignore information that doesn't.

7.    Pay too much attention to the first thing you hear, or the first data you receive.

6.    Frame a decision only on the benefits OR risks, but not both.

5.    Wear rose-colored glasses when you are estimating the results.

4.    Wear doom-colored glasses when you are estimating the results.

3.    Believe that your "gut" is the smartest person in the room.  Corollary: Justify every decision with a quote by Malcolm Gladwell.

2.   Use nothing but data.

1.   Don't use data at all.

"Lean Won't Work Here" -- Post by Mark Graban of Lean Blog

This morning I ran across this excellent post by Mark Graban on Lean Blog that walks through a short history of how organizations have crafted various reasons for why Lean won't work for them. He starts with the automotive industry and ends with health care - but in each case, the industry leaders adopt lean and the laggards fall behind. Each justification for resistance begins with "we're different . . . . ".

Big Sky uses lean principles for many of our clients, but we too have found that there is significant resistance to overt Lean or Six Sigma projects. Many clients are turned off by what I would call "true believers" -- practitioners who are unwilling to let go of by-the-book implementations of lean or six sigma methodology. The practicioners' or consultants unwillingness to be flexible or adapt their approach to the unique client situation dooms adoption of lean in the organization and everyone suffers are a result.

The bottom line, however, is that I have yet to find a process in any organization that couldn't be improved using at least some of the Lean or Six Sigma toolkit. Every client and every organization really is different -- but that doesn't mean that Lean/Six won't work. It does mean that Lean and Six Sigma must be applied differently. The real finesse comes with educating the organization in a way that isn't threatening or dogmatic, but brings them along at just the right pace.

Thanks to Mark and Lean Blog for a great post that I will surely be sharing with many of my clients.

Seven Steps for Defining Decision-Making Projects

I recently visited a client site to participate in the definition of a consulting project that had been broadly scoped, but that required decisions to be fleshed out in terms of specific project objectives, scope, and key performance metrics.

Most of the management group that would be affected by the project was in attendance, including representatives from logistics, operations, and marketing. They were knowledgeable individuals, well motivated, and responsible for many key decisions in their functional areas. Though eventually successful, it was a long meeting, and we had some trouble honing in to the key elements of scoping the project. To some extent, this should be expected, especially for a complex decision making problem.

Yet, as I reflected on the meeting, I realized that there were certain steps we could have followed that would have been helpful for the task at hand, improved decision quality, and lowered the complexity and time involved in concluding our discussions

1. Define decision making boundaries for the project at the very outset. What is excluded is as important if not more important than what is included inside the decision making framework.
   
2. Reduce the fuzziness in the project definition to the extent as possible through a precise definition of the roles of each constituent group involved.
3. Reduce the decision to a well defined process at the right level in the organization. I have written on this issue in an earlier blog entry.
4. Create project timelines with periodic milestones consisting of broad work structures, with specific attention paid to how the project scope agreed upon would mesh with those milestones.
   
5. Define key performance indicators that would be used to measure project success, and directly link them with final project scope and definition agreed upon by everyone.
6. Create consensus by explicitly seeking inputs for each of these steps from all the key stakeholders present at the meeting.
7. Revisit and re-iterate the steps in the order listed if stuck in discussions that seem to be stalling. Long discussions on performance indicators for instance may be driven more by not having followed the earlier steps (such as defining project boundaries or process level of analysis) rather than by a lack of understanding on what is important for measurement purposes.

While individual situations vary, following these steps will in all likelihood accelerate the project scoping process, reduce fuzziness associated with multiple constituencies focusing their attention on different levels of analysis, and create defined goals and timelines. It will also result in a decision making charter for the project that will have a greater chance for success and goal attainment.

The Three C’s of Governance

Most companies struggle on some level with decision-making. Let’s face it; keeping a large company working in a coordinated manner is no simple task. In the case of IT, this problem tends to be exacerbated by the fact that there is a lack of common language between groups. The business speaks in terms of finance and marketing, while IT talks about projects in terms of features and technical feasibility. The result is a lack of alignment, which hurts both groups. The solution to this dilemma is governance. The goal of governance is to fix broken processes and bring focus back to the strategic priorities of the business. In this entry, I suggest that we can look at governance through three lenses: control, communication, and change.

Effective governance exerts control either through formal authority or influence, depending on the degree of (management) centralization and the authority granted by executive leadership. In either case, the governance board works to establish standards and policies for the organization to guide development efforts. In addition, establishing a project approval process is essential to managing priorities and keeping IT departments focused on key initiatives instead of working in reactive mode to respond to the request of the day. The goal here is to balance the needs of the business with technical requirements to develop solutions that deliver business value and are secure and efficient to maintain.

The benefits we hope to achieve through control begin with communication. Project selection, policies, and standards should all be established through conversations between the business and IT within the context of strategic objectives and desired outcomes. These decision points hinge on a common understanding of the value delivered, the risks mitigated, and the cost to implement. Alignment between the business and IT is essential to set the right policies and to ensure that organizational compliance is high. Furthermore, a formal project selection process allows the IT and the business to set priorities together, stop projects that aren’t delivering value, and redeploy resources where they are most needed.

The last dimension of governance is change; how do we remove political obstacles and also get users to adopt the solution? Governance offers the opportunity to establish a structured, organized change management process to get us from our current state to a desired future state. Politics represent one barrier that can be challenging to overcome. It is the role of business stakeholders on the governance council to help IT overcome political barriers by identifying and addressing issues early on. User resistance to change is another matter entirely. Resistance to change is rooted in a desire to avoid disruption to the user’s established routine and to stay with the systems they know well. The best way to counteract this resistance is to improve communication and involve end users early in the development cycle. The project lifecycle should take care to generate user buy-in by asking for feedback, evaluating and incorporating changes from the user population, and supporting the transition to the new system.

Another look at the three C’s of Governance:

Control
· Formalize project selection/prioritization
· Employ IT portfolio management
· Establish standards
· Define policies
· Balance formal authority against influence
· Deliver consistent solutions

Communication
· Communicate business value – How will we benefit from this project?
· Gather business requirements – Does the solution meet our needs?
· Create transparency and better understanding of IT activities and performance
· Improve understanding of objectives and expectations
· Improve visibility of project issues and priorities
· Change perception of IT as a ‘cost center’ to strategic partner

Change
· Involve users earlier in the development cycle
· Capture enhancement requests
· Improve solution adoption
· Establish communication plan
· Identify and plan for objections/resistance to change
· Overcome organizational politics
· Provide end-user training