International Process and Performance Institute

Having two teenage boys who played a lot of video games, I came to understand an interesting and recent addition to the English language.  The word “spawn” has for some time defined the reproduction of egg bearing aquatic animals, and more recently, a computing term where a system process executes a child process.  In video games the characters, including the players, are “spawned” into the game and when they are killed off (in the game of course), the characters can come back to life or “respawn.”  I found this concept of “respawning” very interesting.  I would give my sons a hard time about game realism being such a highly sought after feature in video gaming culture, and yet where was the realism in respawning in the middle of the game?  I would occasionally challenge them to show one real-life example of respawning in the world.  Of course, they would ignore my unsolicited cynicism by continuing to play their game.

My cynicism about the concept of respawning continued for some time, until I actually discovered it in the real world of process.  What I discovered was that certain Moments of Truth had a natural tendency of respawning when they failed.  Moments of Truth are the places in our processes where the customer is involved or “touched.”  Imagine you are calling the support line for your Internet provider and you get a busy signal.  You say to yourself, “that’s odd”, then pick up the phone and dial again.  Is it one Moment of Truth or two?  Imagine you are filling in a form on a website.  After completing all the necessary fields and selecting “Continue”, the display blinks and takes you back to the form to complete again.  You’re pretty certain you filled in the form correctly, but you fill it in again and select “Continue”, only for it to repeat the behavior and blank the form again.  You tell yourself, “third time is a charm” and proceed to fill it out one more time; sure enough, that time it works.  Is it one Moment of Truth or three? 

These examples and many others point to the fact that when Moments of Truth fail, they sometimes respawn until either successful or the customer gives up.  These are not different Moments of Truth but the same, and can keep occurring iteratively until successful.  I hope this can help in your analysis efforts in more accurately determining the process Moments of Truth (MOTs).

I recently received an email query from a member in regard to Process Activity Lists (PALs) I would like to share because it was an outstanding question and one I think a lot of members might have.   The query was:

Hello,

I am puzzled how PALs (Process Activity Lists) can be used to fully represent Processes. I am used to working with BPMN and divergent paths based on decisions (e.g. if product is IN STOCK follow one path, otherwise follow another). I am not clear how PALs represent this. In the CEM Optimize method, sequential activities, allotted to an actor, are joined by a line ... if a decision point were reached, then the line would surely split. For example, suppose that the case study referred to provision of internet services and a diagnostic revealed a line problem versus a router problem or a customer configuration problem. Further suppose that each diagnosis required different subsequent flow... How would a PAL represent this?

To appropriately answer this question, we need to start by putting anything we might use to represent a process in proper perspective.  No mapping tool or map can "fully represent" a process as anything we develop to represent the process is an abstraction (i.e. the map at some level represents the thing but is NOT the thing).  What we need to consider is what level of abstraction is relevant to any given process related activity or objective. 

One of the best examples of this principle is the use of mapping or GPS software for creating a travel route.  When our objective is to see the overall route and/or our relative position on the route, it often requires a higher level of abstraction (the big picture).  However, when we are trying to navigate at the street level, a much lower level of abstraction is required.  The original high level view is of no help at that point and visa-versa. 

When it comes to process, if our objective is to provide detailed documentation of a process for system development or other detail oriented reasons, a PAL is not the right level of abstraction.  However, when performing Optimization or Alignment analysis, it is exactly the right level of abstraction because it keeps us from the detail which does not help us in those activities.  In fact, it is often a high level of process detail that gets process improvement activities mired and "lost in the weeds."

Seems like everyone in the IT world is talking about Clouds, and I'm not referring to those fluffy white things in the sky. The hype around Cloud Computing is in high gear, with visions of pay per use computing, elastic capacity and significant time-to-market improvements. In fact, many IT architectures are changing, or will be, as a result of this phenomenon.

Regardless of what Enterprise Architecture (EA) framework you like, they all supposedly start with the same thing; the vision and mission of the business. However, in looking around at various EA frameworks you'll find very little information on the principle driver of any business --- The Customer. This assumption can lead to Inside-Out thinking and a cloudy vision of where the business needs to go.

"If we want to know what a business is we have to start with its purpose…  There is only one valid definition of business purpose: to create a customer."
 - Peter Drucker

It's not too surprising that we lose sight of simple truths when the world around us is getting more complex. I recently read an article by McKinsey & Company titled "Why business needs should shape IT architecture" which stated,

