Big Sky Thinking

Top 10 Ways to Make a Bad Decision

noreply@blogger.com (John Dillard) — Thu, 11 Feb 2010 13:47:00 +0000

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.

Project Management Never Takes a Holiday

noreply@blogger.com (Jennah Mathieson) — Tue, 01 Dec 2009 03:59:00 +0000

As we get into the holidays, this is the perfect time to take stock of your current projects and make your resolutions for next year. Things get a little bit quieter, and that creates a fantastic atmosphere for catching up on all of those things that you should be doing all the time... but just don't quite get to. "Project management" covers a wide swath of activities- but they all come back to one constant theme: control. Without clear knowledge of the progress along each of the lanes of your project, you will quickly lose control. Even the most experienced project and program managers can lose control.

Unfortunately, it doesn't take long for a project to spin out of control without proper measures in place. First, you have to look at your project scope. Is it a many-tentacled monster with smaller sub-projects sprouting out of everywhere? Is it growing rapidly (and by rapidly, I mean by 25% or more over 6 months)? Is it complex? Does it have built-in reporting requirements? if the answer to any of these questions are yes, you need project control in the form of tracking mechanisms and documentation.

Your first response is likely that you know what is going on and you certainly don't need to bury yourself in paperwork that gets completed and then stashed in a drawer, never to be used. I like to call that stuff "shelfware." That's why you have to design your methods of control to fit into what you're doing- specifically to your project and to the way you work, the way your team shares information- both internally and with your stakeholders. There are lots of great ideas, and you can force yourself to get the templates built and the information flowing by scheduling a meeting with your major stakeholders on a regular basis, with a structured format. That structured format will get them used to what you need them to know. Look back over the last 90 days and see where your "fire drills" were. If they were cleared up with a bit of explanation and additional communication- learn from those experiences and put that information out on a regular basis, in a format that the people who need it can relate.

Now that you've done that, it's time to tackle the big beast. Here's how you do it:

Break your project into "lanes"
Assign each of those lanes personnel who have those day-to-day responsibilities
Put in writing (to share with your team and stakeholders) the SCOPE of each of those lanes
Break up all of your tasks into those major lanes
Write task charters to lay out what's in scope for that part of the project
Create a project milestones chart (I like to use a plain-old Gannt chart because it doubles as a calendar of when things are due and where your dependencies are)
Post your chart where people can see it and follow along

Make sure that if you were to be kidnapped by aliens tomorrow, that the people you work with would know exactly what was going on across your entire project- what people were doing, what those activities are in support of, and WHY.

If nothing else, it will make your life a little easier as the project manager, and the regular investment of time in "housekeeping" sorts of activities like this will afford you control over your project, real oversight, and maybe even some extra time to celebrate holidays... you know, while you're not working.

Statistics are Sexy

noreply@blogger.com (Jennah Mathieson) — Thu, 12 Nov 2009 22:18:00 +0000

In an era of almost unlimited data availability managers are inundated with information of all types from multiple sources. In this environment, the manager must be able to filter out the relevant from the noise, and must also identify the data that can be transformed into something useful. Once you're left with a narrowed down pile of data, you can turn that into information that your team, your stakeholders, and your leadership can use to facilitate informed decision making.

Wait! That's not the end! Information is only truly useful to those people if it is communicated effectively. "Effectively" means that:

It supports a well-defined purpose or decision-making objective; and
It's in the right format for the message and the audience, and
It provides clarity, rather than just more volume.

This is where the statistician on our team comes in. Statistics provides the means to analyze and extract real value from your pile of collected data. They can be descriptive- explaining the current reality in clear, concise terms; they can also be predictive- extrapolating trends to aid in decision making. Unlike other types of information, reliable statistical data when combined with a well-thought-out case for change is difficult to refute. A well-crafted, data-based argument is incredibly effective when trying to gain consensus among stakeholders on the way ahead.

Hal Varian, the Chief Economist for Google, was interviewed about the affect technology has on innovation. In that interview, he talks about how Statistician is the "sexy" job of this decade, as Computer Engineer was the sexy "it" job of the 90s during the tech boom. Keeping a skilled statistician within arm's reach can help you focus conversations and enhance your team's decision making activities by providing support for your business case for change. In a world where data and data sources are growing exponentially, a statistician can extract the value from that data and transform it into the representation needed to support your decision making processes. The statistician can inform and empower your stakeholders. Statistics aren't just critical to determining your path, but are also the key to explaining those choices to others.

The Emotional Side of Lean

noreply@blogger.com (Jennah Mathieson) — Wed, 07 Oct 2009 03:14:00 +0000

I read an interesting article in January's edition of the Journal for Quality and Participation about the need for emotional intelligence in a project. It’s by Rangarajan Parthasarathy, and you can read it here. It pulls together the principles of project management, evidence-based management, and the emotional quotient necessary to making a project successful.

