&Research Paper

Knowing that the Project Clothes HaveNo Emperor

How to Support the BusinessÐNot the Old Systems

Brian DickinsonPresident, Logical Conclusions, Inc., Kings Beach, California, USA

Much of what we see in place at an organization is there to support the `design structure.' Mostsystems were put in place to make the business run as designed for the real world at somepoint in the past. This structure is the biggest target for improvement in a re-engineeringproject and also, if not acknowledged, is the biggest potential source of failure. This is becausethe `design structure' is there to accommodate human systems and computer systemsÐtheseare the design aspects of an organization. These structures are the clothes (the systems) thatcover the emperor (the business). This article will show you how to discover the emperor andnot simply streamline or up-date the clothes. &1997 John Wiley & Sons, Ltd. and CornwallisEmmanuel Ltd.

INTRODUCTION

We are seeing a number of surveys indicating thatup to 80% of re-engineering projects fail. Theseclaims of re-engineering failures get me on my`soap box,' so I would like to use this forum to cutthis stuff off at the pass.

Listen up! It's almost impossible to fail in a re-engineering effort if your organization is more than3 nanoseconds old (I'm only slightly exaggerating).This claim is based on my 31 years of observingthat the vast majority of organizations have simplyevolved to where they are today. This evolutionwas typically without any conscious `engineering'method applied to past growth. Therefore, theopportunity to re-engineer any established organ-ization will produce many areas of signi®cantimprovement and hence a successful effort.

LET'S GET SOMETHING OUT IN THE OPEN

Re-engineering has very little, if anything, to dowith:

. Downsizing,

. Arbitrary cutting of middle management,

. Implementing the latest computer technology, or

CCC 0969-3866/97/040261-07$17.50 261& 1997 John Wiley & Sons Ltd and Cornwallis Emmanuel Ltd.

Brian Dickinson is the founder and president of LogicalConclusions, Inc., a successful training and consultingcorporation servicing many government agencies and majorcorporations. He has over 30 years' experience in teaching andconsulting in business systems and all areas of data processing.For two years he has contributed to Vice President Al Gore'sprogram to re-engineer the government. Brian is an activeparticipant in the Citizen Ambassador Program and hasrepresented the US in China and Russia. He has consulted andtaught globally on the subjects of Software and InformationEngineering, Project Management, and Business Re-Engineering. He is also a popular international speaker onQuality System Development.

Brian is the author of many books on the subject of SystemDevelopment Methodologies and on Business Re-Engineeringincluding: Developing Structured Systems: A Methodology UsingStructured Techniques, Developing Quality Systems, StrategicBusiness Engineering, and Risk Free Business Re-Engineering.

Knowledge and Process Management Volume 4 Number 4 pp 261±267 (1997)

Re-implementing departments with a humanteam approach.

It does have everything to do with:

. Growth,

. Customer satisfaction,

. High productivity,

. Competitiveness, and

. the longevity of an organization.

OUR CPU (COMMON PLATFORM OFUNDERSTANDING)

I de®ne the goals of re-engineering as follows:

. Put the customer ®rstÐsatisfy customers' needsand expectations by structuring our organizationto seamlessly respond to these needs.

. Cut red tapeÐachieve dramatic and measurableimprovement over the performance of the organ-ization's old implemented systems (human andcomputer).

. Replace old systems that may be hurting theorganization today with quality engineeredsystems.

. Remove aspects of the existing organization thatdo not directly satisfy the organization's strategicgoals.

SO, WHAT'S FAILING? OR, THE MORETHINGS CHANGE; THE MORE THEY STAYTHE SAME

I believe that the failing projects exposed in thesurveys aren't really re-engineering efforts at all;they just use the banner of re-engineering to carryon the same, `throw-the-system-together,' `projects-as-usual' practices.

It's not a re-engineering project when:

. There is no organization mission statement anddocumented project charter to start it off.

. The focus is on system/implementation issues(i.e. at the beginning of a project you've alreadydecided on the implementation technologyÐeither human and computer).

. You think you don't need to conduct a systematicanalysis as part of the project.

. You don't intend to maintain an engineeringdiscipline throughout the project (i.e. you haveno re-engineering methodology in place).

. The re-engineering team has no training in re-engineering speci®cs.

. A classical, existing project suddenly gets re-named as the organization's `re-engineering'project.

. The project goal is to obtain short-term grati®ca-tion for management or shareholders (or tosatisfy a political agenda) to the exclusion ofthe customers' interests.