"Complexity is rife in any growing business. … As application volumes grow in response to a fast-changing economic, regulatory and business environment, the issue of complexity is becoming acute for many organizations."

The growth in the number and complexity of business applications is causing a lot of analysis to be done about application characteristics, i.e., are they 'suitable' for cloud computing; but more analysis must be done to complete an accurate picture.

Cloudy Vision = Cloudy Future

It is not just architecture that's changing as a result of cloud computing, entire business models are changing as well. This screams for more focus on the external customers of the business; focusing on application characteristics alone may not be enough.

The McKinsey article went on to discuss Enterprise Architecture Management (EAM), as a framework to manage IT architecture. It also emphasizes the importance of the business in leading EAM initiatives, and establishing a Business Lane for your ITIL© Road Map is something I've been ranting about for some time now:

    Business Process Dependencies & Cloud Computing
    Is your IT organization driving the Bus?
    3 Days in the Bus Lane

One of the steps in creating an Enterprise Architecture is to establish a baseline model; the 'as is' state of your current business processes. The McKinsey article mentioned what can happen when IT/technical folks drive process documentation efforts:

"A weak linkage to the business creates a void that limits the quality of the     resulting IT architecture and the organization's ability to enforce and sustain the benefits of implementation over time."

However, even when individual business units take the lead in defining business processes they often restrict scope to their own functional unit. This encourages inside-out thinking and can blur the vision and mission for the business, since customer-facing processes routinely cross functional borders.

The frenzy to take advantage of cloud computing's benefits may lead some to place applications in the cloud without really understanding how they underpin Level 1 (customer-facing) business processes. This can increase risk significantly.

See clearly by looking through the eyes of the Customer

Concepts like Successful Customer Outcomes (SCO) and Moments of Truth (MOT), along with defining business processes in terms of how they serve (or do not serve) external customers are simple techniques that can be used consistently to ensure that you maintain an outside-in focus.

By defining business processes as Level 1 through 4, using the SCO and MOT techniques, organizations can create business process dependencies that are directly tied to how they serve external customers. This can improve decision making about when to use cloud services, but perhaps more importantly can provide a foundation for business process innovation.

Unless you take the energy to re-enforce these simple truths then the unrelenting pace of business and increasing complexity will blur your organizational focus.

Use of IPAPI's Education Program and the Customer Expectation Management Method can help you and your organization see clearly through the clouds that are ahead.

While I'm as excited about the potential that cloud computing may provide, I'm concerned that it may be one more thing encouraging us to take our eye off what really matters --- customers. The attraction of 'cloud computing' may be driven -- at least in part -- by a desire to take runaway complexity and place it in someone else's hands.

The importance of understanding your business process dependencies is likely to increase as we seek cloud computing, regardless of whether your direction is public, private or a hybrid approach.

One of the things I like about the Outside-In thinking and/or the Customer Expectation Management Method is how we can establish business process dependencies based on how they serve external customers. I think this is useful in may ways.

Level 1 processes --- those that encapsulate the entire customer experience --- provide a basis for establishing priority, uniformity of purpose and innovation. They are key to achieving and maintaining an 'outside-in' focus.

Level 2 processes --- those that have at least one Moment of Truth (direct customer interaction) but do not encapsulate the entire customer experience --- support Level 1 processes. Similarly, Level 3 processes -- which do not have any Moments of Truth but do link to at least one Level 2 process --- are supportive of Level 2 processes.

Many in the IT world are discussing this concept of dependency management. In fact, I like to mention this quote in many of my ITIL classes:

"The central challenge of IT governance is the simple dependency: application depends on database, database depends on server, server depends on switch, application depends on application and so forth. IT organizations deal with this critical data on a daily basis and treat it shamefully - essentially as a disposable commodity."

Architecture & Governance Magazine - Volume 1, Issue 1
The Last Word: Dependency Management: A Fundamental Challenge of IT Governance
By Charlie Betz, Author and Enterprise Architect

This quote could easily apply to the business as well.

Failure to understand and document critical business process dependencies, and how they serve the customer, is a fundamental business responsibility. Unfortunately, businesses are just as likely to treat this dependency data as shamefully as IT treats technical dependency information.

It is also just as common for business units to define processes from a functional, internal perspective. But external customers do not want to see 'business units' any more than than the business wants to deal with individual technology domains.