In order to truly make the recommendations of a Lean project work, you have to have more than just knowledge of statistics and Lean tools and how to apply them to your project. You should reach across the groups with equities in the program and work the kind of relationship management magic that creates an atmosphere where everyone is looking forward together toward the same goal. You have to be able to create a sense of ownership among the stakeholders. Essentially, you must “sell” the solution.

It’s hard to find good project leaders who can consult as a part of the team without losing the evidence-based management required by Lean. A great way to overcome that is to assign specific roles; partner a person with the “soft” skills required to keep all of the people and personalities running in the same direction with a person that has the quantitative ability to keep the data collection and analysis clean and productive. I believe that the lack of attention to the emotional side of a project, particularly the acceptance and ownership of the resulting changes, is a preventable source of failure.

Role Based Access Control – Part III: Defining and Implementing Roles

noreply@blogger.com (Ron Bowron) — Thu, 01 Oct 2009 14:19:00 +0000

We have discussed the benefits of Role Based Access Control and outlined a method to rationalize user applications as a first, critical step in the roles definition process. Today’s discussion provides an overview of how to define the roles that grant users entitlements to applications and systems. This process includes the use of role mining tools, the definition of role structures, and the development of a role catalog.

Role Definition Step 1: Leverage Mining Tools and Methods

Once application rationalization has been completed, we can safely assume that our applications are aligned to our organizational roles. At this point, we can formally define our user roles by collecting and refining this information to derive a role model. These roles will be closely tied to your existing job positions, which will map to a defined set of applications and access levels. For organizations with a large number of employees and applications, we recommend using software to assist in managing the role definition effort. Some products to help you accomplish this task are:

· CA’s Eurekify Sage

· Sun’s Role Manager

· SailPoint

These tools analyze existing user access patterns across multiple systems and applications to define access privileges and associate those privileges to roles.

Role Definition Step 2: Determine Role Catalog Structure

A Role Catalog is a database designed to help manage the list of roles and information about each role, and most RBAC products have one. Role Catalogs are an important tool because they associate each role with permissions, policies (e.g., separation of duty), and even other roles depending on the type of role service levels being managed.

Current RBAC standards define four role service levels, and we recommend using these standards to define your role catalog structure. The rules are:

Level 1 - Flat RBAC – establishes and maintains many-to-many relationships among user-role and permission-role assignments.

Level 2 – Hierarchical RBAC – extends coverage to include user-role and inherited roles (role-to-role) assignments.

Level 3 – Constrained RBAC – applies separation of duty constraints and policies, both static and dynamic.

Level 4 – Symmetrical RBAC – provides a permission role review and auditing interface for role administrators.

Source: The NIST Model for Role-based Access Control

Role Definition Step 3: Define a Hierarchical Role Structure and Role Inheritance Model

The number of users, the types of roles and your security requirements will help you determine which RBAC Level to implement. If you are planning for a Level 2 – Hierarchical or higher, then you will also need to consider defining the role relationships or role inheritance model.

Inheritance allows for roles within the hierarchy to leverage the privileges of the lower roles. This can significantly reduce the number of roles you need to create. A typical hierarchy starts with three tiers of Roles:

– Tier 1: Permission Roles

These are the lowest tier of role that can be granted. Permission roles are typically defined and managed by the network file system, database or directory administrators. Examples include: Create, Delete, Modify, View Files, Data records or Directory Attributes.

– Tier 2: Technical or Application Roles

Technical Roles can inherit the existing lower tier Permission Roles. Technical roles are generally controlled by Application and or Directory Administrators based on how the application manages user or groups. The benefit of the inheritance is you directly assign a single Role to the user, but the user inherits multiple lower tier permissions.

– Tier 3: Organizational Roles

Organizational Roles inherit the lower tier roles and are directly assigned to the user. Organizational roles are typically defined by Operations and Management as the Job Title or Job Function.

NOTE: Most organizations will find that three tiers for inheritance are sufficient. While you can add as many tiers as you need, extra tiers tend to have an exponential affect on the number of roles and the relationships you must manage.

Role Definition Step 4: Define Role Administration processes

Once you have your roles and the role relationships defined, you can begin the process of determine the best administration process for you role catalogue. The administration process should indentify:

· Role Catalog Administrator

· Administrative process

o New role requests and approval process

o New role creation process

o Role Requests and approvals

o Security and Separation of Duty override approval process

o Auditing and Reporting process

For medium to large sized organizations, you may find the implementation of an Identity Management System (IDM) to be the best way to administer roles. Most IDM product vendors have also included RBAC in their product suite, which makes the overall system much more tightly integrated.

Enterprise-level RBAC provides a framework to manage access rights efficiently and enforces security/access policies across different user groups more effectively than previous administration models. Analyzing, developing and maintain your Role Based Access Control system may seem difficult at first, but the operational and cost benefits for those that are successful are significant. And those that administer their RBAC system with and Identity Management Framework enjoy the true benefits of process automation. With RBAC in place you are able to rapidly address changes in organizational structure and business processes while managing information security risks and access controls.

Best of the Blog: Decision Making Traps

noreply@blogger.com (John Dillard) — Mon, 14 Sep 2009 14:57:00 +0000