. You have project goals that don't respect thesigni®cant effort involved in re-engineering anorganization.

. A part time, isolated group of available indivi-duals meet occasionally to conduct the project.

. You've already decided on a pre-packagedsystem solution that `magically' ®ts your essen-tial business.

Note that re-engineering is not a response to`crisis mode.' It is for sensible organizations thatdon't wait for their products and services tobecome obsolete or for their customers to complainbefore they look at the organization's response totheir needs. Even the best organizations should notlet `best' get in the way of better. We should all takelessons from the slide rule and Swiss watchcompanies. If they're not making calculators orquartz watches, they're probably out of businessbecause they lost track of what they did and gotwrapped up in how they did it.

Do call it re-engineering when:

. You have and are satisfying the organization'smission statement.

. `Political' hierarchies are disregarded and theemphasis is on partitioning the organizationbased on customer satisfaction.

. The project charter for the re-engineering efforthas the `royal seal' and top management'scommitment and the contents of this charterseparate measurable system, project, and busi-ness goals.

. A systematic re-engineering methodology isadvocated and a dedicated re-engineering teamis fully trained in the method.

. Analysis is recognized as the most signi®cantpart of the project.

. You intend to introduce a solution based on theresults of an analysis of your essential business.

. You have reliable metrics before deciding upondeadlines and the resources needed to meet these

RESEARCH PAPER Knowledge and Process Management

262 B. Dickinson