In fact, if business process dependencies are not understood based on how they serve external customers all the efforts IT makes on the business' behalf can in vain. It is not enough to know which applications may be suitable for cloud computing based on their characteristics, business process dependencies must be understood as well.

Proper design, ongoing governance, and managing IT for value depend on understanding customers and markets --- with or without 'clouds'. An outside-in understanding of business process dependencies is essential to this effort.

When Balanced Scorecard first descended upon the business world in the late 80’s and early 90’s, it was a fresh and needed perspective that promised to help our organizations rise above the decidedly one-sided financial performance measures used up to that time.  Frankly, most organizations who have tried to implement a Balanced Scorecard have not reached the success they were looking for and the reasons are varied.  Balanced Scorecard has served a purpose to help us understand we need other ways to monitor and measure the outcomes which are linked to organizational success.  However, I’d like to talk about why it often fails and offer some suggestions for success in your scorecard efforts.

Most of the reasons Balanced Scorecard implementations fail are centered on the measures themselves.  One of the top reasons is picking the wrong measures; but includes unrealistic goals for the measures, lack of alignment with the real objectives, and the measures themselves being too difficult or expensive to effectively gather.  Next are issues such as conflicts with the legacy reward systems, measures losing relevancy over time, and failure to use the measurements to initiate corrective actions. Other reasons center on management issues such as poor project management, lack of senior management support, and lack of internal promotion.  Yes, implementing a Balanced Scorecard has some challenges.

I’d like to share with you another challenge I see with Balanced Scorecard.  While Balanced Scorecard has helped us set our sights on other ways to measure our organizations, when we look at what really matters, it is not truly a balance we should look for.  Peter Drucker prophetically told us years ago the customer is the foundation of every business; indeed, the customer is the business itself.  If we take care of the customer, we take care of the business and all stakeholders benefit.  We often give lip service to the customer.  In reality, the shareholders get primary deference in most publicly traded organizations, and even privately held organizations can be myopically focused on profits, ROI, ROC and the like. 

 The customer is our rallying point without question.  If all stakeholders agree the customer is the most important stakeholder in our organizations, there is no argument what our focus should be.  Even the stakeholder whom we call the customer agrees with this point of view.  It is inarguable.  Why do we take any other position?  Frankly, the truth is, we often do exactly that. 

While I wholly endorse the direction Balanced Scorecard has taken us from the narrowly focused financial measures, let’s not get hung up completely on the “balance” part.  The measures our organizations need to be keenly focused on are primarily related to our customers.  The companies who are leading their markets are using metrics correlating to what delivers successful customer outcomes, and that makes all the difference.

I can hear some muttering, “But satisfying the customer without a profit does no one any good.”  My response to that kind of thinking is to say if you can’t figure out how to deliver what your customers want and also make a reasonable profit, then based on Drucker’s definition of a business, you don’t have one.  All you have is an exercise in futility or perhaps a non-profit.  If profit is your motive, you need to rethink your approach or quit and end your suffering.

Creating a scorecard for your organization could be the right idea; here are some things to consider before you embark on that journey.  Hold off if your organization is in any situation that resembles a crisis, is struggling, or currently involved in any other large projects.  Projects of that magnitude are steep; if your organization is already on a hefty climb, it will most likely prove to be too much.

Consider looking at some of your organization’s most customer facing processes.  Perform a CEM Alignment analysis; you’ll get clarity on what customers really want while developing the KPI’s to measure your delivery.  This analysis is critical to discovering the right measures for your scorecard.

But don’t get hung up on balance.  A customer leaning scorecard is ideal.  Metrics related to your customers (by whatever name you call them), and their satisfaction, should be more prominent and weighted more heavily than any other measures you implement.  Nothing provides the opportunity for greater satisfaction for all stakeholders than raving customers.  That feels good and is good for everyone involved.  And remember, most scorecard efforts fail around the measures themselves.  Your measures truly need to gauge the delivery of outcomes the customers perceive successful to them.

As an ITIL© consultant and trainer, I've used words like: Top-Down...End-to-End... Outside-In... and I'm afraid that adding this jargon to the jumble of ITIL terms may be resulting in clients getting a picture that looks something like M.C. Escher's Relativity. 

More often than not, Service Catalogs represent IT's view of the world and are nothing more than Technical Catalogs that mean very little to the business (and even less to the business' customers).

This reality simply must change if the vision for ITSM is to be realized. Nowhere is this more exposed than when we instrument IT services for 'end-to-end' monitoring. Everything's relative.