In reviewing the most recent Google Analytics info on this blog, I've been struck by the response to our posts on HBR's classic article on decision-making traps, which appeared some time ago. Based on the popular demand, I have posted below the links to each of the entries.

Part I: The Anchoring Trap

Part II: The Status Quo Trap

Part III: The Sunk Cost Trap (my personal favorite)

Part IV: The Confirming Evidence Trap

Part V: The Framing Trap

Part VI: The Estimating and Forecasting Trap

We're glad so many enjoyed these posts.

Role-Based Access Control – Where to Begin - Part II

noreply@blogger.com (Ron Bowron) — Thu, 06 Aug 2009 22:30:00 +0000

In Part I of this series we discussed the benefits of implementing Role-Based Access Control. In order to realize these benefits, we need to understand what applications their employees use to be productive in their jobs.

Question: How does someone go about developing a coherent and consistent definition of Roles across the information systems?

Answer: Application Portfolio Management (APM) and Application Rationalization

Application rationalization can help address the following:

Identify users that do not need access to the application
Establish a baseline for each position and how they use the information in applications
Identifies types of access required for each job/position
Prioritizes applications and identifies best candidates for RBAC implementation

Application Rationalization Step 1 - Eliminate the obvious

A good starting point to cleaning up this mess is to reach out to the application owners for the most sensitive/risky applications and show them the departmental positions that use the application and ask if those positions have the appropriate access. The application owners provide the first cut, eliminating those users in positions (and departments) who should never have access to the application.

Application Rationalization Step 2 -Identify the real needs

The next step is to go to the business managers in each respective department and get their approval as to which information and applications are required for each position.

Remove user from applications they no longer need access to or use.
Align information access with job responsibility/position.
Prioritize applications that will benefit the most from RBAC automation

At the end of this exercise, you will have cleaned up the application environment – having both removed departments and users who are in job functions that should never have access, and having eliminated users who should no longer have access based on their current job responsibilities.

Application Rationalization Step 3 - Final Step

Obtain buy-in from stake holders: Managers, Application owners and users.

Now all people in the same position will have access to the same applications. Determining the access each position requires makes it much easier to define roles and determine what applications a person should have access to and at what level. And that will be the focus of Part III of our RBAC series.

Coming soon: Role Based Access Control – Building your Role Library - Part III

Key Takeaways from The Burton Group’s Catalyst Conference, Part 2.

noreply@blogger.com (Brad Gates) — Tue, 04 Aug 2009 00:45:00 +0000

At first glance, the term “social networking” seems to have no place in the work environment. After all, “social” activities are all those things that take place after the work day has ended, right? Actually, what you’ll find now is that companies are beginning to leverage the power and insight social network maps provide. Craig Roth and Chris Howard, both from the Burton Group, gave a good presentation on the current uses of social networks in organizations. If you think about it, a social network just describes the connections between people. Those connections could be shared interests or collaborative relationships. Within an organization, hierarchies such as org charts and reporting changes are built but networks happen. Networks develop based on friendship, work interests / requirements, tasks, etc. The challenge for organizations is not how to artificially build networks, but how to leverage the organic networks that naturally happen. Some organizations are mapping those social networks using data mining techniques. By doing so, organizations can identify key subject matter experts, individuals who are collaborators, information owners, etc. By having these social maps, organizations can actively improve their operations through the encouragement of positive behaviors and individuals. For organizations wanting to leverage social networking in the work place, there are a few recommendations:

Deemphasize issues of age or “coolness” – social networks happens regardless of age and aren’t necessarily linked to present technology such as Facebook or Twitter.
Don’t dismiss the human dimension of the organizational environment – Any organization that consists of people, is a social organization. Accept it.
Engage early with IT departments – Develop appropriate tools to determine and build the network.
Be mindful of issues of privacy and security – Mine only data that is valuable and be transparent with your organization about what you are doing.

Burton Group’s Catalyst Conference: Dipping your toes into the Cloud

noreply@blogger.com (Hanno Ekdahl) — Fri, 31 Jul 2009 13:50:00 +0000

One of the more interesting sessions that I attended today discussed cloud security and some of the key issues organizations face when moving data across open, untrusted networks. These issues include the limitations of available security models, clear definition of data ownership, lack of visibility into incident management and resolution, and the need for comprehensive auditing. I walked away with the belief that the current vendor models offer customers too little control over their own data and applications to be viable in their current form.

Despite these challenges, cloud computing offers a number of benefits that make the solution an attractive opportunity, including reduced application deployment times, increased storage, reduced administration, and a pay-as-you-go model that matches expenditures with usage levels. Based on the sessions I attended, I believe that there are four fundamental areas that need to be addressed by vendors to make the cloud an attractive solution:

Better define and implement Data/Application Security

Provide incident management either directly, or facilitated through a trusted 3rd party

Provide Audit and Compliance functionality

Define an exit strategy for customers so they can bring data and applications back in house easily without incurring undue risk (e.g., loss of data)

Burton Group Catalyst Conference: Roles-Based Access Control Highlights