deadlines (i.e. the project isn't saddled withinsuf®cient resources).

Re-engineering is not a fadÐunless you considersurvival `faddish.' Re-engineering is far moreimportant than what we used to know as a `typicalproject,' because often the entire organization'scontinued existence is at stake. Remember thathistory has taught us that there will always beanother organization (or country) that's willing totake the long-term view and do it right. This iswhen we all get our pink slips.

OK THEN. WHAT WILL MAKE A GENUINERE-ENGINEERING PROJECT BE CLASSEDAS A FAILURE?

We have a number of potential sources of failurerelating to the goals of re-engineering. These areusually put in place by the existing organization's`powers that be.'

When an organization embarks on a re-engineer-ing project, someone (usually a human being in amanagement position) has to declare the goals thatde®ne `success' in a Project Charter. Unfortunatelythat `someone' in many cases has to put themselvesin the hot seat and be willing to admit that theymay be part of the `Clothes that have no Emperor.'This leads us to a couple of major sources of projectfailure.

Potential source of failure No. 1Ðconcentratingon system goals, or `let's buy some new clothes incase we ®nd an Emperor.'

What I mean by this phrase is that much of whatwe see in place at an organization is there tosupport the `design structure.' In other words, mostsystems were put in place to make the business runas designed for the real world at some point in thepast. This structure is the biggest target forimprovement in a re-engineering project. It is there,of course, to accommodate human systems andcomputer systems, as these are design aspects of anorganization.

These structures are the clothes (the systems)that cover the Emperor (the business). In manyprojects that have purported to be re-engineeringefforts, I have seen their initiators declare the use ofnew computer technology as the major goal of theproject (e.g. on-line automation of tasks, client-server computer systems, relational data-bases, useof the Internet, and such). This is technology

`driving' the business and it's incredibly commonout there. In many cases these people have alreadymistakenly decided on a sexy new hardwaresolution before they've really analyzed the pro-blem. They've lost sight of the fact that thehardware and/or software system issues are reallyonly solutions to business requirements. The sameapplies to any other design-oriented goal such asthe human-oriented goals of downsizing, outsour-cing, use of production teams, or ¯attening themanagement hierarchy.

Don't get me wrong; these system goals may beperfectly validÐif the analysis of the businessreveals inef®ciencies in the current implementationand these solutions will be the best in satisfyingthose inef®ciencies.

I'm saying that if you're involved in a re-engineering project, it implies that you suspectthere's something wrong today with the waythings are and that you're going to apply anengineering discipline to discover what's wrongbefore proposing a new design. Don't start propos-ing new designs as long term solutions until afterthe analysis is complete. Even then, please realizethat designs aren't the goals of the project, butmerely a part of the solution.

If we do not conduct an accurate analysis as theprimary part of a re-engineering effort, we willprobably fail to remove our blind acceptance ofpreconceived design notions of `normal businesspractices' of the past. These `normal' practicesinclude human structures such as divisions,departments, agencies, and bureaus (and their `turfwars,' etc.). They also include their computerequivalents such as Order Entry systems, account-ing systems, edit/update/print programs, input/process/output programs, a 4Kb subroutine, etc.(and the programmer/DP mentality that perpetu-ates these structures). This failure will lead us to re-engineer a system or a signi®cant part of a systemthat should have been tossed out long ago. In fact,this failure to see through the old designs leads usto create faster bad systems and hence from anymeasure, brands the project as a failure.

I do realize that one of the problems is thatstrategic planners must often make decisionsregarding long term equipment acquisition, sitemanagement, facilities expansion, and so forthbased on the needs of the proposed design. Evenso, please don't let this lead to the myopic view thatit's the new equipment that matters most. Thisview also often sets up false re-engineering projectsfor failure.

It may be worth mentioning here an all toocommon, particular System Goal I see stated in re-engineering effortsÐto outsource as much as

Knowledge and Process Management RESEARCH PAPER

Knowing that the Project Clothes have no Emperor 263

possible. Please realize that outsourcing is anothersolution (possibly looking for a requirement) andthat rushing to outsource is to decide on how toimplement the organization's business beforereally knowing what it is the organization does.

Also, the moment an organization starts out-sourcing, it loses control of some part of the processof satisfying its customers. Assuming that thecompany providing the outsourced services is inbusiness for pro®t, your organization will mostlikely start to pay more than what it would cost tore-engineer and use your own people and systemswith associated training, equipment, etc.

Potential source of failure No. 2Ðconcentratingon project goals, or `where did you get yourestimating/projection skills?'

The culprit here seems to be the court jester.Someone (usually close to the Emperor or even theEmperor him or herself) sets an arbitrary limit onthe resources (time, people, money, support)needed for the re-engineering project. Any projectcan be classed as a failure when a person makesuneducated projections re¯ected in the projectgoals.

If you put your management `hat' on and putyourself in charge of a re-engineering effort (or anyeffort), you have a delicate balancing act on yourhands. It's like trying to maintain an equal balanceon a four-ended see saw. This is similar to thechildren's playground ®xture with the differencethat it looks like a plus sign balanced on a point inits center. At one of the four ends of the see saw sitsthe project scope identi®ed by the total set ofbusiness requirements and on another sits theallotted resources. On yet another end of the seesaw sits the effort deadline. Finally, sitting on thelast seat is the resultant system's quality.

If you set a restrictive project deadline, and thedate you set is not based on empirical data (fromother, similar re-engineering projects), please rea-lize that one of the other quadrants has to `give' tomaintain a realistic balance. It's entirely possible(although rare) that your deadline may be too longif you base your estimate on `®nger-in-the-wind-guesstimates.' With a preset deadline you canachieve a balance if you can prune the number ofrequirements (i.e. don't try to re-engineer the entireorganization at once); or, if you can put moreresources (money, people, support tools, experts,etc.) on the project.

Obviously, the same goes for any of the otherfactors; e.g., trying to increase the requirementswithout increasing the necessary resources upsets

the balance as does trying to shorten the deadlinewithout upsetting quality or one of the other factors.

In my view, the most important rider on the seesaw is quality. If you lower quality by shorteningdeadlines (or skew quality through a mismatch ofrequirements and resources on the other beams),you may as well throw in the re-engineering towelbecause what you'll end up with is an expensive,poorly made substitute for the inef®cient, oldsystems you're replacing.

People who allocate the project's resourcesshould know how to maintain this balancing acton the four-way see saw and know that lettingquality take a drive is not an option if truly re-engineering.

If you are willing to sacri®ce quality, pleaseremove the word `re-engineeering' from yourproject and call the effort `downsizing', `restructur-ing', `streamlining', or any of the other fad labelsthat we've seen come and go in recent years.

We don't need to give up trying to manage a re-engineering effort if there are no realistic statisticsavailable. We can take a high-level pass on the re-engineering effort and evaluate the intermediateresults as we go.

OK THEN. WHAT WILL MAKE A RE-ENGINEERING PROJECT BE CLASSED AS ASUCCESS?

The potential source of successNo. 1Ðconcentrating on business goals; or `takeme to your Emperor.'

We need at least one measurable business goal for are-engineering effort to be valid. These are realisticgoals regarding what the organization does for itscustomers against which we can demonstrablymeasure the new systems. In other words, we startmeasuring the accomplishment of these businessgoals on `day one' of implementation of the newsystems. This is what separates business goals fromsystem and project goals. It is absolutely necessaryfor the success of a re-engineering effort to discoverthese. We need to nail down upper management toproduce the business goals. Whenever I think ofbusiness goals, I'm reminded of John F. Kennedy'ssuccinct business goal:

`I believe that this nation should commit itself toachieving the goal, before this decade is out, oflanding a man on the moon and returning him safelyto the earth.'

RESEARCH PAPER Knowledge and Process Management

264 B. Dickinson

Notice that he stated what we should do, the levelof quality, the deadline, and a requirement withoutstating any `how we should do it,' system/implementation issues. Be careful hereÐa businessgoal to `provide better service to the customer' isnot really a valid business goal because it effec-tively translates into the nebulous: `do good andavoid evil on this project.' I've never seen `provideworse service to the customer' stated as a goalalthough such things as knee-jerk downsizing oftenresult in this.

With a little skill we can teach ourselves toidentify or ask the right questions to ®nd the truebusiness goals of a re-engineering project. This maybe as simple as asking `What's wrong with theservice to the customer now?' and `What measur-able, customer-oriented improvements do youexpect to see?' I doubt whether many customerswould request that we buy the latest high techequipment or use a team approach to our internalstructure, which (as stated previously) are systemgoals.

Please note that although it would be best tohave them declared up front in the project charter, I®nd nothing wrong with discovering the realisticbusiness goals throughout the analysis stage of there-engineering project. I invariably ®nd that the re-engineering team themselves discovers all kinds ofbusiness goals in analysis.

Business goals dictate and lead us to discover thedetailed business requirements. From a veryfundamental point of view, business requirementscan be looked upon as that set of nouns and verbsthat make up the essential response to ourcustomer's needs. For example: when I, as acustomer, want to withdraw some money frommy bank account, I'm not too concerned whether Iuse the bank's implemented human system orautomated teller system (or, in some cases, theirhome banking system). These are just designs putin place by the designers of banking systems toallow me, as a customer, to withdraw my funds. Ido hope though, that the same set of essential verbsand nouns get `triggered into life' when I conductmy withdrawal, regardless of the design placed ontop of them. These essential verbs and nounsusually consist of: verifying the customer and theaccount ID and checking the account balance. If allthis is OK, then subtracting the withdrawal amountfrom the account balance, transferring the funds tothe customer, etc. take place.

Whether these verbs are implemented as state-ments in a human procedure manual or ascomputer code and whether the nouns are imple-mented as physical cash or digital transfers acrosstelecommunication lines is entirely an aspect of

design. The design being based (hopefully) on theanalysis requirements and what the customermight like as a media for their transactionÐnoton what the of®ce guru, techno-nerd thinks is `neat'or on what the VP read as `the latest technology' inan ad in the last edition of Sports Illustrated.

Potential sources of success No. 2Ðidentifyingand categorizing the events in the organization, or`exposing the emperor'

All organizations have a set of events to which theyhave decided to respond. In re-engineering it isimportant to categorize these events.

If we conduct an accurate analysis of what theorganization and its mission are really all about,then during this analysis effort we will invariably®nd many aspects of the business that exist whollyto support the old design. This old design isusually outdated and, in many cases, has verylittle or nothing to do with satisfying the custo-mer's need. However, the old design will be anexcellent source of signi®cant improvement.

These aspects may include people groupings andtheir layers of management, bureaucracy, oldcomputer systems (developed based on who wasavailable at project startup time), and technologyand its maintenance structures. All of these aspectswill be discovered when evaluating the events inand around the existing implementation of theorganization. The events that support the olddesign we call system events.

Any organization `in business' (and that includesnon-pro®t and government organizations) knowsthat without any `customers' they are `out ofbusiness.' So the people who vote us allÐeventhe top dogÐin or out of of®ce are, of course, thecustomers of our products or services. The custo-mer may be someone who purchases our goods orservices, a taxpayer, a shareholder, a student, etc.

It is mainly at the customer interface with theorganization that we discover the events we callbusiness events. These and other ¯avors of eventsmust be `®ltered' by the re-engineering team.

I cannot do justice to the details of the ¯avor ofevents in this article, but let me caution you to:

. Remove strategic events (put them in a separatemodel);

. Be cautious to not re-implement old systemevents;

. Ensure that we identify and fully specify thebusiness events;

. Ensure that the regulatory events are still valid;and

Knowledge and Process Management RESEARCH PAPER

Knowing that the Project Clothes have no Emperor 265

. Use dependent events for potential areas of expan-sion and strategic alliances for the organization.

I have found that concentrating on the businessevents will invariably produce a successful re-engineering project.

A FEW WORDS OF WISDOM, OR `BECAREFUL HOW YOU TELL THE EMPERORWHAT YOU SEE'

The older an organization is, the more dif®culties itfaces in overcoming its own inertia. Any organiza-tion that ®nds itself in the position of needing to bere-engineered will already have a whole closet fullof historical/hysterical design aspects in place. Asstated previously, one major design aspect is theold system partitionsÐboth human and computer.These partitions will be the organizations' biggestobstacles to customer satisfaction and re-vampingor eliminating these partitions will also be themajor sources of improvements when you applyre-engineering principles.

On the other hand, if you don't have a longstanding organization in place and you're startingan overnight letter and package delivery system,then you have an excellent chance of improving onanother organization's old, perpetuated design fora letter and package delivery system that datesfrom the days of Ben Franklin. The scale ofopportunity (and therefore, the potential for drasticimprovement) is on a sliding scale of from 0 for astartup company to 100 for a large, establishedorganization. Please note, however, that the organ-izations that typically embark on re-engineeringprojects are not one-person startups.

Realize that we think very little about changingcomputer technology (e.g. batch to on-line systems)when it's out of date, but we resist incredibly whenchanging human technology (e.g. control struc-tures, work times, etc.). We predominately still usethe hierarchical human control structure put inplace by people such as Adam Smith (1700s) andFrederick Winslow Taylor (1800s).

I hope that any managers reading this can takethe lead in restructuring their own roles before it isarbitrarily done by someone else. Think of re-engineering as a legacy project and know that it cantake months and even years to fully implement(depending on the size, age, and traditions of theorganization). Re-engineering is not the quick ®x

that will make you the hero in the next quarterlyreport or this political term.

YOU'VE NEVER HEARD ANYTHING LIKETHIS BEFORE, HAVE YOU?

I have found that a re-engineering team made up ofdedicated professionals is always successful whengiven the requisite levels of support, resources,training, responsibility, and authority, and a clearproject charter.

These teams are typically made up of subjectmatter expertsÐbusiness people involved in thecurrent system, team support personnel, and afacilitator. I have seen many of these teams developsuccess-enabling, innovative solutions that arecustomer-oriented, cost-effective, and always sim-pler than whatever was in place in the oldenvironment. What amazes me is they often dothis even at the personal expense of having tosigni®cantly re-organize their own working roles.These `champions of re-engineering' put them-selves outside their comfort level and obviouslydeserve at least enough support to get the job doneright. These people accept the risk of questioningthe relevance of the organization's `clothes' andtheir own Emperor (i.e. the probable initiator of there-engineering effort itself).

A LOGICAL CONCLUSION

I'm not really saying that a re-engineering projectcouldn't fail, particularly when the people issues(such as resistance to change) are not addressed. SoI would like to ®nish with perhaps the mostimportant issue in re-engineering. This is the factthat we are dealing with people's futures. Wemustn't lose sight of the fact that re-engineering'sintention is to give the organization an opportunityto survive and prosper and add to the quality of lifeof both its customers and employees.

I hope this is obvious, but a good organizationdoesn't just abruptly stop the old system when thenew one is ready. It phases in new featuresÐespecially where people interface with the newsystem. This has proven to work quite well in thebanking system where manual tellers and autotellers are available for different customer'spreferences. We should be aware of this fact whenwe look internally at our organization. Ouremployees need the same consideration whenmoving from an old structure to a new one.

RESEARCH PAPER Knowledge and Process Management

266 B. Dickinson

The remaining grains in the balance betweensuccess (a.k.a., survival/satis®ed customers) andfailure (a.k.a., Chapter 11/dissatis®ed customers)rest with the organization's strategic planners whomust constantly be looking for new avenues ofbusiness and listening closely to their customersand their champions within.

I've `surfed' a number of industry fads over theyears, myself, but this one isn't a fad. What reallymatters now is that we have a signi®cant oppor-tunity to change things for the better with this re-engineering wave.

We must not allow ourselves to lose the realpotential of re-engineering by branding false re-engineering efforts as failures of the concept ofre-engineering itself.

So please, when you see a project mis-named as are-engineering project, tell someone who can make adifference (even if anonymously) before the clothes®nd that they have no Emperor. I would ask you toseize the day and keep your organization alive bytaking control of your own destiny and re-engineer-ing your organization into long term growth andcompetitiveness. I'll get off my `soap box' now.

Knowledge and Process Management RESEARCH PAPER

Knowing that the Project Clothes have no Emperor 267