Picking the Right Vendor for Your Embedded Analytics Product.

Picking the Right Vendor for Your Embedded Analytics Product.

It's one of the most important decisions you can make when adding analytical capabilities into a product.  And, unfortunately, it's an easy one to get wrong. What platform should you choose?  There are a hundred options these days—each claiming to have what you need.  How do you decide?  Here are three tips...

How Embedded Are Your 'Embedded Analytics'?

Before you start evaluating features or selecting vendors, you need to get a handle on what YOU mean when you ask for analytics in your product. Although it seems simple, it really isn't so straightforward. There are many ways to "embed" analytics in a product and the method you choose can create limitations for your product roadmap and determine the overall user experience for your customers.

Three Ways to Think About (and generate revenue from) your Analytics

A great place to start is by understanding the "Three Faces of Embedded Analytics".  It's a great starting point because this simple concept is directly tied to defining the underlying data you'll need to access and to the ways you might offer your data product to users.  Get it wrong and you can end overlooking some valuable ways to generate revenue. 

The Three Keys to Creating a Money-Making Analytical Product

It happens every time.  Every single time. 

From the moment I meet a customer for that very first session, the clock is ticking. It might be seconds, it might be minutes, it might be hours—but it always happens. They always ask the same question:  "how can I make money with my data?"

The past is our future for information dashboards

Back in the early 1990's, I created one of the first metric dashboards for the telecommunications company I had just joined to help improve business processes.  My goal was simple:  build a web-based dashboard that let management view charts showing the performance of key processes.  Sounds pretty simple, right?  Today it would be, but 20 years ago creating "business intelligence dashboards" was a convoluted process at best.  

Here's what the workflow looked like back then.  First, I created the intranet site that would serve as the holder for the dashboard charts.  It was pure Microsoft FrontPage with a black background, animated GIFs, and crazy colors...

Adventures in Analytics: lessons from the trenches on selecting, implementing, and productizing business intelligence

I had just accepted a new role at a small technology company when an email from my soon-to-be boss changed the direction of my career:

"We've got all this data we've gathered from our application.  We should do something with it, like adding some sort of business intelligence.  Start thinking about what we could do."  

Back then, I had no idea just how little I knew about selecting a business intelligence vendor, getting the system implemented and integrated, and creating an actual product offering based on BI capabilities.

Three years and four analytics implementations later, I know just how naive I was and I've got the scars to prove it.

For me that first BI project was an exciting (if a little nerve-wracking) experience — I had no concept of what was around each corner and which decisions were going to haunt me later.  I've implemented business intelligence into existing products multiple times now and learned quite a bit with each additional project.

I'd like to share the lessons I learned, the best practices, and the worst mistakes.  You'll still make plenty of mistakes with your own project, but you can avoid the pitfalls I encountered by using the techniques that I learned through painful trial and error but which made my implementations successful.

The Quest Begins:  Trying to Find a Vendor

If you do a quick search on Google for "business intelligence tools", you will find 110,000,000 results.  Assuming 10% of those results are for BI tools, that you review two vendors per day, and that you have a team of five people to help in the assessment process — it would take you 30,000 years to complete your selection process.  

This is a problem.

How do you cull through the massive number of BI offerings available today in a reasonable amount of time and without missing key players?  Analysts' reports are your friends...

I started my search by making a list of all the potential players in business intelligence/analytics that were reasonable solutions for our needs (more on that to come).  The problem was that I didn't have access to any Gartner reports and I didn't have the budget to pay $1,995 for the latest "Magic Quadrant".  What I learned early on is that you can call any of the BI vendors such as GoodData, Birst, Tableau, or Alteryx and they will give you a copy of the latest Gartner report with little convincing.  I called one of the vendors and explained that I needed to implement a white-labeled BI solution inside an existing web-based application and I had a copy of the latest Magic Quadrant report in my email within the hour.  In fact, many of the vendors now allow you to get a copy of the report from their Web site after filling out a quick form.  The only caveat is that it's often a truncated version only highlighting features of their product.  Call a vendor and ask for the full report.  

Why do you care about the full report?  Because it has a comprehensive listing of all the vendors your should be reviewing — it becomes your master list from which to start narrowing down solution candidates.  But how do you know who to include and exclude from your search?  Even the Gartner report has too many options for you to fully demo each application.  Start by defining your goals and personas.

Who Will Be Using This and Why?