noreply@blogger.com (Hanno Ekdahl) — Thu, 30 Jul 2009 04:30:00 +0000

Today was the first day of the Catalyst Conference general sessions and a number of the sessions that I attended were focused on Identity Management and in particular RBAC. At Big Sky we have always asserted that Identity Management begins with defining the core business processes behind on-boarding and off-boarding users (employees, contractors, etc.) It’s nice to hear from the Catalyst presenters that organizations that have experience in implementing RBAC have a similar point of view; successful implementations start with the process and not by mapping system privileges. Begin at the top and drill down to the details. A summary of the key areas that need to be understood when defining roles:

What does each person do in their position? (e.g., DILO study of work processes)
How do we optimize the processes for that position? (What are the value-added decisions and activities), and then
Understand what applications that person needs to be effective within that process. (Determine how to best accomplish tasks and share information)

The roles definition will naturally fall out of this exercise and allow the business need to drive the IT implementation. After all, the effectiveness of the roles you define depends on properly matching the right entitlements with the right user in the right position.

Key Takeaways from The Burton Group’s Catalyst Conference.

noreply@blogger.com (Brad Gates) — Thu, 30 Jul 2009 01:00:00 +0000

I managed to gain some good insights today from two Catalyst Conference presentations on cloud computing / virtualization. Both speakers, Chris Wolf from the Burton Group and Mark Templeton from Citrix, emphasized the need for organizations to make deliberate changes to their business processes to successfully implement virtualization on any level. For most large scale change efforts like virtualization, the problems (and failures) often come from the people and processes, not from the technology. After all, technology just does what it’s told. To ensure success, organizations must take a step back from the actual technology to determine what organizational processes are in place now and how those should change in the future vis-à-vis the planned solution. Based on the speakers’ experience, organizations that are most successful with virtualization projects have made a commitment to analyze and change organizational processes as a first critical step to foster solution adoption and to maximize the delivery of business value. The successful implementation of any technology is never an isolated event as it profoundly affects both people and processes. An organization must recognize and plan for this disruption.

Dangers of Scores in Decision Making -- From James Taylor

noreply@blogger.com (John Dillard) — Mon, 27 Jul 2009 16:37:00 +0000

James Taylor, who we've referenced on this blog on several occasions, shared his thoughts today on the dangers of scores in decision making. He provides a great example: the Body Mass Index (BMI), which is fraught with issues but is nonetheless used inappropriately by companies and health officials alike.

I've seen the misuse of scores or other numbers in some of the organizations served by Big Sky. When a model is developed that produces a number or a score -- such as with Analytic Hierarchy Process, Statistics that measure strength of relationships, or even simple weighted averages -- there are many who focus too narrowly on the number without context, or fail to realize its limitations. For example, we will often help clients use quantitative methods to prioritize budgets, but the numbers that "pop out" are really nothing more than measures of preference; they are not truth. In many cases, they aren't useful measures outside of the model, and can't even be compared to previous analyses using the same method.

Scores must be balanced with other factors -- which James correctly points out can be codified in rules and often automated. For those decisions that can't be automated because they are inherently more political or are subject to other unpredictable factors, the limitations of "scores" should be carefully and frequently communicated to all stakeholders to avoid confusion or misuse.

Thanks to James for a great post.

Role-Based Access Control – Introduction – PART I

noreply@blogger.com (Ron Bowron) — Thu, 16 Jul 2009 15:32:00 +0000

Knowledge and innovation are key factors contributing to growth and prosperity in a service economy and require an information framework that organizes and makes information available when and where it is needed. The challenge facing organizations is not just in managing organizational knowledge, but in determining who should be given access to that knowledge. This Blog entry offers an overview of the latest set of tools known as Role-Based Access Control (RBAC) that provide a security model to manage access to sensitive organizational information.

Historically, organizations have granted access to their applications and data through a security system that is based on application-level administration to grant and deny access to resources. Administrators had to maintain a list of rights for users known as Access Control Lists, or ACLs, to manage system access. As the number of applications and users grew so too did the administrative burden of maintaining ACLs. Furthermore, the security risks to the organization increased because administrators had no effective tools to promptly remove users who should no longer have access to systems. These problems are eliminated in an RBAC security model, where user access is administered dynamically through Roles.

As organizations have opened up their networks to the Internet, securing their information resources has become much more complex. It is a difficult balance to strike between protecting customers, employees and shareholders from potential risks or losses and the need to achieve organizational goals efficiently and effectively. While many would argue that the security is a cost of doing business, the increased expense and effort required to implement effective security models becomes daunting as information is made widely accessible beyond organizational boundaries. This challenge can be mitigated, however, by Role-Based Access Control, which allows organizations to automate security decisions about who has access to what.

A Role has a set of permissions and by placing a user in a Role, that user is granted access to the systems or resources associated with the Role. Users are assigned to one or more Roles, and each Role is associated with a permission or set of permissions to IT resources. In this way, a Role establishes the relationship between the users and the systems that they are authorized to access and provides a much more efficient way to decide who has access to what resources. Organizations no longer have to work at the application or system level, instead they can use roles to assign the appropriate permissions en masse. As a user’s responsibilities change (i.e., they are promoted or move divisions) they are removed from their old roles and placed in new roles based on their job title.