So I thought I'd put some of these terms in perspective to highlight why this matters when defining IT services.

Outside-In, End-to-End, Top-Down .... just what are we talking about?

The term Outside-In is not new. In fact its roots trace back to Peter Drucker's work in the 1950's:

“It is the customer who determines what a business is. For it is the customer, and he alone, who through being willing to pay for a good or a service, converts economic resources into wealth, things into goods. What the business thinks it produces is not of first importance—especially not to the future of the business and to its success. What the customer thinks he is buying, what he considers ‘value’ is decisive—it determines what a business is, what it produces and whether it will prosper. The customer is the foundation of a business and keeps it in existence. He alone gives employment.”

GE drank this Kool-Aid long ago too:

If IT seeks alignment with the business then the best way to achieve this is to align with the business' External Customers. ITIL©'s Service Design (figure 3.10, page 41) shows 'Integrated business-driven technology management' and states:

“[ ...it is vital that the management architecture is developed from the business and service perspective (i.e. 'top down').]”

So Top-Down suggests we should be focusing design efforts on understanding requirements (duh) and then proceeding to Bottoms-Up implementation (i.e., monitoring instrumentation) efforts. OK, so what about 'End-to-End'? As best I can tell this started as one of the design principals of the Internet; my simple mind translates this into every layer (i.e., the ISO 7-Layer Model) of every component (i.e., Configuration Item) of an IT service ---- and therein lies the rub.

Why Outside-In (read External Customer) Perspective Matters

How we define services is as fundamental to IT service management as a CMDB, Service Catalog or any  IT process. Most would agree that limiting service definition to a Technical Catalog of services is not adequate, which is why we have a Business Catalog of services as well.