One of the mistake I made was that I didn't frame our goals crisply.  We had started early on by listing project goals so we knew that:

  • We wanted to offer BI as part of our core product
  • It had to be embedded in an existing software-as-a-service application and maintain the look and feel of our application
  • It had to be easy to install and maintain (we didn't have many Engineering resources available to help in the implementation)
  • We had to be able to control costs as the application grew
  • It had to have a great user experience — both for us creating dashboards and for the end user consuming the analytics

I thought I had a good handle on exactly what we needed.  I didn't.  Basic project goals are necessary, but not sufficient for BI implementation.

The second time I implemented analytics, I corrected a major oversight from project #1.  I created personas describing exactly who would be using the system.  By persona, I don't mean a marketing persona: "35-45 year old male who lives in San Diego and an enjoys the soulful sounds of the Backstreet Boys."  I mean a user experience persona that describes the user you are serving and the problems that keep them up at night.

It is important to fully define these personas because your BI application will likely have a wide-range of users — from tactical users to executive-level strategic users.  I overlooked this step during the first project and I ended up co-mingling tactical and strategic charts and graphs on the same dashboards.  As a result, I ended up creating pages that didn't quite fit any one user type well.  Charts that made sense for a front-line manager were useless to the COO.  The second time around, we had a workshop and defined the personas that would use our system such as:

  • Chief Marketing Officer
  • Sales manager
  • Head of Customer Advocacy

For each of these personas, we then created a quick persona brief, an example of which is shown below.

The purpose of the brief was to get us thinking about the users that needed to be served by each dashboard we would create.  We still ended up with a mix of tactical and strategic roles, but on the second project we realized this and separated the charts more logically into different role-based pages.

I recommend that you start your process of vendor selection by making a list of the project goals and then move on to thinking about the specific users whose lives you are trying to improve through the use of analytics.  

Is There a Company Out There That Doesn't Sell Analytical Tools?

At this point in the implementation process you will have three key pieces of information:  a long list of vendors from whom to choose, a list of your project goals, and a list of personas that you need to serve.

The next step is to eliminate those vendors whose products don't align with the needs of your users.  For example, we quickly eliminated several "Traditional BI" vendors because although they had well-established products, they couldn't operate embedded into our web-based application.  One strike — you're out.  From the twenty initial vendors we started with (selected via the Gartner report), we narrowed the list to seven potential solutions by eliminating those couldn't fit with our operating model.  We continued our narrowing process by evaluating the remaining candidates against a combination of factors.

To simplify the process, I created a matrix of both objective and subjective criteria.  I listed the project goals as criteria, but also added items such as "ease of working with the vendor".  Do not overlook the subjective criteria.  While meeting the basic technical requirements is critical, it's the subjective stuff that will make your life either fun or hellish over the next few months.  

For example, during the initial discussion with a particular vendor, the salesperson told our he'd of Engineering that he should go back and read the product specs webpage so that he'd be able to ask better questions on the next call.  That incident gave us a hint into what we might expect working with the vendor's team and factored heavily into our "ease of doing business" category.  And there wasn't another call.  

Here's a sample of the matrix we used (vendor names sanitized to protect the guilty):

This wasn't the only mechanism we used to evaluate the vendors.  For each candidate, I prepared a one-pager that covered items such as:

  • Years in business 
  • Size of the vendor
  • Number of implementations to date
  • Number of embedded or "Powered by" type implementations
  • Cost of year 1 (setup plus service fees)
  • Cost years 2-5 (mostly the on-going service fees)
  • Cost of professional services for implementation 
  • Support ecosystem (did they provide training, marketing support, etc.)

We combined all of these factors into our evaluation and selected three business intelligence vendors to perform proof-of-concept trials.

"Our Pricing Is Based on Several Random Factors Designed to Make Comparison Impossible..."

One item I didn't anticipate when starting the BI journey was how different the pricing models would be from vendor to vendor.  The schemes I encountered included:

  • Pay per user
  • Pay per server/CPU
  • Pay based on volume of data
  • Pay a percentage of your product's base cost to the BI vendor 
  • Pay a straight annual fee and pay for services

The incredible disparity in the pricing models created huge headaches for me and made it tough to compare pricing across systems.  I solved the problem by calculating the cost of implementation through the end of year one, and then the cost of each year past year one.  A key here was establishing the project assumptions based on the goals and personas.  Our assumptions on that first project included:

  • 20 million rows of data (we could control this number to limit our potential cost)
  • 1 refresh of the data per day
  • Professional services to help determine what data we needed, built the loading processes, create the initial charts, and teach us how to use the system
  • Two changes to the underlying data model per year

Using this information, I went back to each of the seven finalists and asked them to calculate the costs for the first five years.  If you use this approach — making the sales team do the costing for you — you'll save a lot of time.  

With all the permutations for pricing that exist, I can't overstate how vital it is that your selected vendor's pricing model matches your intended product offering model.  If you get it wrong, you can limit the potential ways in which you can offer the product to your users.  As an example, we wanted to include basic BI for all existing customer accounts, all users, but with limited data.  If we had chosen a vendor that based pricing on the number of users, we'd be in the position of either reducing margin as more people used the system or tying to limit the total users per account.  This was the opposite of what we wanted to achieve — we wanted everyone using the system and getting hooked!

As a result, the vendors that based pricing on user counts were eliminated.  Our product also had a very thin profit margin and we eliminated the vendor who wanted a percentage of our revenue from further consideration.

You Talk a Good Game, Now it's Time to Show Us

It was down to three vendors and time to see the applications in action using our data and our desired charts.

The proof of concept (POC) trials were designed to mimic what we might see in a production situation — similar data, similar charts — just less data and no integration.  We wanted to see how fast each vendor could get up and running with our data as well as how quickly they would respond to changes to the requirements and the little challenges that always pop up in a complex project.  The vendor that we eventually chose was able to perform not one, but three separate trials for us faster and with less stress than the second place vendor was able to get anything up and running. 

As an added bonus, the POC also allowed us to "test" the personalities of the implementation team.  We would be working with these people for the next 90 days — this was a great chance for a preview.  If a problem came up on a Friday evening when the demo for CEO was on Monday morning, would they be willing and able to help?  Would they quickly pick-up on our business challenges or would we need to explain our company's business model repeatedly?  The answers to these questions were as valuable as the technical aspects of the POC and factored heavily into our final decision.  We ended up choosing the vendor that had great capabilities, a great team, moved quickly, and felt more like a partner than a vendor.  But now, we needed to negotiate the deal.

Send in the Lawyers

The work on the contract details was perhaps some of the most enjoyable, fulfilling time of my life.  I look back on those hours and days fondly...  

Oh wait, sorry, it was the most grueling, exhausting portion of the project.  Not because of the lawyers (they were delightful people who just happened to enjoy hour-long conversations about mutual indemnification) but because of me and what I overlooked.

Here's where I made another major mistake in the first project — I got the legal and finance teams involved way too late.  We'd already conducted the POC and had picked the vendor that we thought would be best for our product.  We'd even settled on the pricing both for the product and implementation services.  We're done, right?  No.  Wrong.  It's details time.

As soon as the legal and finance teams became involved in the project, a couple of things became clear.  First, I would need to spend significant time reviewing the project with them, explaining the business purpose, explaining our selection process, discussing security, etc.  We even had extensive discussions about why we were buying a solution instead of building our own (hint: building is always more expensive and time-consuming).  It was frustrating and took a significant amount of time. 

I should have gotten these teams involved from day one so they could understand our decisions as we made them.  My fault, lesson learned.

The second thing that became very obvious very quickly was how many little details I missed. Here are some of the items that I now know are essential to address early:

  • Contracts with existing customers — you'll need to change the terms so that they understand that data will be handled/processed by a third party (the BI vendor)
  • Right to audit security.  Do your customers have the right to view security audit documents provided by your BI vendor?
  • Service-Level Agreements:  Does the BI vendor's contractually obligated uptime match what you are promising to your users today?
  • Professional service budget —  what happens if you don't use all the money?  Can it be used for other projects?
  • How do you define a "project"?  Is the BI tool only to be used for a single application or can it used to power another effort such as your internal metrics?
  • What happens if the vendor decides not to review the contract after the term expires? How much time do you have to implement a new solution?
  • When does the meter start running on pricing?  Do you pay for the BI system while it's still in development or only after sign-off is complete?
  • Intellectual property:  Where does the vendor's application end and yours begin?

There are many more finance/legal issues that I've learned need early resolution, but these are the ones most deeply seared into my psyche for the future.

Wait, You Mean We Still Need to Implement This Thing?

Vendor chosen, contract signed — it's time to get going!

And...  wait.  What are we building again?  Yet another of the mistakes from the first project that I corrected in project #2 was a failure to have a good understanding of exactly what we wanted to show our users.  Having the persona developed for the second project helped, but so did having a complete "dictionary" of the charts, metrics, and dimensions we needed.

For the first project, we burned through a significant part of our services budget just trying to get a handle on what kinds of questions we needed to answer, what data those answers required, and where that data was located.  For the second project, we got a little smarter.  The first thing we handed the vendor's project team was a spreadsheet with the following for each analytic to be displayed:

  • A sample of the chart you want to show (e.g. a bar chart with dual axes)
  • A list of the metrics required by the chart (e.g. net revenue, customer count)
  • A definition of each calculation required (e.g. uplift = current month performance - baseline performance, baseline performance = rolling 12-month mean)
  •  The dimensions required (e.g. by year, quarter, month, day, region, product, team, etc.)
  • The next level of drill-down (e.g. click the bar for the month to see the specific items that make up that month's performance)

It doesn't have to be pretty, but providing a simple dictionary of charts, matrices, definitions, and dimensions will accelerate the initial phases of implementation and save you money along the way.

Qualtity Assurance is Key

I'll never forget sitting at a meeting with our CEO where we revealed the results of our hard work from the past month.  One of his first comments was "why does this chart say the cost of this type of repair was $27 million?  Our whole budget is less than $20 million.  This can't be right."

Oops.  We hadn't performed quality assurance (QA) to the level we should have in that first project.  Although we spent hours reviewing charts, testing performance, and tweaking colors and layout — we had missed an issue with the data we were providing the vendor.  We had built a process to convert all expenses from local currency to U.S. dollars, and then forgot to change the loading process so that it used the new converted data.  Rubles mixed with Yen mixed with Pesos.  We never noticed it, but the CEO sure did.  With business intelligence you've got one chance to get it right.  Show someone data that they know is inaccurate and you'll have a hard time getting them to trust the system ever again.

The second time around I made sure this wouldn't happen again.  At the start of the project I formed a small team of people with expertise in various parts of the business to review each and every chart and make sure it made sense.  We provided the team with a copy of the same data we provided the vendor for the POC and had them run the same calculations manually.  No silly calculation errors this time around.  Again, lesson learned.  The hard way.

All That Other Stuff...

We made it through that first implementation successfully and in less than 6 months.  The second, third and fourth implementations took less time and were equally successful.  But, some things took far longer than others and I recommend that you start on these tasks early on in your project.  

  • Product tiers:  Do you have levels of BI such as basic, plus, and pro?  What are the differences?  How are these priced?
  • Sales training:  You need to get the Sales team up to speed so that they can sell your new BI functionality.  How will perform both initial and on-going training?
  • Support processes:  How does a problem get initiated, triaged, and handed to the right party for resolution?  How do you define what gets handled by the BI team vs. what is handled by your team?
  • Customization:  If a customer wants a completely customized dashboard, are you willing to do it?  How will you price it?  How will you handle support for that unique instance?
  • Marketing:  You might need new logos, sales collateral, press releases, etc.

As I performed each implementation project, I kept a running record of all the details that could be easily overlooked.  Below is a sample of the mind-map I use:

Pulling It All Together

Analytics are hot, they are addictive, and they sell products.  But implementing business intelligence isn't a simple 1-2-3 type process.  You can learn as you go as I did, but it's easier if you know where the trouble spots may lie and how to avoid them.  I've wrapped up the steps I followed (during the fourth implementation, not the first!) into a flowchart that shows the steps you need to consider.  They don't all have to be done in this exact sequence, but it will give you a sense of the basic process.  

Pick a good vendor, understand your users, start on the little details early, and don't forget QA and you'll get your project successfully implemented and look like a rockstar.

Good luck with your project!

The Future of Analytics is All About Action

Back in 1994, I was a fresh young manager at MCI assigned to help the mid-atlantic region better understand and improve performance.  Armed with a computer and—for the first time—a direct, non-dialup connection to this new thing called "the internet,” I started thinking...  I was seeing all of these web sites (well, a couple dozen at that time) published by companies to display their product information; could we use our nascent intranet to publish our performance data internally?

The answer was "yes, sort of".  With Microsoft FrontPage loaded on my speedy Intel 386-based machine, I designed some truly horrific performance dashboards.  Black backgrounds, awful logos, lightning bolts—if it was a bad early 90's web cliche, it was on our intranet site.  But, the fact was that we had a performance management dashboard complete with statistical process control chart images show performance, patterns, and root causes for our key metrics.  As ugly as it was, it was one of the first intranet sites at MCI and certainly the first dashboard of process performance data.

The problem with our setup was twofold: first, we had to collect all of the data manually (it usually took weeks) and second, we had to create all of the analytical elements (charts, tables) as images and then import them into the website.  The days of easily accessible data and business intelligence tools were still quite far off.  But still, as primitive as our system was, it was a game-changer for performance management and analytics in our organization.  For the first time, we could all see our performance in a single, common location.

I remembered this experience when I read an article that asked "are dashboards the next game-changer" and it made me think:  are they?  Are "dashboards" the next game-changer for businesses?

My opinion is that no, information dashboards in and of themselves are not the next game changer.  Which leads to the next logical question — what is the next game changer for performance management analytics?  To help see where I believe we need to go, let's take a quick look at where business analytics have been up until this point...

The first wave

The first wave of dashboards was characterized by simply having such a thing as a "dashboard" on the web.  Where before executives had relied on MS Excel spreadsheets generated on a daily, weekly, or monthly basis by a team of reporting analysts, those executives could now access that information via a machine interface. I say a "machine" interface, because it wasn't necessarily even a web-based dashboard. Frequently these first wave dashboards were standalone reporting applications that required the executive to login to the app to view the data (or more likely, they had a member of their staff login and print out the report for them to view offline). 
A major issue with first wave dashboards was that there was a lack of available, meaningful data. I remember spending countless hours trying to figure out (a) where the information we needed lived and (b) how in the world could we get it out?  The horrible, horrible term "screen scraping" was used and used frequently. If you could find the data, if you could get the data out, then you were still faced with getting the data into your dashboard system, creating meaningful analytics, and repeating every week or [cringe] day. These were not the "good old days.”  They were the living with old, hard to reach, hard to manipulate data days.

The second wave

The second wave, characterized by data access, made life far easier for most people who worked regularly building dashboards and analytics. Back-office business applications began providing import/export functionality or—better still—APIs that allowed for easy access to the data. Now you could extract data in a real-time or near real-time basis. The era of day or week long information lags was quickly disappearing. 

The dashboard in tools themselves also took a huge leap forward. Systems like GoodData, QlikView, Birst and JasperSoft allowed average users to build sophisticated dashboards that could answer many of the questions posed by the business and their analytics could be modified quickly as the business needs evolved.  Don’t like the barchart?  How about a line chart?  Let’s throw a trend line on that.  This was an immense leap forward, but was still lacking what management users really required. These dashboards were still very much "read-only" systems—they displayed analytics to the user, but didn't give you any sense of what to do with the data being visualized.

The third wave

And that brings us up to today...  These days, getting our information via the internet is second nature.  It's a pretty rarely occurrence in 2014 when we can't find the information we need via a quick Google search.  We also have (or are getting close to) easy access to performance data—lots and lots of data.  These two factors have made the dream of being able to combine disparate data sources into a single, easily-accessible business dashboard a reality.  Today we can build dashboards that let us explore KPIs for customer satisfaction, operational efficiency, and sales funnel value all in a single, real-time portal.  

And it's mostly useless.

Why?  Because we haven't quite crested what I call the "third wave" of analytical dashboards—turning insight into action.  

It's amazing that we can now access all of this information in real-time and drill down, drill over, chart, trend, and predict what is going on with our business, but really, this isn't the ultimate goal for analytical tools.  The pinnacle of these systems is helping us to answer the question "so what?" This is the third wave.

What we need from the next generation of analytical systems is the ability to do the following:

  1. show a chart
  2. find any patterns
  3. highlight the patterns
  4. let us annotate the pattern with a root cause
  5. show u the effective potential solutions for root cause problems
  6. feed the results of our chosen solution back into the system
  7. repeat, repeat, repeat

The third wave for business analytics isn't a feature or more data—it's an analytical workflow that takes the knowledge gained from the huge volumes of available data and which helps you determine the most effective solution to improve performance. It’s about turning insights into action.

I predict that future, successful analytical tools will help users to not only visualize the data, but to pick out meaningful patterns (outliers, cycles, etc.).  They will allow the user to annotate these patterns with the root causes of the pattern (snow in the mid-west, new employees trained that day, quarter close, etc.).  They will present management with possible actions that can be taken when they see such a pattern—actions based on the performance gains that might be expected based on what's observed in the past (in short, the BI system has a memory of what you've tried before).  And they will mark the point in time when you implemented a performance fix so that you can correlate the actions taken to future improvement.

The third wave isn't yet here, but it's coming.  We've got all the tools at our disposal, the dashboards, the data, the commuting power...  Now we need to combine these with the realization that without action, the insight provided by analytical tools isn't much more that eye candy.  Let's stop building charts and graphs that look great, but leave us asking "so what?"  Let's start building systems that take all the way from "wow—I didn't realize that" to "here's what we're going to do about it."  That's the third wave of analytical tools for business.  It's about turning insight into action and allowing us to use the data and tools at our disposal to make the most effective decisions possible.  

User Experience at Disneyland: Learning from the best

Last year, we took our kids to DisneyLand.  As someone interested in User Experience, I was just about as eager to go as the kids — after all, who does UX better than Disney?

Overall, it was a great time.  We had what I'd imagine to be the quintessential Disney experience…  The kids loved it, we survived, wallets were emptied.  However, all is not perfect in mouse land.  What I found surprised me a little bit.  After hearing about how "everyone is a cast member" and the amazing lengths Disney takes to project their ideal image, I saw things that surprised me.

At the hotel, the Grand Californian, we had a great check-in experience.  Very well-organized and clearly designed to move large numbers of people through the check-in process as efficiently as possible.  But they also too this efficiency a bit too far in one instance.  

On the first morning of our trip, we came back to our room between breakfast and braving the line in the actual park.  Walking down the narrow halls of the hotel, I saw basket after basket of linens and towels sitting on the ground next to hotel doors.  Clearly this is and efficient method for servicing the rooms — person A quickly drops off all linens, person B cleans the room without having to maneuver a cart around.  Here's the problem, the same narrow halls that might make it problematic for housekeeping to move a cart through the halls also make it tough for guest to navigate two small kids (plus backpacks, etc) through the hall.  It also breaks the whole "National Parks lodge" feeling that they are trying to replicate and makes it feel more like an assembly line.  I don't have a great answer for this one, but to me it felt like Disney chose to sacrifice customer experience for efficiency.  A valid choice, but maybe not one I would have made.

A bit later, as we were nearing the front of one of the countless lines, I got the inevitable "I need to use the bathroom" from one of my children.  Out of the line, off to the bathroom we go.  We used the facilities and were preparing to wash our hands when something odd struck me…  At a place where it's really all about the kids, where each experience is carefully crafted, where everything is considered — the washbasins were set too far back in the counters for a four-year old to reach them without being lifted up.  The adults had no problems but the kids?  They were out of luck.  Sure, it's a minor inconvenience in the overall scheme of things but compare this to the experience at some store like Whole Foods.  

At our local Whole Foods, the counters are the same height and the sinks are set back at a normal distance, but they have placed a small retractable step underneath each counter.  Pull it down with your foot, the child steps up, uses the sink, steps down, and the step retracts.  Brilliant.  This is what I would have expected to see at Disney more so than a grocery store.  The Disney situation felt like it was designed, though I'm sure with great care, by an adult using an adult perspective.  If that adult had considered the problem from the perspective of a small child, I'm sure they would have seen and addressed the issue.  But they didn't.

Food time…  What are you going to do?  Leave the park and try to find reasonably priced food somewhere in Anaheim?  No.  You're going to find food in the park, pay quite a bit for it.  And be happy about it.  So at lunchtime we sought out and found a deli-type restaurant that looked pretty good (and honestly, the prices weren't too bad and the food wasn't horrible) and made our selections.  Here's where the user experience broke down again.  Many — not all but many — of the employees (sorry, cast members) in the restaurant seemed really annoyed to be serving customers.  No smiles, no "how can I help you's", just emotionless slapping of orders on plates.  I know that they serve many, many people each day.  I know that this is not a job I would want (or could probably even do very well), but this isn't Bob's House-O-Meat.  This is DISNEY.  You are a "cast member."  The simple lack of a smile and basic friendliness caused the entire Disney cloud of magic to dissipate for that 45 minutes in the restaurant.  Probably not what Disney had intended.

We had a great time.  The kids loved it, we loved it, and we'll likely go back some day.  But it struck me how easily the UX veil can be pierced by a few small items that may have been simply overlooked.  It struck me that large amounts of time and money devoted to a UX effort can be undone quickly and easily.  Sometimes it's the little things that make all the difference.

Get Agile: Applying the Lessons from Software Development to Business Process Design

Have you heard the news?  

"60% of all software development projects fail to meet their goals."  

Of course you've heard this.  EVERYONE has heard this nugget of wisdom.  It starts off presentations, it's used in consulting pitches, software integrators put it in their marketing materials, and IT departments promise it won't happen to them (or you).  Here's the problem:  it's probably wrong.  I believe that, in fact,  closer to 80% of enterprise software development projects fail to meet goals.  The key is — it is a specific type of software project that nearly always fails.  The type of development project that nearly always fails is the "old school" waterfall-type project.  The kind that starts out with requirements crafted in excruciating detail, progresses to multiple layers of sign-off, is developed in several phases — each with their own system, unit, and user acceptance testing — and eventually finishes with a final result that doesn't fit the needs of a business that has long since moved on.  Over the years I've seen software that was released that no longer fits an evolved business model, software that missed huge, key requirements, and software that was released just in time for an acquisition that changed the entire business environment.

Whew.  I'm frustrated just thinking about it.  Luckily, the software development industry (mostly) figured out that this was a problem quite while ago.  Most successful projects today — especially externally facing consumer projects — follow a very different trajectory than the development projects of ten or even five years ago, emphasizing tighter contact with the customer, faster development cycles, and the testing of smaller chunks of code.

So what does this have to do with business process design?  

Unfortunately, many business process redesign efforts make those old-school enterprise software projects look like Olympic champions by comparison.  Unlike their software development counterparts, most practitioners of "process redesign" have not been so eager to bring their methods into the 21st century.  In fact, while software design is largely light-years beyond where it was in the early 1990s, process design — for the most part — has changed very little.  The practices learned many years ago a largely still followed:

  1. Document the old process in mind-numbing detail (about two weeks' worth of time)
  2. Identify the issues in the old process (a week here)
  3. Design phases for a new process (another week)
  4. Design the details for the new process (easily four weeks)
  5. Implement the whole thing as one giant project (I don't even want to guess...)
  6. Hope it works (and that the design is still relevant after so much time has passed)

And surprise, like the outmoded techniques for software design, the process design projects conducted in this manner also have an extremely high "failed to achieve results" rate — even worse than for IT projects in my experience.  I speak from experience — this is exactly the way we used to perform process redesign work in the past.  Redesigning a process using this "technique" was tedious and frustrating, both for us and for our clients.  And, it was tough to achieve the desired result.

But it doesn't have to be this way. 

Process redesign projects don't have to be lumbering, slow, painful exercises that rarely succeed in achieving their goals.  By learning the hard-won lessons of software developers, you can dramatically increase your chances for success in your process redesign project.  

When software development moved past traditional waterfall-style development, a new way of thinking emerged called "Agile Development."  Agile development stresses speed over perfection, rapid development of small bits of functionality, and testing of all deployed code.  How can this be used for business process improvement?  Here are three of the main "agile" concepts and how you can use them to improve processes more rapidly and with a much higher success rate:

Lesson #1:  Minimum Viable Process (MVP)

One of my favorite phrases is "the perfect is the enemy of the good," and nowhere is this more true in the design of business processes.  In the past, businesses undergoing process redesign — whether they called it TQM, BPR, or Six Sigma — all made a similar mistake.  They took far too long to develop the process, hoping for a "perfect" final design that met all objectives and avoided all constraints.  As someone who has fallen prey to this seductive path myself, I can tell you with 100% certainty that there is no "perfect process" waiting around the corner, there is no "magic bullet," there is no single "correct solution."  The process that is actually deployed and is actually in use is almost always better than that "perfect" process that exists only on a Visio diagram hanging on the wall.  Business needs and goals change so quickly these days that you simply cannot afford to spend months designing the ultimate business process.  By taking an extended period of time to develop our business processes, we risk a final product that was "perfect" for the situation that existed several months ago — but useless in today's environment. 

So how do we reconcile the need to improve processes with the need to move quickly and get something that improves the situation up and running?  One solution is called the "minimum viable process" or MVP.  The concept is simple: design the simplest, most basic process that will get the job done and iterate from there.  Ok...  So what does THAT mean?  It means that you dispose of just about everything that isn't directly related to delivering the output of the process until you can prove that without the pieces that are left, the process simply cannot function.  It means that you design the process without the multiple re-work, validation, approval, and wait state loops that dominate most processes today.  Treat each process checkpoint or approval state as a design failure — a process step that exists only because the process itself is inherently flawed in even needing a checkpoint — and try to design that step away.  Obviously you won't be able to eliminate every single check & balance step in your process, but minimize them and see what happens.  The key with the MVP design is that you need to get a new process out, up, and running as quickly as possible to test its performance in the real world.  Those super-complex, "perfect" processes will need to reach the real-world stage at some point — wouldn't you rather have spent two-thirds less time in process design when you find out that your process has major flaws that must be corrected?  Use the MVP as your initial test platform to challenge your assumptions and ideas about the new way of doing work.  Then, use the next concept — Continuous Deployment — to make the process better fit the goals of the business.

Lesson #2:  Continuous Development & Deployment

ANY process that you design — whether you spend days, weeks, or months building it — will have problems.  You can count on it.  I've designed and implemented many new processes over the past 15 or so years, and I have yet to see a single process that, once "in the wild," didn't have to change to some degree.  With this being the situation, the key to a successful process design implementation is the pace at which you are able to effectively change the process design in response to the issues that you identify.  Often, organizations take an "implement once and forget it" approach and unfortunately this results in an overall poor redesign result (part of that 60%).  You have to find the process flaws and fix them quickly.

So how do you remedy this situation, recognize issues with processes and make changes that will better meet the design goals?  The best practice for this is called "continuous deployment" and has grown in popularity in the software development community over the past few years. Here's how it works in the software world: 

  1. you work closely with the "customer" to understand and build the software
  2. you release the software in little "chunks" of functionality
  3. you observe and fix
  4. you release again  

 This all happens very quickly. In fact, one of the leading advocates of continuous deployment, Eric Ries, talks about how his company would deploy commercial software to the customer base multiple times per day.  He stated that if each engineer didn't deploy at least every few days, it meant that something was wrong.  You can make the same continuous development & deployment principle work for you when redesigning business processes.  Adopt the philosophy that every day during the design cycle, something, anything, must be "shipped."  It could be a new form for ordering, a prototype of an online database for tracking customer data, or a change to your CRM tool.  The key is that you release constantly and learn from what happens.  Think small frequent changes, not big delayed changes.

By now you might be thinking "Wait — we can't do that.   What if we get it wrong?  We need to perform testing/cost-benefit-analysis/executive review/financial review/legal approval/(insert committee here) review before we do anything.  We could hurt the business."  I don't believe that for a second.  The potential for having a small "release" of a business process change — one that you monitor very closely to observe the results — damaging the business irreparably before you see the problem and release a process fix is very low.  In fact, I would argue that these small process releases are much easier to monitor and problems are far easier to detect that when you perform one massive release at the end of a process redesign.  World-leading design firm IDEO calls the concept of converting risk into smaller, manageable pieces "risk chunking" and uses it to ensure that their new product designs aren't an "all or nothing" proposition.  You want to see risky?  Forklift in a massive process implementation after eight or ten weeks of design work and try to identify the issues (or benefits) that are associated with what you just did. Now THAT'S risky!

Of course, if you release a new process or a process change and then ignore it and move on to the next challenge, you've missed the point.  When performing continuous deployment of process, you must monitor the results.  Did it work?  Did it cause unintended consequences?  The way to tell is through another software technique called "A/B testing."

Lesson #3:  A/B Process Testing

You've created the smallest, leanest process possible, you've implemented it using continuous techniques, now what?  Now you need to test the results.  Often, process implementations are treated almost like a bullet to the head — one shot and it's over.  The software world has taught us nothing if not the need for constant review of the effectiveness of each "release."  Imagine software that was released, had bugs, and was never reviewed or fixed.  How likely would you be to call that software a success or to recommend it to a friend or colleague?  In the software world of agile development, a technique called "A/B testing" or "split testing" is used to determine the implications of a recent release.  

Here's how A/B testing works:  you are doing continuous, small deployments so each piece of functionality is relatively easy to understand in terms of its implication to the users.  When you deploy this small functionality change (the "A" functionality), you deploy it to a sub-set of the users and compare to the users who are still using the old functionality (the "B" functionality).  Think of it like a small, rapid beta test.  This can have huge, beneficial implications for software — think of what would happen if you deployed a new "Buy Now" button to a website but accidentally colored the button the same as the page background.  You now have, as Eric Ries says, "a hobby, not a business model."  Obviously, you would prefer to detect an issue such as this sooner, rater than later.  

Use the A/B testing concept for your business process changes.  Instead of deploying a changed form, website, or process to the entire set of "users," deploy to a smaller set of test users and compare the differences.  Did the new process perform the way you expected?  If so, deploy the change to the rest of the process users.  If not, go back, re-develop that part of the process and re-deploy.  Continuous development and A/B testing are a tightly linked loop of design, development, deployment, testing, and re-development.  Just remember that A/B testing without continuous deployment means that mistakes will be out in the wild much longer than they should and continuous deployment without A/B testing means that issues may go unnoticed for far too long.


We need to break out of that old cycle of developing monolithic processes only to have them fail to produce the results we anticipated.  In an environment where every dollar counts more than ever, we just cannot afford a 60% plus failure rate in process redesign.  It not only costs us time and money, but also credibility with employees.  Use the lessons from software development and build lean, minimum viable processes, deploy them quickly and continuously, and test the results against the old process.  Everything you implement won't be a success, but when a mistake does occur, you will find it quickly and be able to rapidly make the changes necessary to succeed when you implement the next time around.

Outperform: Using a Bad Economy as a Killer Competitive Advantage

Today the news came out that the unemployment rate in the United States reached a 26 year high. Given the bad economic news that we hear nearly every day, it's not surprising that people — and companies — are in a bit of a panic. Nearly every company that I know of is considering layoffs, killing major projects, reorganizing (read: eliminating lines of business), or just plain ceasing operations. Why? Because that's what you do in the face of such a terrifyingly bad economic downturn, right?

Wrong. At least, not if you want to exit the downturn performing better than your competition...

If you look back over time at the great companies such as Google, Microsoft, Johnson & Johnson and many others, they all have one striking characteristic in common. They all started during significant economic downturns. Crazy, huh? Who would ever want to start a business during such a risky, scary time? Someone who sees that every great challenge is also a huge opportunity to solve major problems, to serve undeserved markets, and to create enormous advantages over the competition. Those companies used an economic downturn as a competitive advantage to implement new technologies, tools, and idea while the incumbents were focused solely on survival.

Now is the time — while most companies have shifted into "panic mode" — to think about using the current economic situation as an enormous, once-in-a-lifetime chance to create a killer competitive advantage.

Here are three tips to get you started...


KILLER TIP #1: Hire your competition's best people

What? Wait a second, you're thinking of laying people off, not hiring people. Okay, maybe you need to reduce your workforce, but it's a mistake to do it wholesale and without thinking about the future. If you are laying people off, chance are, so is your competition. And the people they AREN'T laying off are still scared that they are next. It's the perfect time to poach the best and the brightest from your competition. Here's what you do: if you need to perform layoffs — fine. Target those individuals who:

  • are not fitting in to your culture
  • are not performing as they need to be

The third bullet is the real kicker. In a reduced workforce situation, you need to have people who will be the leaders that carry the company into the future once the economy picks up. Not the lowest paid people. Not (necessarily) the ones who have been there the longest. But the best, brightest, and most energetic people who see your vision for the future and can start getting you there today. Look around at the companies that are driving you nuts on a regular basis. Find out who is driving the best product strategy, the best marketing plan, the best sales team. Go hire those people away from your competitor. These people will be the "Pathfinders" that will lead you past the competition and prepare you to dominate once a recovery has taken hold. If you have to layoff additional low performers in order to be able to hire these Pathfinders, do it. This may be the only time when you can get such people without breaking the bank.

KILLER TIP #2: Move to the Cloud

By now you've probably heard of "the cloud." If not, "the cloud" or "cloud computing" simply means that instead of buying (and maintaining) expensive servers, rack space, power, etc — you outsource this infrastructure and get on with your core business instead. Why do this? Because too many companies have enormous IT development or operational support groups focused on providing 24x7 care and feeding of mission critical servers, installation of applications, and other infrastructure maintenance. Is that really your core business? Why, in an environment where every single dollar counts, do you have people dedicated to patching desktop software, designing security models for your intranet systems, and maintaining servers? You'd be better off putting your dollars to work hiring those Pathfinders...

For example, several years ago, I worked at a company where we had a great idea for a new software product. This was before (or at the very beginning of) the "cloud-revolution" so we just used traditional methods for our development. We bought servers, we spent months on the security model, how to issue passwords, how to control access to parts of the application, how to deploy the system to end users, and how to do routine things like backing-up our data. Over the course of a year, we spent nearly $1 million and still didn't have a marketable product. Worse still, the system was so expensive to build, maintain, and deploy that we had to charge "per user" fees that were far too high for the market to bear. As you might expect, that business is now sleeping with the fishes.

Flash forward a few years. I still wanted to build the software. I thought it was a great idea with a great deal of merit and would be worth developing — but not the same way as we did before. I had absolutely no desire to build and maintain the underlying infrastructure. Instead, we used one of the cloud-based "Platform as a Service" systems on the market. This meant that we didn't have to buy any servers, we didn't have to develop a log-in mechanism, we didn't have to design back-up plans — that was all included in the service. We could focus all our efforts on the problem at hand —building the features we wanted to offer instead of worrying about infrastructure. Think of this as traveling from New York to D.C. by car. Do you really want to build the roads, gas stations, and restrooms it will take to get you there? Why not use the facilities that already exist for your convenience? This is what we did with our software and it made a huge difference. Instead of a team of 10, we had a team of — well, me. Instead of a year, it took us (me) three months to build (with more features, thank you very much). Instead of $1 million to build it, it cost a few thousand dollars. We can operate the software for no fixed costs and offer it to users at a very attractive price (and still make a profit). The software is now on the market, is very easy for us to deploy and maintain, and gets great reviews from users (self-promotion alert: it's called NextWave360and we think it's pretty great). If we had tried this WITHOUT using the cloud, we'd probably be answering debt collection calls while building a log-in screen right now...

There are two main ways you can use the cloud to your advantage to save costs: use it internally and use it externally.

Cloud Tip 1: Use the cloud for your internal applications

Between Google, Zoho, Salesforce.com, and the myriad of other cloud-based applications (see EIR #13 here), it's hard to justify putting a standalone copy of a software package on each person's desktop. It's expensive, it gets obsolete quickly, and it's hard to maintain (ever had to reload MS Office?). We switched to GMail for our mail system — free and we still use our same domain namebut we get far more space than we did before.  There's really nothing to "maintain" and we save $50/user.  We use EchoSign for document/contract management, Freshbooks for cloud-based bookkeeping, and our own cloud-based project tool for project management.  We don't even own a web server.

Cloud Tip 2: Use the cloud to develop external applications

As in our software development example above, consider using one of the cloud-based "platform as a service" (referred to as "PaaS") systems to develop any applications that you offer to your customers, either internal or external.  I know, I know...  Your IT guy told you how it wasn't safe, it wouldn't be cost-effective it the long-run, it caused hurricanes, and you couldn't make the interface the proper shade of green (pantone 361).  Sorry, I'm officially calling him out on that.  As long as you pick a PaaS provider that is trustworthy, uses a good data center, does back-ups, and either is stable or escrows the code, you are no more at risk than you are developing on your own servers.  In fact, I would argue that the speed to market, the ease of deployment, the ease of maintenance, and the ability to change the code on a dime if necessary far outweighs the arguments made by the IT traditionalists.  This is the way software will be developed in the future — get out ahead of the curve and save some time and money while you are doing it.  I recommend taking a look at TeamDesk, Cordys Process Factory, and Force.com.

KILLER TIP #3: Blow Up Your Processes

Admit it.  You have been performing your business processes much the same way for a long time now.  Maybe you did some "process improvement" and changed the way you executed a couple of steps last year.  How'd that work out?  I'm guessing it didn't make much of a difference.  Now, in the middle of the economic chaos, is the time to change all that.  

You need to seriously think about "blowing up" your processes.  Before you start surfing the web for demolition supply stores, allow me to explain.  When you are trying to gain efficiencies, reduce costs, and improve service, it can very difficult to make progress through evolutionary or incremental techniques such as traditional process improvement.  Often, all the process "plaque" that has built up over the years gets in the way of making rapid significant improvement — "that's not the way we've always done it" becomes the rallying cry.  If you want to exit the economic downturn better positioned than your competition to take advantage of new opportunities, you cannot afford to either ignore your processes or simple incrementally tweak performance. You need to challenge the way you do everything.

There is a story about a technology CEO who was faced with a stagnating company where costs were too high and effectiveness of their network was too low.  Little progress had been made and something had to be done — the system couldn't continue to operate the way it had in the past and survive.  The CEO met with the team one day and said "I have news to report. The network is gone."  The team looked confused and he further explained, "Go look and see — it's gone. Now figure out what we do.  Rebuild it."

A bit abrupt, but effective.  He essentially had removed the option of minor improvements instead challenging the team to design a solution from the ground up.  Think about what this would mean if you did the same thing with your billing process, your A/P process, your service delivery process.  Think about what it would look like if you were a new start-up business designing the process from the ground up.  Of course, you are likely thinking "we can't do that — it's too expensive.  Now is the time to stick with what we have, not go changing things."  If you want to exit the recession with the same old processes with which you entered, full of plaque, partially effective, then that's the right attitude.  But what if, while your competitors are using the strategy of retrenchment (and as a process consultant, I can tell you — they are...), YOU choose to get really efficient and effective with your processes.  While the economic rising tide may lift all ships, you've lightened and streamlined your ship during the low tide.  It may be counterintuitive, but it is an effective strategy for using slow times to not only reduce inefficient practices now, but also to prepare for the future before your competition.  Fix it now, reap the benefits down the road.

There you have it: three Killer Tips to help you view the economic downturn as a tool, not just as a calamity.  As Warren Buffet is famous for saying, when everyone else is scared, that's when you need to be aggressively investing.  The same holds true for performance improvement.  Everyone out there is scared, struggling, fighting to survive.  By snatching up the best people, using the new technologies available, and by revolutionizing your processes today during this climate, you will be well prepared to outperform your competition in the future.

Surviving the New Economy - Cool Tools to Help You Do More with Less...

It's tough out there.  The poor economic conditions have led to slashed budgets, reduced headcount, and projects getting put on indefinite hold.  The problem is - you still (hopefully) have a business to run.  What do you do if you don't have the budget to support that huge enterprise app?  How do you manage if you need to the same work or more with fewer people?

When you are a small company (like we are) or a big company with shrinking budgets, you have to find creative ways of getting things done.  Here are just a few of the tools that we've found make doing business on a budget much less restrictive...


  • Instead of WebEx - Use "DimDim

We got tired of using WebEx about 3 years ago.  It seemed to take forever to get everyone online viewing the screen ("Can you see it now?  How about now?  Now?) and on top of that, we got to pay a small fortune for the privilege of the frustration.  BUT - we still need to share screens and presentations with clients...  Enter "DimDim."  Dumb name, excellent application.  Like WebEx, DimDim allows you to share screens, presentations, web pages, have white boards, etc.  Unlike WebEx, it doesn't require users to download an application - it's a small java applet that runs when you access the meeting.  Best of all - DimDim is FREE for up to 20 people in a meeting.  Beyond 20, you can get a "Pro" or "Enterprise" account for about 10% of the cost of WebEx, but honestly, we've never seen the need.    DimDim Web Meetings.  (Highly Recommended.)

We work with clients all the time who have paper contracts that need to get printed, passed around, signed, then stored.  It's no wonder trying to find that single signed piece of paper is liking trying to find a needle in a haystack.  We don't use paper - we use EchoSign for all our contracts.  EchoSign is an online document signature system that allows you to upload the document (from Word, Excel, etc...) and send it out for signature.  The recipient gets email notification and can sign (or not sign) the document electronically.  It then gets "filed" electronically in your EchoSign account.  FREE for up to 5 documents at a time, EchoSign has paid versions for larger amounts of storage, more users, unlimited documents, etc.  EchoSign.

  • Instead of: your IT department - Use Coghead

In my opinion, Coghead has the potential to radically change the way in which companies view the IT department.  That's a big claim, but Coghead is a truly amazing system.  Quite simply - Coghead is a "cloud-based" platform that allows you to build any application you want, hosted on the web, for a pretty minimal per user fee.  And - it's extremely easy to use.  Here's what you can do with Coghead:  instead of waiting months for your IT group to search for, buy, and implement a new CRM system - why not build a quick CRM application in Coghead and learn what works and doesn't work so you can provide IT with better requirements.  Instead of using MS Excel or MS Access to track customer orders or inventory - use Coghead to build an online database complete with order forms, reports, and email notification when new items are added.  Coghead doesn't require you to write code or understand programming languages.  Instead, you drag and drop text fields, number fields, labels, etc. on to a Coghead "collection" - a tabbed web page - and arrange things any way you like.  I can easily see how tools like Coghead could transform the central IT department in to the "keepers of the master database" with end-users developing the applications they need - in real time - and change them as quickly as the business changes.  Coghead (Very Highly Recommended)

  • Instead of: Microsoft Exchange - Use Gmail

I know, I know - EVERYONE knows about Gmail, right?  Well - did you know that you can use Gmail with your own domain name (you@yourcompany.com instead of you@gmail.com)?  A recent survey showed that using Gmail at an enterprise level is orders of magnitude less expensive than running your own MS Exchange server.  Gmail for domains has two versions - FREE and $50/year/user.  We use the free version which gives you up to 7GB of mail space per user, a shared calendar system, Google Docs, and Google sites (a good replacement for MS Sharepoint).  The paid version removes a small text "ad" on the webmail page, which you'll never notice if you use MS Outlook or Apple Mail, and which is pretty discrete anyway.  For us, Gmail works really well - all our mail comes from "nextwaveperformance.com" and we have huge amount of storage. Plus - the "dashboard" for adding and managing new users in your account is really easy to use - far better than other systems I've tried.    Gmail for Domains (Highly Recommended)

If you have to make flowcharts, MS Visio is pretty much the standard (unless you use a Mac, then do yourself a favor and get OmniGraffle).  But - that standard comes with a price - about $270 for a single user copy of Visio.  Wouldn't it be great if you could get the ability to build nice, clean flowcharts for, oh... let's say... FREE?  You can.  It's called LucidChart.  LucidChart is an online flowcharter that again comes in two forms - a free account and a paid account.  The paid account removes the LucidChart logo and costs $50/user/year.  It also gives you some interesting collaboration tools that allow multiple people to work on the flowchart online.  It doesn't read or write in Visio format, but if you can live with exporting as a PDF (which you should do anyway), LucidChart should get the job done.   LucidChart (Recommended)

  • Instead of: Microsoft Project - Use OpenProj

Let's get one thing out of the way right now.  I can't stand MS Project.  I think it is one of the worst pieces of software on the market today for reasons too numerous to mention but, many companies still use it.  The problem is, it's pricey and companies generally have only a few people with a copy.  OpenProj is the answer.  OpenProj comes in two flavors - stand-alone and hosted.  The stand-alone version (comparable to using the stand-alone MS Project) is - wait for it... FREE.  That's right - everyone in your company can have a project management application that reads and writes in MS Project format free of charge.  The server-based version - comparable to MS Project Server - is $20/user/month.  This one seems like a no-brainer to me.  Why would you ever pay for MS Project when you can get the same thing at no cost?  OpenProj.  (Recommended)

The Power in the Cloud

As a consultant who specializes in business process improvement, one of the most frustrating aspects of the job is coming back to a client weeks or months later to find out no substantial implementation progress has taken place. We've spent weeks redesigning processes to improve efficiencies only to find out that the flowcharts are sitting on a shelf somewhere gathering dust. When we ask the client "what's happening - why aren't you implementing?" - we get the same answer time and time again - "we've submitted change requests to the IT department and we're still waiting..."

As painful as it is for us - imagine how it must be for the client who hasn't yet realized the benefits from the improved process!

Luckily, a new age is upon us. The days of submitting requests for simple applications to overloaded development teams and hoping/praying that your application is highly prioritized are drawing to a close. The days of IT departments developing applications - only to find they built the wrong thing or key functionality is missing is slowing slipping away.

With the advent of revolutionary shared-infrastructure cloud-computing platforms such as Coghead, the way we interact with clients and the result we are able to achieve are radically different as compared to just one year ago.

In the past we would work side-by-side with our clients to develop a new business process and then leave hoping for a successful implementation later, now we prototype everything. We develop the process first, then sit right there with our clients and develop a mock-up - a mock-up that actually works - with the flowchart still hanging on the wall.

For example, last week we met with one of our clients that needed a new method for prioritizing their customers in to various support levels (gold support, silver support, bronze support, etc.) The problem was, the decision was fraught with emotion. The sales team always wanted "premium support" for every customer. The support team wanted to make sure that premium support was only for customers that REQUIRED premium support (and paid for it!). On top of that, once the support-level decision was made - it never got re-visited! Customers who warranted premium support 2 years ago were still receiving premium support today, even though their expenditures with our client had dropped by 50% or more. Something had to be done.

We worked with the client to develop a new set of criteria that we could use to rank the support needs of each client resulting in an overall "support score." Each client was then reviewed, scored and ranked into the appropriate support tier and here's where the magic of cloud computing comes in... Where in the past we would have used MS Excel to create the "ranking list" - for this client, we used Coghead to develop a web-based support scoring system. In a matter of 2 hours, we had a prototype that the client could use to enter client information and obtain an objective, criteria based decision on where clients should be slotted. What's more - since it was cloud-based and accessible via the web, the entire sales team could enter their information real-time AND re-visit the ranking on a periodic basis.

How long something like this have taken just 2 years ago? Maybe weeks, more likely months (and that is assuming that you could get funding approval!). The world has changed - cloud-computing now allows business to develop or change systems as rapidly as their process change to keep up with their customers' and the business's needs. Just remember, with this amazing power comes responsibility. The great positive that is cloud-computing can easily make things worse if you don't think through your processes before you start building a solution.

Are You a Termite or a Squasher?

Are You a Termite or a Squasher?
The Science of Change, Part 2

"Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.”

- General George Patton Jr


The Concept:
I was wandering through the business section of my local book store the other day when I noticed something amazing. Do you realize how many books have written on the subject of leadership? Hundreds of them - and this is just at my local book store. Books that teach the characteristics of a leader, books that discuss the “leadership mentality,” books that use sport analogies, books that use war analogies. Lots and lots of books about what it takes to be a great leader. I guess the thought process is that if you can just learn to be a more effective leader, business performance will improve and the organization will become wildly successful.

It occurred to me, looking at all those hundreds of books, how did we manage to lead successful organizations BEFORE all these books were written? Better yet, how do some of the most successful organizations - ones in which I’m quite sure their “leaders” have never read a single leadership book - manage to thrive under brutally difficult conditions?

In our experience with both very good leaders and very bad, we have witnessed strong evidence indicating that the way to increase organizational performance is not to study and emulate the traits of the great leaders of the world, but rather to study organizations that are highly successfully without even having formal leaders or leadership.

In a previous EIR, we explained how many organizations can be viewed as “Complex Adaptive Systems.” Complex systems have been studied by scientists in the fields of physics, biology, and ecology for years, but recently organizational theorists have begun to apply the science of complexity to business processes and organizational performance. The study of complex systems in nature teaches us quite a bit about how some “organizations” such as termite colonies organize themselves to achieve significant tasks with little or no “leadership” as we traditionally recognize it.

Is There a Termite “Bill Gates” Somewhere?

Let’s take the example of termites in Africa or Australia building a mound for their colony. As you can see from the image to the left [omitted], termite mounds can be rather large. In fact, some of the mounds have been measured at over thirty feet in height. These huge structures actually function as a set of “lungs,” moving air in and out of the termites’ home by harnessing the wind as it moves across the top opening of the mound1. Pretty impressive for such a tiny insect with no human resources organization.

How do termites organize themselves and muster the resources to build such complicated and massive structures? Do they have a single “termite Bill Gates” who locks the termite management team in an off-site room for three days to develop a “vision statement” to be published in the next newsletter? Does termite Bill’s termite management team come up with a “5-point plan” for mound construction each quarter? As far as we know, this is not what happens... Termite mounds are built according to a few simple rules of Complex Adaptive Systems.

First, all of the termites have a built-in set of instinctual rules which each follows. Something along the lines of “if I bump in to too many other termites, I should add a little space to the mound.” Nothing too complicated and certainly not a detailed, multi-page mission statement that has to be memorized by everyone. In this sense, no one “leads” the termites to built their home; each simply adds pieces and parts according to the rule set.

Second, Complex Adaptive Systems theory teaches us that many systems are “emergent” and “non-deterministic” in nature. In simple terms this means that (a) you can’t tell what the end result is going to be just by looking at all the individual pieces and (b) the sum of the parts is greater than the whole. In the termite world, you would never imagine by looking at a single insect that it could produce a thirty-foot tall structure, but when many termites work together the individual, tiny efforts combine to yield a tremendous end result.

Third, termites learn when and where to add to the structure by maintaining a high degree of connectivity to others in the colony. Using various signals left by the others, termites understand where the group is working, when work was done, where repairs need to be made, etc. Without this contact between individuals, each termite would randomly add to the mound and the single, cohesive structure would never emerge.

“Squasher” Management vs. “Termite” Management

Whenever I think of how the termites achieve this engineering marvel, with no leadership, no books, and a few simple rules, I begin to compare their experience to my own in corporate America. While working for a large, Fortune 500 company, I had the unfortunate opportunity to view - up close - two radically different management styles used by two different managers, what I like to call the “squasher” management style and the “termite” management style.

The “Squasher” Management Style:

The first manager was definitely what one would call a “squasher” manager. He strongly believed in a hierarchical chain of command, in one-way communication, and in making all decisions for the organization. At staff meetings, he always sat at the head of the table and delivered a one-way speech to his employees who were then expected to nod their heads and go forth to execute his wishes. Thoughts? Opinions? Options? No thanks - not needed here... Any ideas other than his own were summarily rejected. When we were given news, it tended to be such mission-critical information as “the local chapter of the ‘Telecommunications Pioneers’ have changed their name - they are now the ‘Telecom Pioneers’.” After that one, we quickly learned to find the information and updates required to do our jobs in other places from other managers.

Now, this might seem like a harmless one-time thing, but in fact, it was illustrative of his inability to share even the smallest useful details of the business with his team. In addition, he was unfortunate enough to have inherited many staff who were not used to this type of “centralized,” “squasher” management. As one of those inherited staff used to having ideas and opinions valued, you could feel the spirit, the morale, and the life of the organization die around you. After having ideas ignored a few times, people stopped offering them. Even when people could see major problems with a particular course of action he had selected, they carried it out anyway, knowing that alternatives would not be welcomed. When people were unable to find time on the manager’s calendar to review a particular problem, they simply stopped working the issue on their own - everything had to go through him. Working for a “squasher” manager was not a pleasant place to be and quite a number of highly talented people left in relatively short-order.

The “Termite” Management Style:

In stark contrast to the “squasher” manager was a very different executive with whom I also had the opportunity to work. This manager preferred to delegate many aspects of the business rather than running the daily operations under a microscope. As a result, he happened to turn the group into a little termite mound of his own. We had simple rules (no surprises, own the problem, etc.) that we all knew to follow. We had regular and effective communication that actually informed us about the state of the business. We received constant feedback on what we did right and what we did wrong. Like the termite mound, something wonderful and quite unexpected began to emerge. Our small, 25 person group expanded over time to 250 people. Our purview grew from 40 projects in one small corner of the business to 2000+ projects crossing organizational boundaries and touching every area of the corporation. We expanded our role to take on projects that would have been unthinkable a mere year prior. When the management team was not available, the staff identified issues and implemented solutions on their own. Unlike the “squasher manager,” this manager was not interested in gate-keeping or taking credit for every single idea. He was interested in getting solutions and results from wherever they came - and this meant sharing ideas, information, and workload.

Like the termites, out of the simple rules and de-centralized management, we built success.

Applications for the Executive:

As a business leader, what can you learn from the example of the mound-building termite colony? How can you use the science of Complex Adaptive Systems to make your organization more effective? Here are three techniques that you can use to capitalize upon the de-centralized, leader-independent nature of the Complex Adaptive System:

Instill a mission or purpose
The first key to applying the lessons of complex systems to leading a successful organization is to instill a sense of “mission” in your team. This is NOT the same as writing a lengthy “mission statement” which, quite frankly, we believe to be nearly useless. Instilling a sense of mission means that you must ingrain in your people a purpose, a meaning, goal for which they strive. The best way to do this is through simple, consistent reinforcement of the message, whatever it happens to be. If your goal is to “provide the best project management” to the rest of the company, then every newsletter, every meeting, every all-hands meeting should focus on the stated mission. People must be rewarded and, when necessary, removed from the organization based on their ability to understand, communicate, and “live” the mission of the group. Like termites who have no formal, written plan for building their home, you must make the organizational mission instinctual for your team.

Spot & reinforce emergent patterns
Have you ever noticed how new behaviors, ideas, and ways of operating just seem to emerge? New groups spontaneous form, new methods of reporting can appear out of nowhere, and without formal direction seemingly insignificant systems may gain a life of their own. Sometimes these behaviors are beneficial to the business and sometimes they are not so good. Termites use this “emergence” principle to build bigger and stronger nests by reinforcing sections of the mound that are going in good directions (up and out perhaps) and letting other, less useful sections die off.
As a “termite leader” you need to be extremely sensitive to emerging patterns and trends in your group. If you see things such as an employee developing a new, more effective format for preparing reports or people forming weekly sessions to discuss new technology trends - reinforce and praise the behaviors. If you see things like employees gathering in the smoking area to exchange gossip about other employees - you might want to discourage the behavior. The employees of your organization can be an enormous source of excellent, creative ideas for improvement. Recognize and foster these ideas whenever you see them. The “next great thing” could come from one of these unintended, unplanned emergent ideas, and by paying attention, you will end up at the front of the parade.

Establish “connectedness”
Without frequent, timely, and accurate information about the environment, what has already been built, and the areas which need work, the termite mound will die off. The same holds true for organizations. Just as I experienced with my “squasher” manager, when leaders withhold information about goals, issues, and other business situations, organizations experience a type of death. People begin to feel under-utilized and unimportant, morale sags, and Monster.com gets a surge in traffic.

“Connectedness” however, is not just about making people feel good, it is about improving organizational performance. As employees understand more about the business’s current situation, they are better able to recognize potential issues and possible solutions WITHOUT the need for direct intervention from management. Just as leaders must be able to spot patterns, employees need to as well and communication and “connectedness” is the primary mechanism to allow this to occur.


Using the principles of the Complex Adaptive System and termite techniques does not mean that you no longer need to lead your organization. Rather, it means that you must use a different approach to leadership. In this new approach your primary mission is not to direct every action, but rather to instill purpose, encourage creative behavior, and reinforce communication - key elements that better allow the organization to lead itself.

The corporate world is chock full of squasher managers and employees that have grudgingly learned to live with their fates. They have stopped trying to improve, stopped adding their ideas and opinions, and stopped looking for creative solutions to the myriad of problems they face in their jobs daily. As a result, the organizations in which they work limit opportunities for improvement to only those ideas coming from the management team.

Don’t let your organization wither and die while squasher managers stifle creativity by parsing out information like it is gold or by micro-managing. Try using termite leadership techniques - encourage employees to tap in to their own skills, abilities, and creativity - and you might be surprised at how quickly improvement will come.


About the Author:

Kevin Smith is a co-founder and managing partner at NextWave Performance LLC.

© 2007 NextWave Performance LLC

Shock the System: The Science of Change

Shock the System:  The Science of Change

"There is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order to things." — Niccolò Machiavelli


The Concept:

In the early 90s, fresh out of graduate school, I landed the job of “quality support specialist” at a Fortune 500 technology company. What is a “quality support specialist” you might ask? Good question. A “QSS” was a role designed to support the regional director in improving processes, analyzing process data, and improving overall organizational performance. As a QSS and it being the early 90s, we formed teams. Lots of teams. That’s what we did back then. Teams to analyze customer issues, teams to analyze workflow, teams to work cross-company issues with our business partners. I must have led (they called it “facilitated” – it sounds fancier) 20 or more teams in the two years I was in the role. Guess how many of these teams’ efforts led to lasting, meaningful performance improvement? I’m embarrassed to admit, not very many.

As someone who works in the “performance improvement” field, this is obviously more than a little frustrating. You spend significant time on these change management activities, and yet very little actually “sticks” and produces long-term results. After a few annoyed managers, a couple of aggravated team leaders, and team members who tremble and run when they hear the word “process,” you start to wonder: “why doesn’t this work?”

Later on in my career, as we have related in previous EIR’s, we DID achieve true improvement in a substantial-sized organization by introducing radical change, reinforcing that change with “guiding principles,” and communicating the results back to those in the organization. To this day, I’m not quite sure how we hit upon this winning combination – possibly it was our immense, unparalleled, big-brained genius for leadership, but more likely it was a combination of intuition and dumb luck. I don’t know – somehow it just worked – but I still wanted to know why it worked and how to make it happen every time…

Well, I didn’t find the answer in one of those “business-theory-of-the-month-club” books that everyone seems to rave about. I found it in two places – my own leadership experience and, of all places, the world of physics… The juxtaposition of these two unlikely partners led to a result that I had seldom seen in the process world – tangible, lasting performance improvement.

Here’s what happened: A few years after the QSS job, while browsing in a book store, I happened to pick up a book on how new theories in physics are changing our view of how things at all levels behave and interact. Among other things, the book illustrated a concept used in physics, biology, and other disciplines called “complex adaptive systems.” To keep it simple, in studying various systems – whether flocks of birds migrating south for the winter or African termites building a massive, complex mound – scientists have discovered some simple, key rules for how systems must behave in order to be highly successful. All complex systems follow the rules and all complex systems survive or perish based on how well they can adapt to their surroundings while complying with the rules.

As I was reading the rules, I kept thinking, “this is exactly what we did! This is what made our process changes stick! We focused on the ‘rules’ that drove our organization!” Through some combination of luck and intuition, we had witnessed the beneficial effects of the complex adaptive system principles in our own organization’s performance.

So then – what are these principles or rules that govern complex adaptive systems? How can the lessons of flocks birds and colonies of termites be applied to a human business organization and its processes?

The first rule of complex systems is to “shock the system.” In order to affect change in a system, you must create some sort of event that forces it to react and behave differently. Shocking the system is a notification that the old way of doing things is history and the new way is the only option. For flocks of birds, the shock may be the cold of the approaching winter. For termites, it may be floodwaters or predators causing them to seek higher ground. For business processes, the shock may be forced upon you (bankruptcy, major shifts in market forces, etc.) or you may need to create a shock that precipitates a desired change.

Inherently, most organizations simply do not want to change – they even have built-in mechanisms – methods, procedures, approval chains, sign-off requirements, etc – to slow the rate of change. This is not always a bad thing, but it does make planned change more difficult. In order to create lasting change, you must overcome the built-in factors that actively resist changes. You have probably experienced this firsthand in your organization. Let’s say you decide to implement a new web-based application for tracking projects in your business. What happens? Do people pick up the idea and begin using it as the new method for reporting, or do they mostly revert back to the old way of doing things? In our experience, the majority of people will resist change – even change for the better – and cling to that with which they are familiar. Science tells us that this is not only common, but it is a trait of all complex systems. Organizational systems have a build-in resistance to change - a natural desire to stay at a “stable” state, so don’t take it too personally when new ideas and improvements don’t get rapidly accepted.

Applications for the Executive:

Okay – so science tells us that complex systems – such as any business or organization - are naturally reluctant to change. However, in order to stay competitive, we have to change. How can we “shock the system” and ensure that process and performance improvements get implemented and not simply pushed aside? Here are the three steps to create a systemic shock that can help ensure successful change:

1.  Float the new ship

    The first step is to implement the change. The key here is communication – the more people know, the more they are “connected” to the change, the more likely you are to succeed. Changes die when they are not communicated to any but a select few. We are big fans of “beta testing” your changes to a small group, but the key is to get the body of the organization on board as quickly as possible. Organizational systems change only when they reach a “critical mass” of people that act or believe in a certain way. If the critical mass is not achieved, the change will die and the organization will revert to the old behaviors. Float your new ship; get as many people as you can on-board, and then…

    2.  Sink the old ship

    Too often, managers will give people an option – accept the change or don’t accept the change. Complex adaptive systems teach us that one of the keys to successful change is the lack of a choice. I experienced this several years ago when the company where I was employed rolled out a new, more efficient, web-based tool for processing orders. The web-based system replaced a 20-year-old “green screen” application that required the users to remember a myriad of order codes and to type orders in a cryptic language that the system could properly interpret. When the management team implemented the new system, they left the old system in place and you guessed it – the employees refused to use the new system. Even after training, for people who had been entering orders the same way for nearly 20 years, the change was downright frightening. Given the choice of the old, inefficient system they knew versus the new, more effective system they didn’t know, they chose the old system every time. The lesson here is simple – don’t allow people to “choose” not to change. Unfortunately, this rarely happens. Time after time we have witnessed companies’ failures to eliminate the choices: managers that create a new “expense report” process, only to continue to accept the old-style of report; IT groups that run an old system and its replacement in parallel for years, and so on.

    Organizations and people like stability. If you are trying to affect a major change, you must “sink the old ship” quickly and decisively after floating the new one.

    3.  Evaluate the survivors

      You have implemented a changed process and eliminated the ability for people to continue to use the old process. The next step is to evaluate who has accepted the change and who has not. Even if you achieved critical mass (you got enough people on the ship) and you eliminated all options but the new way (you sank the old ship), some people simply will not accept the change. They will complain, they will tell everyone who will listen what a bad decision this was, and they will sow the seeds of dissent. With these people, you must make a decision – can they be converted to allies of the new way or do they need to leave?

      Years ago, one of my former employees was a “ship sinking survivor” who did not take well to the change. After we implemented a new, automated project reporting application, he wasn’t very happy. In fact, he referred to the need to report status using the new tool as “chicken-@!$% window-dressing.” And he was very vocal in his proclamations. Not quite the reaction I had hoped for. It would have been much easier to allow his team to revert back to the old way of reporting, but instead, we kept at it. I asked him to tone down his opinions a bit – which he did – but he still wasn’t a fan. It took time for him to use the new process and personally experience the benefits to overcome his reluctance. Before long, his group was the most effective, most efficient in the organization in their use of the new process. They even made suggestions on how to improve the application further. Today when we talk, he frequently mentions how great that process was and how he wishes they had it at his new company. Once converted, former “change-haters” can become your most powerful allies in your change efforts.

      However, some people will not accept a change even after discussing the rationale, the benefits, and the value of the new way. This poses a significant problem, as one of two things will likely happen: these personality types will either derail your change, or the change will reach critical mass and embed itself in the culture of your organization leaving those who refuse to accept the change ineffective. Neither one of these is a very good option – (a) either the change fails or (b) certain employees are unable to fulfill their new duties. To ward off these two bad options, we recommend the following course of action. Upon recognizing disruptive behavior, you should immediately sit the employee down and explain the options: either the employee actively supports (and uses) the new process, or they find employment elsewhere. You might find this hard-hearted, but think about the possible consequences of letting this person continue bad-mouthing your efforts. If the poor morale spreads to enough people to derail the whole change effort, you risk the time and effort you expended on the project and possibly peoples’ jobs, if the project was key to the health of the business. Work with your people so they understand the purpose and the importance of the change. Insist that they use the new process instead of the old way. If they cannot or will not make the transition, they have to go. False kindness is the enemy of lasting process improvement.

      True, effective change isn’t random and it isn’t guesswork. It’s science. Like me, you may not have realized all of the underlying factors that were in play when you experienced a successful change, but they were there, waiting to be discovered. All organizations are complex systems and all complex systems follow a core set of rules. A flock of birds, a mound of termites, a human business endeavor - it doesn’t matter. Understand the rules, and you can more effectively implement change in your organization. Shocking the system is just the first step.


      About the Author:

      Kevin Smith is a co-founder and managing partner at NextWave Performance LLC.

      ©2007 NextWave Performance LLC

      Developing Solutions for a Complex World: The “Stakeholder-Involved” Process

      Developing Solutions for a Complex World: The “Stakeholder-Involved” Process

      The Concept:

      Imagine the scenario: it’s April 1970 and the Apollo 13 spacecraft has recently been launched on its mission to explore the surface of the moon. Suddenly – an explosion on the spacecraft occurs! The famous words are uttered: “Houston, we've had a problem.” It is something for which no is prepared, no one is trained, something completely unexpected. Seeing what must be done, the mission control management team quickly springs into action. Management announces that it will solve the problem and immediately sequesters itself in a distant board room. The rest of the mission control team is told not to worry, to go about its work, and that management will deliver the “solution” soon. When questioned as to why the rest of the team isn’t involved in the solution, management mumbles something about “Sarbanes-Oxley” and runs back to the “war room.” All communication with the team is then severed to ensure that nothing leaks out until the perfect solution is ready. Hmmm…

      Of course, in reality, the mission control operations team worked out a solution together, rather than having it delivered to them by the management team. Unfortunately, too often businesses today respond to crises and risky situations by adopting a “bunker mentality” and consolidating the responsibility for developing solutions to a few select leaders. You might ask: “what’s wrong with that? Isn’t the role of the leader to come up with solutions to the problems facing the business?

      Actually, one of the problems that we frequently witness in businesses today is the consolidation of decision-making at senior levels and the lack of participation of “stakeholders” in the management of processes. Studies show that organizations that involve employees and key stakeholders in the decision-making process are greater than 30% more productive than those that make key decisions in a more centralized manner.

      We believe that there are three primary reasons that the company that taps in to its stakeholders to make key decisions is more productive, including:

      1. Complexity Reduction:

      With the complexity of modern businesses, processes, and systems, it is nearly impossible for a leader to understand all aspects of a problem. By utilizing employees and other stakeholders in the management of processes, leaders reduce the likelihood of key issues being overlooked.

      2. Creativity Enhancement:

      Think of all the business and life experiences embodied in the employees of a business. By allowing these employees to use their individual creativity to try solving problems, you will likely generate solutions that would never have been uncovered if only the management team had been involved.

      3. Perspective Broadening:

      Those outside the intimate daily working of the process have different, unique views of the problem at hand. By harnessing the perspective of these stakeholders in fashioning a solution, the leader better ensures that the “fix” doesn’t cause more problems than it solves.

      We recommend that businesses implement a “stakeholder involved” process – one in which information is shared, in which stakeholders help develop solutions to problems, and one in which process leaders are focused on fostering this collaborative environment. It is a very different model than what you most likely see today – one in which the creativity of employees is encouraged, not frowned-upon. One in which the primary role of the leader is to help employees and stakeholders understand problems and the critical business imperatives. The rewards are significant: higher quality solutions to problems, greater sense of “team” for employees and other stakeholders, improved morale as people see their ideas adding value to the company.

      Applications for the Executive:

      How do you create a stakeholder-involved process? Among the steps we recommend are the following:

      1. Tap into stakeholder creativity

      This sounds simple and logical enough, but it can be more difficult than you might expect. If your stakeholders’ primary experience has been one of “us vs. them,” they are going to be highly suspicious of the new, more involved model. Start by opening your “operational review” meetings to outside participants. Encourage their attendance and participation in the meetings. Share data on process performance – both the good and the bad – and ask for help in determining solutions. If you form a team to solve business issues, make sure to involve employees, upstream and downstream stakeholders, and possibly even vendors. By adding different perspectives, experiences, and thought-processes to your problem-solving toolkit, you will increase both the quantity and quality of possible solutions.

      1. Don’t institutionalize localized solutions

      Often, the first reaction to coming up with a great, creative solution to a problem is to take that solution and replicate it throughout the business. This idea is so great that every division, every office, everywhere should do the same thing! Unfortunately, the creative energy of your employees that you tapped to develop the solution gets stifled in the receiving organization where the solution gets “drop-shipped.” This method also assumes that all organizations have the exact same problems and surrounding circumstances, when in fact, each is unique. Use the solution as a “best practice” model and make sure everyone knows about it, but allow other organizations to develop their own “customized” solutions tailored to their specific problems.

      1. Choose process leadership wisely

      Don’t fool yourself – changing your management style from one where senior leaders make most key decisions to one where everyone is involved is a major change. Not everyone can accommodate that change easily. The fastest way to derail the implementation of a stakeholder-involved process is to have managers who won’t share information, who hide behind service-level agreements, who grab the reins when faced with a risky situation. If you have these types in your organization, we recommend that you take the following steps. First, make sure they understand what you are trying to implement and how they are expected to behave in the new environment. Second, monitor their behavior and their reactions to business problems closely. If they are unwilling or unable to involve the creativity of other in the problem-solving process, it may be time to re-assess your management team.


      It is a new world out there. One where problems are too complex, situations are evolving too quickly, and competition is too fierce to allow isolationist management to run your key processes. Open the lines of communication, tap in to the collective creativity of your employees and other stakeholders and listen, and you will be amazed at the myriad of ideas and solutions that you might never have considered.



      About the Author:

      Kevin Smith is a co-founder and managing partner at NextWave Performance LLC.

      ©2007 NextWave Performance LLC

      Think Before You Automate...

      Think Before You Automate…

      The Concept:

      Did you hear about that great new CRM/billing/inventory/ forecasting/fulfillment/ ordering/ whatever application? It’s going to save our business! I hear it uses bilateral n-dimensional hypercube technology in a virtual “on-demand” nano-warehouse environment to figure out everything you need BEFORE you even realize it! It synergizes, empowers, works out-of-box, seamlessly integrates (with no downtime), never goes down, pays for itself, and requires no training. The sales person told us it can be installed yesterday, costs virtually nothing, includes “platinum-level support,” is always installed on-time and under-budget, has nothing but thrilled users, and OF COURSE IT WILL INTEGRATE WITH YOUR PARTICULAR PROCESSES! Wheeeee!

      Oh, if only this were just a bad version of a George Carlin routine. Unfortunately, it seems to be the path more and more companies are taking these days to solve their performance woes. To be clear, we are big proponents of using technology solutions to solve performance issues – but with one caveat. It MUST be done wisely.

      The lure of the magic bullet application that solves all issues with no drawbacks is certainly enticing (my endless stream of smartphones can attest to that…) However, such a solution simply does not exist. It is our experience that the vast majority of “pick-a-system-and-just-deploy-it” type solutions result in partially deployed applications, solutions that fail to address key aspects of the problems to be solved, implementation costs that are 30-50% higher than expected, and deployment timeframes that are at least 25% greater than expected.

      Whatever technology you choose must be the result of thoroughly and intimately understanding both the current problems being experienced and the desired “future state” you wish to achieve. Deploying a technology solution without understanding these two things is like a kid building a model aircraft carrier without any instructions. It might work out in the end, but at some point someone is going to notice that you used 27 tubes of glue, forgot the rudder, and it won’t float.

      Why do companies routinely jump to the deployment of systems and application without thorough process planning? We believe the primary reasons to be the following:

      1. A belief that technology alone is the solution:

      As a society, we have been led to believe that technology can solve anything. By itself. This is almost never the case - miracle drugs work best with modified lifestyle, hybrid cars work best with a change in driving habits, and a technology solution to a business problem works best when preceded by a change in process strategy.

      2. A demand that something gets deployed NOW:

      Selecting/buying/building “feels” more like taking a proactive step to solving the problem to some people than does identifying current problems and planning out a future path. It is natural to want to give in to the desire to buy or build immediately, but action without direction can lead to disastrous consequences.

      3. A lack of understanding of the intertwined nature of the problem:

      Rarely do we find that a process stands alone with no interaction with other processes inside or outside the business. Process and their associated problems are always deeply intertwined with other process and cannot be changed without significant implications. As discussed previously ( EIR 1, Understanding the Organization as a System ), significant change to one process in a system can have serious impacts elsewhere in the system. You can’t change billing processes without impacting ordering processes. Lack of understanding of the intricacies involved in the company’s business processes leads many decision-makers into the trap of deploying without adequate process planning.

      Applications for the Executive:

      How do you combat the siren call to deploy the latest and greatest technology right this minute? We recommend the following three strategies:

      1. Understand the Current Problem

      The first step to developing a successful technology solution is to understand the problems that are causing you to seek a solution in the first place. Is it an inability to handle certain types of transactions? Lengthy cycle times? High levels of fallout or errors? We recommend that organizations develop a model of the current state of the process – including all the manual and automated steps that will be supplanted by the proposed automation. Additionally, we recommend that companies capture a list of the “disconnects” or process issues that are causing a need for change. With a process map and a list of problems in hand, it is less likely that the systems solution chosen will recreate the ugliness of the past.

      1. Use the Future Flowchart to Build Requirements

      The second step prior to choosing new technology is to develop a flowchart of the future state that you wish to achieve. By developing a detailed flowchart of the “future mode of operation” (FMO), you will accomplish two things.

      First, you will have a document that helps you know what to buy or build. The flowchart can very easily be translated into detailed business requirements that can be used to assist in the technology selection.

      Second, the FMO gives you a checklist to help select a vendor, should you choose that route. Most software vendors count on the fact that you have a very fuzzy picture of what you actually need the software to do. If you don’t fully understand your specific needs, they will spend lots of time discussing all the wonderful features of their product instead of spending time demonstrating how the product meets (or doesn’t meet) your specific requirements. Build the FMO and insist that candidate software vendors review the flowchart and color-code each box on the chart - green (the software can perform that step right off the shelf), yellow (the software can perform the step, but only with customization), or red (the software cannot perform the process step). It is a surefire way of finding out how closely the technology matches your vision and how much custom (read: expensive) development work will be required. Plus, software sales people really love going through a huge flowchart and having to explain that their application only performs 20% of the steps right out of the box…

      1. Deploy in Logical, Process-based Phases

      Here’s how most process automation deployments happen: IT and/or the vendor develops a plan in which all functionality for a product line gets automated, then the next product line, and the next, and so on. They tell you that this way, they get to work out any issues or bugs and then each successive product roll-out goes much more smoothly. All true. What they DON’T mention is that this causes major process problems for the employees. Instead of just the old “bad” process/system, the employee now has to deal with the old process PLUS the new process – but just for certain products. It can end up as a nightmare scenario for quality and customer satisfaction.

      Instead, try to deploy entire “clusters” of functionality at the same time. Your deployment looks like this: the “pricing tool” is developed and deployed for all products and the old tool/process is decommissioned, then the “billing tool” is developed/deployed for all products and the old tool is decommissioned, etc. An added benefit of this type of deployment is that even if the automation project gets derailed half-way through, you still will have sections of the process that have benefited from the work deployed to date.

      Let’s face it – the promise of slick, new technology that will automate all of our processes while driving down costs and increasing productivity is very enticing. But, like most anything, a little caution is advisable. In whatever technology you choose, proceed first with process design to determine the optimal future state for your particular situation. Once that is complete, start examining technology solutions, but make absolutely sure that the process drives the technology choice. Don’t be forced in to a sub-par business process as a result of the system you chose.



      About the Author:

      Kevin Smith is a co-founder and managing partner at NextWave Performance LLC.

      ©2007 NextWave Performance LLC

      Organizational Fields: The Keys to Successful Change

      Organizational Fields: The Keys to Successful Change


      The Concept:

      Studies show that as many as 75% of all process/performance improvement initiatives fail to deliver the expected results. It isn’t for lack of trying – Six Sigma, TQM, Kaizen, BPR – the list of methodologies claiming to have “the answer” to successful performance improvement goes on and on, yet so do the failures. Could it be that we are overlooking something? Something that may be the critical determining factor as to whether a change effort succeeds or fails?

      After years of using highly linear, deterministic models that attempt to reduce organizational dynamics to simple equations, the tide has begun to shift. Change leaders are beginning to realize that flowcharts and metrics are not enough to create successful change within an organization. They are starting to realize that many influences – soft, “touchy-feely” influences – may impact a performance improvement project as much as the actual steps in a flowchart.

      This new way of examining process performance is called “field analysis” and is integral to the concept of viewing an organization as a dynamic, living “system” [ see EIR 1, October ‘06 ].

      Simply put, “fields” are those intangible factors that surround all processes and organizations and which exert significant influence on the probability of change success or failure. These fields include:

      · Morale

      · Sense of team

      · Sense of purpose

      · Sense of success probability (feeling that you can succeed in a given role)

      Here are a few examples of how fields can influence performance:

      · An organization initiates a process redesign project to improve the customer support/help desk process. After spending significant time and resources on the redesign, the implementation stalls and dies a quiet death. Interviewed help desk employees report that they felt a sense of “hopelessness” and that “nothing would really change.”

      · A business implements a new initiative to improve the customer experience. Employees are told that “customer satisfaction is the #1” goal, however, leadership continues to push goals of increased sales over everything else. 90 days later, customer satisfaction has not increased and employee morale is at an all-time low.

      · A technology-driven company is plagued with low morale in its Sales organization. Although various incentive programs are attempted, nothing seems to work. Sales people complain that the processes don’t allow them to sell effectively, but they are largely ignored. Key sales people stop trying to sell to new customers.

      Each of the above examples was representative of the impact that fields can have on performance. Whether it is general poor morale, dissonance between what management says and what they actually do, or a feeling that you can’t succeed at your job, fields affect project success.

      The problem is - how do you incorporate fields into the way you lead change activities?How can you harness these intangible, fuzzy concepts as allies that can help ensure positive results?

      Applications for the Executive:

      Although not as straight-forward as flowcharting a process, establishing new metrics, or adding new technology tools, improving your fields may be the single most valuable thing you can do to improve your business.

      1.  Recognize & Redesign your Fields

      The first step in improving field performance is to recognize what fields are at work. We like to do this through highly-focused interviews, but you can do it in your own organization by simple talking to your employees. Take every opportunity to interact with your staff and ask them about what they are seeing, hearing, and “feeling.” Don’t be dismissive or defensive. Listen to what the employees are saying. You might recognize these fields as “themes” that recur throughout your discussions.

      Next, “redesign” your fields to better align with your goals. One way to do this is to make a prioritized list of fields, ranked by the “pain” each is causing, and developing specific projects to address each deficiency.

      In the end, it is largely a “trial and error” exercise. Over time, you will learn what fields are having the most influence and what tactics have the most impact on those fields. The important things to remember are (1) pay attention to the fields and (2) take action to close gaps you identify.

      2.  Time Your Projects

      Timing is everything. Don’t start a key process improvement activity when morale is very low. Don’t try to launch a new system integration project when employees are preoccupied with a possible lay-off. It is not enough that the project has a positive return, is needed by the business, etc. It also has to be successful and that means it has to be timed properly.

      Prior to starting any change project, brainstorm a list of the fields that may have an impact on your project’s success. Then create a list of “mitigation tactics” next to each of your most problematic fields. If you have highly problematic fields that you can’t address through your mitigation tactics – you have a problem. Consider postponing your project until the field issues have resolved themselves or you have developed appropriate tactics.

      3.  Eliminate the Negative Factors

      Unfortunately, during your field analysis, you may find that it is one of your own employees that is creating a negative impact on the fields influencing your organization. We’ve all had that experience – the “disgruntled guy” who would rather complain and find fault with everything rather than trying to help fix the problems. These people are poison to the fields of an organization. No matter how much time you spend trying to improve morale, sense of purpose, or sense of success probability, “disgruntled guy” can undo all of your hard work in short-order. You must decide if the value added by the disgruntled employee outweighs the drag on the group or if he can be convinced to change his outlook. Don’t make the mistake of trying to ignore the situation and hoping it will go away. It won’t, and it will jeopardize your efforts.

      Although you can’t [easily] measure them and you can’t see them, you can certainly feel the influence of fields on your performance improvement projects. Recognize this influence and plan for it when considering projects and you will significantly improve your probability of project success.



      About the Author:

      Kevin Smith is a co-founder and managing partner at NextWave Performance LLC.

      ©2007 NextWave Performance LLC

      Dying of Thirst in a Sea of Data

      Dying of Thirst in a Sea of Data

      The Concept:

      If there is one thing that everyone in management seems to agree upon, it is the need to measure business performance. Unfortunately, “agreement” and “effective execution” are vastly different beasts. Very few organizations have truly cracked the code for the successful measurement of business performance.

      Why is this? We all recognize the need for performance measurement. We have more data at our “virtual fingertips” than ever before, yet we seem more out of touch with effective performance measurement than ever before. The difficulties can be narrowed down primarily to three areas:

      · Failure to measure the right things

      · Failure to measure consistently

      · Failure to take action on the information we do have

      Failure to Measure the Right Things:

      First, managers frequently fail to measure the aspects of the business that could really have a positive impact on performance. Management tends to measure either those things that are easy to measure (e.g. revenue, cost, head count) or those things that have been traditionally measured for that industry (e.g. mean time to repair for telecommunications, on/off-budget for project management). As a result, many metrics may be either useless or no longer relevant for the modern business. Rather than investing in the development of new, more effective but perhaps more difficult to gather and/or implement metrics, managers have become complacent with sub-standard performance information.

      Failure to Measure Consistently:

      Second, too many leaders simply fail to track the same metrics on a consistent, regular basis. At numerous organizations, we have heard the complaint that the “dashboard changes each month.” This is analogous to trying to improve your car’s gas mileage by looking at a different “metric” at each fill-up. First by tracking mileage with the fuel gauge one fill-up, then by using the on-board computer for the next fill-up, then by tracking the gallons put in the tank on the third fill-up, etc. Each metric might be useful taken by itself, but it is the consistency of measurement that is lacking. Leaders today often exhibit signs of “corporate attention deficit disorder,” leading them to constantly change metrics and formats in an attempt to gain new insight into performance. Unfortunately, in the attempt to gain more and more information, we actually lose insight into critical performance trends and shifts.

      Failure to Take Action on the Information We DO Have:

      Finally, as performance improvement practitioners, we find nothing more frustrating than watching an “operational review” meeting where the presenter flips through page after page of metric data at lightning speed while the executive team nods and makes “hmmm” and “ahhhh” sounds. The presenter makes comments such as “customer on-hold time is up again this month” and then flips to the next metric. It really begs the question – what are you going to do about it?!? There is no inherent “goodness” in the act of measurement. The only reason to spend the time and money to measure performance is if you are going to take action based on the reported data. If you don’t plan to make changes and improvements based on your metric reports, you can save money by just using the same report each week and even canceling the meeting…

      Of course, the real solution is to tie the information about performance to actions intended to remedy the reported performance gaps.

      Applications for the Executive:

      Here are three steps you can take to ensure that the metrics you report can actually help you improve performance.

      1. Correlate your Metrics

      Rather than reporting metrics because they are easier to gather (e.g. the IT systems that can easily deliver them are in place) or because they have always been used in the past, you need to determine which metrics actually matter for your business performance. “Balanced Scorecard” techniques start down the right path, but do not go far enough. The answer is to build a “Correlated Scorecard” that shows which metrics have the greatest impact on your business goals.

      To build a correlated scorecard, start by arraying your metrics in a hierarchical format (like an organizational chart). For example, corporate revenue may decompose into regional revenues which decompose into office revenues, etc. Next, determine which handful of five to seven metrics are most important to your business (such as revenue, costs, and customer satisfaction). These are your “target metrics” and are placed at the top of your hierarchical dashboard of metrics. Finally, determine the influence that each “sub-metric” (those metrics far down the hierarchy) has on your target metrics. This is usually done through statistical regression modeling (available in software packages such as Microsoft Excel). The result should be a formula that will tell you the expected change in each target metric for a given change in the sub-metrics. How much will revenue change if customer service headcount increases? This model can answer that question. The key is not to predict exactly how much your target metrics will change, but rather to determine which sub-metrics have the most impact or influence on the metrics you really care about – the target metrics. Your new “correlated scorecard” should contain only those metrics that are the most highly influential on your target metrics. Through this technique, businesses can reduce the need to gather metric data that is less predictive of performance, thereby reducing reporting costs and allowing the management team to focus on just those measurements that matter most. (Note: This topic will be covered in more detail in a future EIR)

      1. Use Secondary Metrics

      It is a simple fact that some metrics are harder and more expensive to gather than others. Whether the data just doesn’t exist or the system modifications would be too extensive – some metric data simply isn’t available. If this is the case, consider developing a “secondary” or “proxy” metric to measure the performance aspect of interest.

      A “secondary metric” is a metric that doesn’t measure performance directly, but rather, through some other aspect of the business. For example, one executive we know was not able to easily track customer traffic flow into his branch offices, so he tracked paper cup usage in the branch offices’ free coffee machines instead. It sounds strange, but if you assume that employee usage stays consistent, then this is a pretty good indicator of customer traffic. The key is to track the trend of a secondary metric, not the actual value. You don’t really care about the number of cups, but the percentage increase/decrease trend over time gives you the information you need. Remember, don’t give up just because you can’t obtain a needed metric. Get creative and build a secondary metric to gain the insight you desire.

      1. Tie Metrics to Action

      All the wonderful, correlated metrics in the world are completely wasted if they are not directly tied to action. To ensure that your metrics are tied to action, start by scheduling a regular “operational close” meeting at which you will review metric performance. All leadership should attend and the data should be presented by the responsible manager. This meeting should be held on a regular (and consistent) basis – we recommend a monthly meeting. The meeting should also be chaired by a strong leader who can ensure that each presenter delivers the required information in a standardized format.

      The next step is key: every metric presented that is not performing as desired should have an action plan – a set of steps intended to remedy the performance gap. Further, each action plan must have an owner , a status, and a due date. At each operational review, the presenter must not only present the latest metric results, but also the status of the action plans designed to improve performance. It is also critical for the management team to hold managers accountable for making progress on each action plan.

      Finally, re-vamp the way you select and manage projects. At too many businesses, projects and metrics are managed as completely separate entities. Our question is this - if your project doesn’t directly impact one of the metrics of the business, why do you have the project? When setting project priorities, request more than just the basic financial details for each project. Demand that every project request include a list of the metrics that will be improved and the amount and expected timing of the improvement. If your requester cannot deliver this type of information, you may have discovered a gap in your metric coverage, or the project may not be particularly valuable to the business. Using this technique can help your organization align desired metric performance with the projects that will help you get there.


      About the Author:

      Kevin Smith is a co-founder and managing partner at NextWave Performance LLC.

      ©2006 NextWave Performance LLC

      Understanding your Organization as a System

      Understanding your Organization as a System

      The Concept:

      Over the past several years, a dramatic change in our understanding of the way successful businesses operate has taken place. If you are like the vast majority of organizations, you probably have heard bits and pieces of this change, but haven’t really thought about what it means for YOUR organization.

      “Learning organizations,” “matrixed management,” and “management by walking around” are concepts of which you may be familiar that are just skirting the edge of the true breakthrough in understanding how we can do business better. What all of these concepts and techniques are pointing to is the idea of the organization as a “system” or as a living organism rather than just a set of boxes on an organizational chart or a flowchart.

      What does this mean, “organization as a system?” What it means is that, like a living body, an organization is best understood as a whole, rather than in parts. For example, let’s say you have lower back pain. You go to a doctor for a diagnosis of your problem. A “Classical view” doctor might say “hmm… Lower back pain – looks like a slippage of one of your discs. We’ll operate and get that fixed right up.” This sounds fine on the surface, but may be missing underlying factors. A “Systems view” doctor might look a little deeper. He or she would notice that one of your legs is slightly longer than the other resulting in a subtle limp and therefore unbalanced stresses on your spine. The “Systems view” doctor might recommend special insoles for your shoes in conjunction with physical therapy. It is the relationship between your back and the other parts of your body that is causing the pain. Although we see this routinely in medicine, science, and engineering, it is amazing how often we fail to view our business in the same manner.

      You may be thinking “that sounds obvious – of course my organization is more than just a set of boxes on a flowchart, of course the relationships matter,” but the implications are more drastic than you might realize. With our “classical view” of business and business problems, too often our first action is to attack the problem “classically.” How often have you experienced the following?

      · The IT organization decides to change key policies without consulting any of its client/customer organizations. As a result, those organizations that interact with IT are now scrambling to change their processes to fit the new IT policies. Massive disruptions to the business processes occur.

      · Problems are occurring within a particular process. Management decides to redesign that process only – systems, training, leadership, other processes – all off-limits. As a result, management doesn’t get the expected results and employee morale is dampened.

      · A new leader is hired for an organization or division. In quick order, that person makes major changes to the organization and the ripple effects – both tangible and intangible – are felt everywhere in the business. No one questions these changes - after all, it is the new leader’s right to make changes.

      · A senior employee complains that he constantly gets calls directly from customers, from sales, from engineering, etc. with problems to fix. This person states that the process for getting issues fixed is broken and that this is why he gets all the calls. According to him, he gets work done “in spite” of the process, not because of the process. This person is dismissed as a “complainer” and is ignored.

      These are all symptoms of the classical, non-systems view of an organization. By not understanding the critical importance of relationships between processes, between employees, and between actions and results, leaders risk huge, unintended consequences from actions that they perceive to be inconsequential.

      Simple Applications for the Executive:

      So the organization is a complex, dynamic, “system” with intricate interrelationships between all of its parts. What does this mean for the leader of a business organization?

      1. Understand that your actions may have widespread “ripple effects”

      As a leader, you have immense impact on not just your organization, but the company as a whole. Don’t believe this? Imagine what would happen if you told a few employees in your group that you were no longer going to use your IT organization’s services, but rather were going to outsource the next project. How quickly would this “rumor” get around the company? Might it impact how IT treated your current projects? It is critical that you consider the systematic implications of the decisions you make every single day as a leader. Are you going to change a policy? Make sure that you think about how it might affect upstream and downstream organizations. Are you going to communicate a new direction to your employees? Think about how that communication might be perceived by other leaders, organizations, and potentially customers. Little actions can have big consequences.

      1. Foster relationships everywhere

      Organizations run on relationships. Relationships between people, between processes, with customers, etc. Encourage (in fact, insist that) your managers meet regularly with their peers in other organizations to discuss issues and what they are seeing in the trenches. Encourage managers to sit down with their employees and conduct a “round-table” to discuss the issues of the day. None of this needs to be very formal, but it does need to happen and it does need to be “risk free” (no one gets fired for discussing problems). Many of our performance improvement “breakthroughs” with clients have been the result of just getting people – many of whom have never even met before – to sit down in one room and discuss the processes they use and the problems that they face. Foster the building of strong relationships and many process gaps will naturally fill themselves in.

      1. “De-isolate” Your Organization

      Like the doctor who looks beyond just the lower-back pain to discover the root causes, you must open your organization up to the rest of the company. This means that if you redesign a process, you must consider the impacts that leadership, other processes, communication, hiring practices, training, morale, and many other factors all have on your process’s performance. You can build the ultimate process for your organization, but if you don’t understand the relationships and the connections to the rest of the business, you will have major problems.

      Hold open-house meetings occasionally to discuss projects your group is pursuing. Actively seek feedback from your employees, your peers, and other organizations. The simple acts of recognizing that your organization is intimately connected to many parts of the business and behaving as a part of the whole can eliminate many potential problems and radically improve performance down the road.


      About the Author:

      Kevin Smith is a co-founder and managing partner at NextWave Performance LLC.

      ©2006 NextWave Performance LLC