Let’s walk through a quick example. Bob is hired by ABC, Inc. as a Financial Analyst I and gets assigned to the Base User Role, which grants access to the network, email, and the time & expense system. Bob also gets assigned to the Financial Analyst Role as is granted access to specific financial systems and reports required for his position. A couple of years down the road, Bob moves to Accounting and takes a position as Accountant II. As his position changes, he is automatically removed from the Financial Analyst role and assigned to the Accountant role, losing access to those systems he no longer requires to perform his job and gaining access to the accounting systems that he now needs. The end result is that security is implemented more efficiently and effectively and administrative holes (e.g., removing users from systems they no longer require) are eliminated. The question is “What do we need to get there?” which will be the subject of my next entry.

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

noreply@blogger.com (John Dillard) — Tue, 14 Jul 2009 12:30:00 +0000

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.

How Heathrow Fixed Itself (From Think Operations Research)

noreply@blogger.com (John Dillard) — Mon, 16 Mar 2009 12:02:00 +0000

I ran accross an interesting post today while reviewing Alltop's Operations Research page on how Heathrow Airport has fixed its initial problems with wait time. According to the Think Operations Research author, Heathrow has posted key performance measures in plain view for everyone to see, on giant screens:

"It measures and reports on the terminal's various wait time, service availability, overall ease and accuracy, as well as cleanliness."

I have not seen them myself, but the lesson here appears to be twofold: 1) Measure performance and 2) Share the results.

Decision Traps and Ponzi Schemes

noreply@blogger.com (John Dillard) — Mon, 15 Dec 2008 19:58:00 +0000

We have received great feedback from our readers on our series on decision traps, and they are also among our most read articles on this blog. I ran accross an article today that discusses the real-world consequences of those traps: the $50B Ponzi scheme orchestrated by the former head of the NASDAQ. For those of you who think that some people are too smart to fall into those traps, read this great analysis by Ken Hoffberg.

To paraphrase Ken, the scheme demonstrates at least two of the traps covered in this blog:

The Confirming Evidence Trap
The Anchoring Trap

Read for yourself, and assess where you might be falling into decision traps.

SOA: The Cure for Accidental Architecture

noreply@blogger.com (Hanno Ekdahl) — Mon, 02 Jun 2008 03:08:00 +0000

The term Accidental Architecture was coined in a paper published by the University of Kent that discusses the evolution of IT architectures over time and the complex issues surrounding legacy systems. The term has come to represent how narrowly focused technology investments result in an enterprise IT infrastructure that is both complex and challenging to manage. In most organizations, functional units drive IT investments in areas such as procurement, operations, and service delivery. Oftentimes, these IT systems are built to meet ‘local’ requirements and are not thought of as an enterprise-class solution that will interact with other systems and platforms. The net result of these siloed IT investments is an “Accidental Architecture”.

This is not to say that each individual solution is not well-architected, nor that if fails to meet the defined business need, but rather that at an enterprise level the architecture becomes ‘accidental’ as it is dictated by the provincial IT and business decisions that created it. In essence, IT decisions are made without evaluating their full impact on the enterprise and without an eye to the bigger picture, thus creating information gaps in the value chain. This is a missed opportunity to improve information quality, drive new efficiencies, and enable collaboration to provide additional value to the customer or end user. The end game here is to eliminate the information gaps to improve decision-making about operations, investments, and the execution of the organization’s mission.

So how do we avoid the pitfalls of an accidental architecture? We take a move out of Steven Covey’s playbook and ‘begin with the end in mind’. If our goal is to eliminate islands of information and barriers to collaboration, then we require a solution that promotes interoperability. The way to achieve this goal is to adopt enterprise standards that specify how different applications will interact and that also bridges the gaps between different platforms. We recommend adopting the IT principles commonly known as Services Oriented Architecture (SOA). SOA is an architectural style that is based on a set of evolving standards (some of which are mature, e.g. SOAP) that provide a framework for the development of Web services.

SOA provides the tools to manage Web services and specifies the means for service integration and interoperability. This allows developers to create the applications they need to solve business problems without having to worry about application integration issues down the road. This effectively separates the infrastructure from the application, which provides flexibility, reduces development costs, increases re-use, and allows the organization to deploy solutions that work across the enterprise.

As organizations move toward a Services Oriented Architecture, they often take an incremental approach and work to meet a discreet need before implementing web services on a large scale across the entire enterprise. A case study of ING Bank’s first SOA implementation is discussed in “The SOA Magazine” and gives a good overview of the process and lessons learned.

Using Visuals to Make Decisions: Excel 2007

noreply@blogger.com (John Dillard) — Sat, 17 May 2008 13:51:00 +0000