However, even when we view The Business as our (IT's) customer we can be off the mark when it comes to defining services. The silos that exist in IT also exist in the business, and it is common for organizations to take a functional (inward) view of business processes.

So we wind up with Finance, Sales, Marketing, Manufacturing etc. processes that make good sense to the business (but may not make very good sense to external customers). The processes customers 'see' often cross functional boundaries, and in many cases supplier boundaries as well. This complexity of customer/supplier relationships, coupled with an inward view of business processes, can spell trouble for an organization. In a world of increased outsourcing and cloud computing, this is of paramount importance. 

When the term End-to-End is used, we must ask the question from whose perspective? Ask a functional unit like manufacturing or finance and you're likely to get a systems oriented view of their processes;

“[ ...The great shortcoming of the input-process-output paradigm is that it leads to a focus on the internal workings of a system so intense that the external world is sometimes ignored or overlooked. .... Nickols 2003]”

Perhaps more importantly, Outside-In thinking is an organizing principal. It provides a uniformity of purpose that all functional units in the organization can relate to. This is critical to obtaining acceptance and keeping people pulling the rope in the same direction. It also establishes the boundaries essential for defining what 'End-to-End' means.

So, when the Good Books say define VALUE as part of Strategy, be careful to simply view 'the business' as IT's customer; it's the External Customers of the business that really matter.

Outside-In and Service Monitoring Intelligence

While there can be some benefits associated with service monitoring intelligence even when true End-to-End services are not defined from the eyes of external customers, the value of monitoring intelligence increases when we get closer to an external customer perspective of End-to-End services.

Of course simply instrumenting individual silos (network, Web, App, DB, et al) is not close to 'End-to-End'. However, even if we instrument infrastructure 'End-to-End' (meaning we've included all infrastructure components) it offers minimal benefit. The reason is that the applications that ride on top of that infrastructure are closer to the business.

But even when we instrument both infrastructure and applications, we can still miss the mark. The most obvious example of this is when key transactions are not identified or instrumented for monitoring. To quote Nickols again, “[ ...the external world is a vital factor in the performance of all systems. The relationship between an organization and its external world is characterized by transactions -- by the exchange of outputs for inputs."]

Another benefit of taking the time to understand high level business processes from external customer perspectives is that it clarifies what monitoring views are appropriate for the organization. This has everything to do with the cross functional nature of business processes and establishing boundaries essential to understand what End-to-End really means. This is a Top-Down design activity that requires adequate time be spent up front.

Finally (and perhaps most importantly), cycles of monitoring instrumentation are improvement cycles. When we target monitoring instrumentation without the unifying thread of external customers, we can wreak havoc on the organization. For example, services are targeted where parts of the infrastructure are undergoing a server refresh or applications are under extreme pressure for a new release. When this happens, the monitoring instrumentation cycle is at odds with the organization.

So call it what you want.... Top Down, End-to-End or Outside-In. 

Perspective matters. 

I haven’t talked to many who have positive things to say about 2009, except that it is finally behind us.  On the other hand, everyone seems to be highly optimistic about 2010.  I think there is every reason to believe this year will be full of opportunities.  However, I think the best opportunities will come from a different set of behaviors and tactics than we have been using to survive the last two years.

2009 was a year of honing our survival tactics. For many of us in the process business, it meant using our skills to “lean” operations and milk every opportunity to cut costs.  For many organizations those efforts have resulted in significant cost reductions, and in the end, the very survival of our companies.  It wasn’t easy, but survival is good.  Many companies did not fare as well.  I haven’t seen any hard numbers yet, but I don’t recall seeing or hearing about so many business failures as I did in 2009.  I’m very sorry for them all.

For the survivors, I would like to suggest the behaviors which helped us survive are not necessarily the ones to help us take advantage of the opportunity before us, for two reasons.  First, while you have been focused inward on your internal processes and cost cutting, your customers have most likely changed.  While you have had your attentions on reducing the drag on the trigger-pull, your target customer may have moved outside the crosshairs.  Very few of us have come through the last two years without a different view of the world, altered perspectives, modified values, or even a different idea of what we want and what is really important to us.  We have changed in some way and so has our customer.  We need to check in and try to understand what may have changed.

The second reason we may need to take a different approach is the reality that cost cutting and leaning our processes sometimes has the undesirable effect of pushing work and risk back on the customer, who is paying us to take it on.  Have you felt this yourself recently?  I have on a number of fronts. 

One instance was when I recently helped a friend with a problem he was experiencing with his laptop.  He had purchased the laptop only a month before from a retail outlet.  The laptop came with instructions on how to obtain technical support from the manufacturer (a company based in Texas that normally sells direct to the customer).  Upon validating the serial number of the laptop for warranty and service, the manufacturer’s technical support informed us that since the laptop had been purchased through a retail channel, they could not support it and we needed to call the retailer for support.  Humph, ok… We called the retailer, who told us they didn’t have the resources to help, and to call the manufacturer or they could send out someone who charged by the hour. 

I know the PC business is a tough business these days, but this company (like many others) has taken it to an extreme, which only serves to push back on and alienate the customer.  And while the customer defections may not start right away, they will eventually and with certainty.  Customers will not continue to suffer.  Without correction, they will defect. 

Our opportunity in the coming year (or even decade) is to look at our organizations and processes anew with an eye to making sure they are in alignment with our customers.  We need to think about what has changed for them; what do we need to do differently to better serve them, or what new challenges do they face that we could help them with?  We also need to look to see if we have changed in a negative way that affects them in ways that frustrate them.  How can we make them successful?  The only true business success comes with making our customers successful from their point of view (not ours). 

From the Directors, Advisors and volunteers at IPAPI, we wish you the best of success in 2010 and your best year ever!

Having spent most of the past 30 years in information technology, I've tended to assume that business folks are highly focused on the business' customers. They bring in the money, right?

But it is increasingly apparent that in many organizations they've lost sight of them, and even when the business is still customer-focused the IT organization is often so far removed from these external customers that they really have no idea how technology underpins the business.

So, we have IT service management guidance (i.e., ITIL©, etc.) that suggests we create IT Service Catalogs to help with this alignment issue. Easy, right? Well not really.

I've already talked on this blog about Marketing Mindsets and Minding the Gap, so I won't repeat this information here. What I'd like to elaborate on is how IPAPI's Certifed Process Professional (CPP) and Certified Process Manager (CPM) classes can help.

The CPP class introduces (or re-introduces) outside-in thinking through the Successful Customer Outcomes (SCO) techniques as well as how to simplify processes. It's focus is on process alignment, optimization and innovation. The CPM class describes a customer-centric enterprise architecture, discusses process strategy and establishing process metrics that are tied to SCOs.

Each of these classes can be very helpful if you are attempting to establish a Business Catalog of IT services. This is an important point, since many IT organizations have wound up with Technical Catalogs that mean much more to IT than to the business. In fact, acheiving the ultimate goal of IT service management (business/IT alignment and integration) wil not happen unless you are successful in creating a Business Catalog of IT services.

This is where the CPP and CPM classes could be very helpful! CPP will establish process analysis techniques that are driven by SCOs; making sure that the business stays focused on external customers (the ones that pay the bills, remember?). CPM will establish a clear understanding of Level 1, 2, 3 and 4 processes based on external customers, which will help identify process boundaries and potential cross-functional conflicts. Using external customers to create uniformity of purpose can keep folks on track. If you have 15 minutes you can hear me talk about how ITSM On-Ramp™ Services leverage IPAPI's methods.

So if you've drank the Service Catalog Kool-Aid, great! Make sure you start at the beginning --- with external customers. Marketing Mindsets and Minding the Gap are essential to a well designed service catalog.

Start the new year off with a marketing mindset and mind the gap between you and your customers, and between your business and IT. IPAPI's CPP and CPM can help.

We don’t often think of governments as purveyors of great customer service. In fact, we are often dumbfounded when a government agency actually delivers what we would call “good customer service.”  When it happens we first think “Oh, this person must be new and doesn’t understand yet;” or “I’ve passed into an alternate reality and this really isn’t happening.”  The problem is when it comes to most governments, and in particular, western governments; they don’t have any clarity who the customer really is.  So when processes are designed and implemented, they often serve only the funding source such as the chief executive (i.e Mayor, Governor or PM, or President) or legislative body (i.e. legislatures, parliaments, Congress, etc.). 

However, I have seen an interesting trend in the Middle East of late.  Many of the eGovernement initiatives in a number of Middle Eastern countries are setting their sights on satisfying who is most often the real customer – the citizen.  One example is the Kingdom of Bahrain’s eGovernment Authority in their Capacity Building Project.  I was recently in Bahrain and had the privilege of leading a group from this project through the Certified Process Professional program.  I’ve never been more excited about the potential for what can be accomplished with CPP.  Bahrain is already a very nice place to live, and this group is committed to making it a superior experience for the citizens who rely on them for services.  I saw what they can do and the rest of the world should watch and take notice.

Most organizations are confronted with a daily ritual of problem solving.  From the C Level to the shop floor, we all experience our regular daily allowance of “ah crap” or something along that order.  It can be everything from minor nuisances to outright onslaughts. Solving problems every day comes with the territory and is often the reason we make those “big bucks.” Yes, a chuckle may be in order there.

Yet even when we are very good at organizational problem solving, it can lead us into a way of thinking which actually serves to do more harm than the intended good.  It affects our thinking, behaviors and decisions in subtle yet inherently destructive ways.  We need to become aware of this problem and its detrimental affect on our businesses; more accurately, its affect on our customers.  It’s called inside-out thinking.  Inside-out thinking in our personal lives is called myopia.  It’s when our view of the world has closed out any other view but our own; seeing only what serves us and our needs.  

Inside-out thinking is as natural for organizations as it is for human beings because our organizations are really extensions of us as humans.  How do we know when we are inside-out?  It’s actually not that hard and usually expressed in our talk.  Here is what inside-out thinking sounds like:

·    “Our customers do not appreciate what we do for them.”

·    “People are crazy if they don’t love our stuff.”

·    “Customers want the whole world and for free.”

·    “We have to make a living too.”

·    “This would be a great business if not for the customers.”

It should not be a shock to us that our organizations can become myopic.  However, just as it should be of concern for us as humans to break out of our personal myopia, we should also try to break free of our organizational myopia.  We call this outside-in thinking.

We need to keep in perspective why we are in business.  As the late Peter Drucker explained some time ago, “It is the customer who determines what a business is.”  Customers have problems too.  When we serve to solve a problem or problems for someone or society, it is only then we have a business and we have customers.  Outside of that, we have nothing.  If we are not solving problems for our customers, we are irrelevant.

Therefore, when we get so wrapped up in solving our own problems and lose sight of solving our customer’s problems, we become inside-out.  When solving business problems, the approach needs to be about the customer and not the organization. To achieve sustainable business success we need to keep sight of our customer’s problems and make their lives simpler, easier and more successful.  We need to understand their world and what they are ultimately trying to accomplish so you can see how to help them succeed.  That’s outside-in thinking. 

Take some time right now to reflect on what problems your customers have that you can or could solve.  Are you doing anything that creates more problems for your customers or is causing them frustration?  Then consider what your organization can do to solve those problems and ease that frustration.  Start solving more of your customer’s problems and you will solve more of your own than you can imagine.