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
• ARE NOT THE PEOPLE WHO WILL PROGRESS YOU TOWARD YOUR GOALS.

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.)

• Instead of paper - Use EchoSign

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)

• Instead of: Microsoft Visio - Use LucidChart

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)

Update on Friday, April 17, 2009 at 4:30PM by NextWave

Since I originally wrote this, Platform-as-a-Service vendor Coghead has been acquired by SAP and is no longer offering the service to end users.  In lieu of Coghead, I highly recommend TeamDesk as a web-based application system.  Alternatively, you can find lots of info at the PowerInTheCloud website's PaaS Vendor list.

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.

Update on Friday, August 7, 2009 at 11:36AM by NextWave

The platform-as-a-service provider mentioned in this article was acquired by SAP and is no longer available to the public.  Our recommendation?  Try dbFlex instead.  It's similar to Quickbase or Coghead but for a lower price.  (Disclosure:  we are a dbFlex partner, but receive no compensation for directing users their way.)

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

Update on Friday, April 17, 2009 at 4:26PM by NextWave

Jonathan Sapir of PowerInTheCloud.com has an excellent post on how CAS applies to situational application development here