We've previously posted about the importance of using visuals to make decisions. I ran across an excellent post by Jon Peltier at PTS blog that provides a very useful overview of the new charting functions in excel. For those of us who use excel frequently to manage and present data in support of decision-making, a solid understanding of the new 2007 features are a must-have. Thanks, Jon.

Decision-Making Traps Part 6: The Estimating and Forecasting Trap

vishalkhushalani@gmail.com (Vishal Khushalani) — Mon, 07 Jan 2008 16:58:00 +0000

In our previous post in this series, we introduced “The Hidden Traps in Decision Making” by John S. Hammond, Ralph L. Keeney, and Howard Raiffa, in which they describe six traps in organizational decision-making that can adversely affect performance. This week’s post covers the final trap, the “The Estimating and Forecasting Trap”. Even though most of us are not very good at making estimates, we tend to be overconfident about our accuracy – which can lead to bad decisions. There are three different traps that can have a particularly distorting effect in uncertain situations because they cloud our ability to assess probabilities.

The Overconfidence Trap – Tend to be overconfident about our accuracy

The Prudence Trap – Over-cautiousness or prudence

The Recallability Trap – Base predictions of future events on the memory of past events.

Big Sky sees this trap in our clients especially when executives have strong domain or market experience. In addition, because very experienced people have excellent instincts, they can overlook trends that change the implicit assumptions in their mental decision-making process. For example, Clayton Christensen’s work on Innovation shows how the excellent customer-focused instincts of executives can actually crush the development of new, market-changing products. You can read more about Christensen’s “Innovator’s Dilemma” here.

Techniques to overcome:

Start by considering the extremes, the low and high ends of the possible range of values

Challenge estimates of your subordinates and advisers (overconfidence trap)

Always state your estimates honestly and explain to anyone if or not the estimates have been adjusted (prudence trap)

Carefully examine all your assumptions to ensure they’re not unduly influenced by your memory (recallability trap)

Closing thoughts on Decision-Making:

When it comes to business decisions, there’s rarely such a thing as a no-brainer. Our brains are always at work, sometimes, unfortunately, in ways that hinder rather than help us. At every stage of the decision-making process, misperceptions, biases, and other tricks of the mind can influence the choices we make.

The best protection against all psychological traps – in isolation or in combination – is awareness. Forewarned is forearmed. Even if you can’t eradicate the distortions ingrained into the way your mind works, you can build tests and disciplines into your decision-making process that can uncover errors in thinking before they become errors in judgment.

Decision-Making Traps Part 5: The Framing Trap

vishalkhushalani@gmail.com (Vishal Khushalani) — Mon, 07 Jan 2008 16:42:00 +0000

In our previous post in this series, we introduced “The Hidden Traps in Decision Making” by John S. Hammond, Ralph L. Keeney, and Howard Raiffa, in which they describe six traps in organizational decision-making that can adversely affect performance. This week’s post covers the fifth trap, the “The Framing Trap” which states that the way a problem is framed can profoundly influence the choices one makes. Research proves that people are risk averse when a problem is posed in terms of gains, but risk seeking when a problem is posed in terms of avoiding losses.

Big Sky sees this trap in our clients especially when executives consciously or unconsciously frame the problem such that their proposed solution seems to be the best answer. Also, executives might focus on highlighting their pain areas which might not be a pain area for somebody else.

Techniques to overcome:

Don’t automatically accept the initial frame, try posing problems in a neutral redundant way that combines the gains and losses or embraces different reference points
Think hard throughout your decision-making process about the framing of the problem, and when others recommend decisions, examine the way they framed the problem.

Our next post in this series will discuss the “Estimating and Forecasting Trap” outlined in the article.

Decision-Making Traps Part 4: The Confirming-Evidence Trap

vishalkhushalani@gmail.com (Vishal Khushalani) — Wed, 28 Nov 2007 00:55:00 +0000

In our previous post in this series, we introduced “The Hidden Traps in Decision Making” by John S. Hammond, Ralph L. Keeney, and Howard Raiffa, in which they describe six traps in organizational decision-making that can adversely affect performance. This week’s post covers the fourth trap, the “The Confirming-Evidence Trap” that leads us to seek out information that supports our existing instinct or point of view while avoiding information that contradicts it. This not only affects where we go to look for evidence, but also how we interpret the information that we receive.

Big Sky sees this trap in our clients especially when executives are biased based on their past experience and knowledge, or if they are pushing for their pet projects. For example, when we help client prioritize investments, we find that some executives are very surprised with how an objective process is at odds with their “gut.” For a great read on this phenomenon, check out Moneyball by Michael Lewis. Clients who are in “The Status-Quo” and “The Sunk-Cost” traps also succumb to “The Confirming-Evidence” trap.

Techniques to overcome:

Confirm that you are examining all the evidence with equal rigor
Find someone you respect to play the devil’s advocate
Be honest with yourself about your motives (are you gathering information to confirm what you already think?)
While seeking advice of others, don’t ask leading questions that invite confirming evidence

Our next post in this series will discuss the “The Framing Trap” outlined in the article and will be posted next week.

Decision-Making Traps Part 3: The Sunk-Cost Trap

vishalkhushalani@gmail.com (Vishal Khushalani) — Mon, 05 Nov 2007 22:06:00 +0000

In our previous posts in this series, we introduced “The Hidden Traps in Decision Making” by John S. Hammond, Ralph L. Keeney, and Howard Raiffa, in which they describe six traps in organizational decision-making that can adversely affect performance. This week’s post covers the third trap, the “Sunk-Cost Trap”, that talks about our deep-seated biases to make choices in a way that justifies past choices, even when the past choices no longer seem valid. These past decisions often involve considering sunk costs in assessing the viability of a project – old investments of time or money that are no longer recoverable. One might also call this “throwing good money after bad.”

Big Sky sees this trap in our clients especially when…switching costs are high or if there are budget constraints. When huge investments have already been made, the team that made that decision tries to justify that decision. In many of Big Sky’s government clients’ large complex IT projects continue to command major investment well after it’s clear to all that the projects have failed. Rather than redirecting investment to better options, some organizations will continue to try to salvage huge IT investment by bolting on functionality or placing band-aids on system issues.

Techniques to overcome:

Always be mindful of long-term objectives and examine how they would be served by the status quo, if at all
While considering other options, evaluate the status-quo alternative if it was just another option, rather than the front-runner
Avoid exaggerating switching costs
And finally, always evaluate alternatives in terms of future as well as present context

Our next post in this series will discuss the “The Confirming-Evidence Trap” outlined in the article and will be posted next week.

Decision-Making Traps Part 2: The Status Quo Trap

vishalkhushalani@gmail.com (Vishal Khushalani) — Tue, 30 Oct 2007 18:46:00 +0000

In our previous post in this series, we introduced “The Hidden Traps in Decision Making” by John S. Hammond, Ralph L. Keeney, and Howard Raiffa, in which they describe six traps in organizational decision-making that can adversely affect performance. This week’s post covers the second trap, the “Status Quo Trap,” that we also observe in our clients on a regular basis. In organizations that display the Status Quo trap, decision makers display a strong bias toward alternatives that perpetuate the status quo. Breaking the status quo means taking action, and when we take action, we take responsibility, thus opening ourselves to criticism and to regret.

Big Sky sees this trap in our clients especially when…organizational cultures do not encourage change. When employees are not rewarded to take risks but are penalized for unfavorable outcomes, they choose to stay with the tested-and-tried way of doing business. For example, we have observed in some R&D clients a tendency to reward large projects that transition to operational use, but stigma is applied to failed attempts at innovation. This encourages R&D planners to over-weight project with a high probability of success and projects that are already fully funded, rather than creating a portfolio that includes some high-risk projects.

Techniques to overcome: A few ideas for avoiding the status quo trap include:

Remind yourself of your objectives and examine how they would be served by the status quo
Identify other options – don’t assume that there aren’t any
Ask yourself if you would choose the status-quo alternative if it was not the status quo
Avoid exaggerating switching costs
Evaluate alternatives in terms of future as well as present context

Our next post in this series will discuss the “Sunk-Cost Trap” outlined in the article and will be posted next week.

Decision-Making Traps Part 1: The Anchoring Trap

vishalkhushalani@gmail.com (Vishal Khushalani) — Fri, 12 Oct 2007 21:14:00 +0000

John S. Hammond, Ralph L. Keeney, and Howard Raiffa wrote an article in Harvard Business Review “The Hidden Traps in Decision Making” which discusses different traps of the mind and different ways in which we can overcome these traps. All of us are susceptible to making bad decisions and judgments unless we can learn to recognize and avoid them. Even though the article was written nearly a decade ago in 1998, it is still highly relevant and important in the context of decision making. Hence, despite its age, we decided to devote a series of posts highlighting each of these six “traps,” and the techniques that these authors recommend to overcome them. This first post discusses “The Anchoring Trap” and will be followed by one post for each of the five remaining traps identified by the authors.

#1: The Anchoring Trap: When considering a decision, the mind gives disproportionate weight to the first information it receives. Initial impressions, estimates, or data anchor subsequent thoughts and judgments. This pernicious mental phenomenon is known as anchoring.

Big Sky Sees this trap in our clients when. . . time is of the essence. When organizations are under particular pressure to make a decision fast, the anchoring trap becomes particularly acute as there is little patience to wait for alternative information.
Techniques to overcome: View a problem from different perspectives (use a different starting point to avoid the anchor), be open minded, be careful to avoid anchoring your advisor (tell them as little as possible and ask for their opinion), and be particularly wary of anchors in negotiations.

Our next post in this series will discuss the “Status Quo Trap” outlined in the article and will be posted next week.

Interview with James Taylor, Author of "Smart (Enough) Systems"

noreply@blogger.com (John Dillard) — Mon, 30 Jul 2007 14:29:00 +0000

James Taylor, a frequent commenter on this blog and the author of one of the best decision analytics blogs out there, recently published a guide to Enterprise Decision Management called Smart (Enough) Systems. We recently had the chance to speak to James about the book and about the relationship between technology and effective decision-making.

BST: Thank you for taking the time to talk to us about your new book, Smart (Enough) Systems. What motivated you to write a book on this subject?

JT: It seemed to me that there was a very limited awareness of how existing technologies were being used to make point systems smarter – both in terms of companies who had used the technology in one area but not others and in terms of companies who did not seem to realize what was possible. Companies were putting up with really “dumb” systems because they thought the alternative was something that only existed in the lab. Neil’s experience was very similar in that he too saw companies getting far too little value out of their data. A book offers both a platform for explaining something thoroughly and a “proof point” that this is a serious and “real” approach.

BST: You place a lot of emphasis on Operational Decisions in the book. Could you talk about why they are particularly important?

JT: It is not so much that operational decisions are more or less important than, say, strategic decisions. It is more that they are totally neglected in most organizations. When I talk to companies about their operations and identify the decisions that drive the high volume systems and processes in their business, they have typically not even considered them. The operational decisions that make or break the profitability of a customer or the cost of a transaction are delegated to programmers, front-line staff or generic software packages almost without thought. That’s why the book focuses so much on them – they are sadly neglected.

BST: We found your discussion of strategic alignment and choosing the right decisions particularly important in the book. How critical is it for organizations to find the right decisions to improve?

JT: Well the approach we outline in the book is clearly aimed at a certain class of decisions, operational decisions as you note, and so focusing on that kind of decision is very important. It won’t work well to try and use enterprise decision management, the approach outlined in the book, to manage and improve strategic decisions for instance. That said I think companies can use the techniques and technologies we discuss on a very wide range of decisions and that it is not critical to pick the right one out of them to get started. One of the hardest problems can be getting people to realize that decisions are being made in a certain point in a process and then getting them to focus on it as a distinct opportunity for improvement. Given this difficulty it may well be that you have to start with the decisions people can “see”.

BST: We have written about how many organizations that could be applying more sophisticated decision analytics – or any type of more rigorous quantitative analysis – haven’t yet done so. How do you convince these more reluctant organizations that there is real value in this approach?

JT: Well I think the biggest issue is understanding how they can apply these things to their operations and the focus on decisions, not on reports or analysis, is critical. I think the process we lay out in the book that takes a series of baby steps to get more and more sophisticated about decision-making having called out and focused on the decision.

BST: The book emphasizes the importance of business rules, and of having an integrated development environment to hold those rules to provide services. This is a very similar concept to Identity Management, which provides a central database to manage the user lifecycle across multiple connected systems based on business rules and policies. Given the similarity of these approaches, do you see a convergence of these technologies, and if so, what do you see as the end game?

JT: That’s an interesting question and one I have not really thought about. In general, I tend to differentiate between using rules as part of solving a problem (like identity management) and focusing explicitly on decisions and decision management, using rules. In this case, then, I would expect to see rules-based identity management (using rules to make identity management decisions) and a separate use of rules as part of taking control of business decision making.

BST: In several examples in the book, you discuss not only the technical challenges to EDM, but also the cultural challenges. What are the most common cultural barriers/challenges that organizations must overcome to adopt better decision making methodologies? Are these challenges restricted to “traditional” businesses (like banking)?

JT: I think there are a number. There is a lack of management focus on operations – execs see their role as making strategic decisions not improving execution. There is a lack of trust and collaboration between IT and business units that make collaborating on decision management hard. Data is often poorly understood and what understanding there is tends to be backward facing not forward. Lastly there is a change issue – can companies really change the way they regard operational decisions. Each varies in companies but all are an issue that need to be considered as part of an adoption plan.

BST: Another interesting point you make is the need to enable IT capabilities so that IT can be where the business needs it. This can be a bit of a chicken and egg problem, because in many organizations the IT department is seen as a cost center and as such, it is often starved for funds. Who typically drives these infrastructure changes? In your experience, are there particular governance models that enable the type of adaptability and collaboration necessary to make EDM efforts successful?

JT: Well there are a couple of perspectives. A risk-based approach where the risk of not being able to change systems drives a willingness to invest in modernization (calculate the risk to the company of not being able to change systems quickly enough or where their accuracy is too poor). An opportunity-based one where the approach is applied only to new systems and the more effective development and ongoing evolution of those applications gradually frees up dollars to revisit old ones. Lastly there is a growth-oriented one where a company allows a proposal to spend money for a return that drives a new decision automation project that drives additional revenue. The additional revenue is then allocated to clean up old ones. There’s no magic bullet.

BST: If your readers want to learn more about this discipline, what would you recommend that they read next (after they read “Smart Enough Systems”)?

After they read it and recommend it to all their friends you mean? Well, there are some good blogs out there (yours, mine and others) on analytics (both technical and organizationally focused), rules, and customer-experience. There are some great books too – Competing on Analytics, Linnoff and Berry on Data Mining, The Business Rules Revolution and many others – on the specifics of various parts of the approach (all of these are listed on the companion site, www.smartenoughsystems.com) . Mostly, though, I would suggest starting! The hardest thing is having experience so getting started is key.