Matters of great concern should be treated lightly.
Matters of small concern should be treated seriously.
— Tsunetomo Yamamoto, Hagakure
Stage 3 on the journey to enlightenment is Right Speech, and consultants, the modern-day gurus, flourish or fail based on the Right Speech. Every Sunday afternoon, aircraft rise from runways on the East and West Coasts of the United States, each winging for the opposite coast. These planes are crammed full of modern-day gurus, each consultant voyaging to give the same advice on the same problems to similar clients in similar situations on the opposite side of the Continent. Do they wave as they pass? Why are they called in? They must offer some truth, simple yet profound, and this chapter will initiate you into some of their Truths. Chapter 3 speaks of consulting, including some guru fads and some techniques every guru needs, such as getting consensus, and getting your ideas used.
When I thought I’d leave regular employment to be a consultant, I realized I might be asked virtually any possible question that could be asked about technological decisions. I worried that I would never be able to do that. But then I realized I needn’t worry. I know the answer to every possible question that can be asked about technological alternatives. Sounds impossible, but it’s not. As any successful consultant knows, the answer to every technology management question is: “It depends”.
What is the best database system? It depends. If you’re looking at a million-transaction database the answer will be different than if you are a single user on a PC. The essence of analysis is discovering the alternatives and what they depend on. What is the best application? It depends—on culture, and legacy and yes, especially politics. And you know what politics means. The word is formed from the Greek prefix Poly-, meaning “many”, as in polygon, many sides. And –tics as in ticks, which are “blood-sucking insects”. But seriously, politics will affect your project whether you like it or not. Just make sure it doesn’t override technical reality. As Geoffrey James tells us in The Zen of Programming:
Never Base a Technical Decision on Political Issues
and
Never Base a Political Decision on Technical Issues
The fact that there are no firm answers can help you proceed in the face of uncertainty. Late one night a Vice President was questioning the DBA and me as we made various attempts to fix a vexing problem that brought our DBMS down. “Do you guys know what you’re doing?”
“Of course not, but we’ve never let that stop us before!” we both said simultaneously.
As a systems analyst you must deal with the feelings of ambiguity and uncertainty you’ll encounter. My students are skeptical when I tell them that in my career, about half the time I did anything, and almost every time I did anything cool, I didn’t know what I was doing at the time. We computer experts have a bag of tricks to use when we don’t know what we are doing (which is most of the time), and that’s what I used. The secret to systems analysis serenity is understanding that simple ignorance is not a problem, and relaxing. Trust your knowledge and intuition: Embrace contradiction, feel your way along, and blunder through.
Ambiguity is always present in the life of an analyst. You must be able to deal with it, give it your best shot and proceed. If the answers were clear, they wouldn’t need you. Sometimes the uncertainty is caused by incomplete information, and if you can correct that do so, but often you can’t. So you must embrace contradiction and use it to your advantage. Ikujiro Nonaka and Hirotaka Takeuchi point out in their HBR articles, and in The Knowledge-Creating Company: “Ambiguity can prove useful at times not only as a source of a new sense of direction, but also as a new source of meanings and a fresh way of thinking about things. In this respect, new knowledge is born out of chaos.” They point out Japanese companies intentionally use ambiguity and fluctuation to cause “Creative Chaos”. A team can be driven to a state of “zero information” where prior knowledge doesn’t apply. Over time, the process begins to create its own dynamic order from ambiguity and fluctuation.
Simple ignorance is not knowing what you’re doing, and is fine, in fact normal. Profound ignorance is exceedingly dangerous, sometimes deadly, however. In profound ignorance, you don’t know that you don’t know. That’s why it’s important to distinguish between what you know, and what you don’t know.
The Only Thing Known for Certain is
Nothing is Known for Certain.
There is a difference between offering your advice and getting it used. Being right doesn’t mean you’ll be listened to. My book on Y2K, Solving the Year 2000 Crisis, was about the only book published that correctly predicted Y2K would not be that big of a problem—but it was greatly outsold by books predicting TEOTWAWKI: The End of The World As We Know It.
Most of you have been frontline workers (“individual contributors”), some have led teams or projects, and all are contemplating consulting. What’s the difference between a worker, a supervisor, a manager and a consultant? There is a subtle difference between these roles, highlighted by how each is properly evaluated. Workers should be evaluated on their performance. Supervisors should be evaluated based on the performance of other people, namely the people who report to them. Managers on the other hand, should be evaluated based on the performance of other people, particularly people who do not report to them. Users, DBA’s, vendors, and myriad assorted technicians and reviewers all play a critical role in the success or failure of your project. Most of these critical players do not report to the manager in charge of the project. Yet if any of them fail, the project fails, and you fail, too. For a consultant, it’s even worse—you will be evaluated based on the performance of the people you report to, to wit, them that hired you. So the higher in the chain (assuming you’ll accept “higher” is the right word) the more your success is judged on influencing events despite the fact you have no formal, direct power. It’s a matter of the balance between authority and responsibility.
In an ideal situation, authority and responsibility will be equal. If you have the responsibility to do a task, you need the authority to get it done. Responsibility without authority can be uncomfortable. Even worse is authority without responsibility. In this case someone interferes and requires you to do some fool thing that causes your project to fail, but then takes no responsibility for the outcome. For the consultant, Authority and Responsibility don’t balance by definition, so take care. You have no formal authority but complete responsibility: it will always be your fault if a project you are on fails. Both perceptually, since observers will blame it on you, but also in fact, because as a consultant you’re supposed to anticipate and head off failure.
Everyone might not be able to see it from your angle at first, so you might need to stand alone for a time: Sometimes everyone later agrees with what at first they thought was crazy. Many movies about juries illustrate this, one lone stubborn juror, as in Twelve Angry Men, eventually convincing the others they were wrong when they were initially certain the defendant was guilty. On the other hand, you must also follow the Middle Way: once you have stated your opinions eloquently, if your idea isn’t accepted, it’s time to shut up and do what the client wants. Remember the Golden Rule: Whoever has the Gold, makes the Rules.
No book themed on Japanese concepts would be complete without some quotes from Japan’s greatest business guru. Japan’s greatest guru is not some aesthete who lived in the mountains pondering his navel. Surprise: He’s not even Japanese, but American! The most respected business guru in Japan is none other than W. Edwards Deming, 1900-1993, who went to Japan in the Post-World War II Occupation era and taught the Japanese about Quality. At the time, Japan was stagnant after its crushing defeat in World War II, and “Made in Japan” was synonymous with “cheap and flimsy”. He conducted his first seminar in Tokyo in July 1950, just after the outbreak of the Korean War on June 25. In gurudom, timing is everything, and his timing was superb. Japan had been an industrial power before the War, but had had much of its industrial base destroyed and had not yet rebuilt. The Korean War was called by some a “Gift from the Gods” to Japan: the war in Korea brought huge orders for goods to Japanese factories, of which the president of Toyota said: “These orders were Toyota’s salvation”. John Dower, in Embracing Defeat notes: “This almost serendipiditous conjunction of desperation and opportunity enabled Deming’s Japanese admirers to integrate his ideas about quality into the inaugural stages of new production cycles and new entrepreneurial ventures in ways that would have lasting consequences over the ensuing decades.” So Deming taught the Japanese how to incorporate quality into an economy that was practically rebuilding from the ground up during an economic boom.
[ [ [
Deming is famous for his Fourteen Points, many of which are quite applicable to systems development, so we’ll refer to him again. In his book, Out of the Crisis, he also lists some obstacles to attaining his management philosophy, several of which are also useful to the analyst. Below are some of Deming Sensei’s principles in bold, with my interpretation of what they mean to systems analysts:
Hope for instant pudding. This is usually referred to in systems as “No silver bullet”, after the ACM article of the same name by Frederick Brooks. You don’t just “adopt Quality”, “get CASE tools”, “become Object Oriented”, or “Install CRM” and magically solve all problems and fix everything. Fads constantly offer various purported silver bullets, most of which weren’t even lead bullets, but paper bullets.
The supposition that solving problems, automation, gadgets and new machinery will transform industry. We love our technology, so sometimes we adopt technology for technology’s sake. Deming points out that “computation of savings from use of a gadget (automation or robotic machinery) ought to take account of total cost, as an economist would define it. In my experience, people are seldom able to come through with figures on total cost.”
Search for examples. Cookbook methodologies and benchmarking are examples of this trap. If it worked at XYZ company it will work here, or “Oh good, we have a methodology, we can all turn our brains off and stop thinking!”
Obsolescence in schools. Lifelong learning is the name of the game in systems development, and it’s hard even for the schools to keep up. You will want to consider institutions like university extensions, which attempt to keep on the cutting edge. The University of California Extension courses, for example, are usually taught by practitioners current in the field, sterling examples such as your humble author, who strive to keep up with the latest developments. Most university academic courses are, well, academic, and often behind the times.
False starts. Don’t join the Methodology of the Month Club. This happens when you don’t stay with a new methodology long enough to realize any benefit. Some companies happily embrace the fad of the moment, and never actually recover the innovation costs of one methodology, tool or package before going on to the next.
The unmanned computer. The computer can be a curse or blessing. But you must still use your brain. Users too often accept the word of the computer as unquestionable truth, but programmers, who of all people should know better, sometimes do that, for example with CASE tools and code generators.
The supposition that it is only necessary to meet specifications. Deming cites an example of a programmer: “She learns, after she finishes the job, that she programmed very well the specifications as delivered to her, but that they were deficient. If she had only known the purpose of the program, she could have done it right for the purpose, even though the specifications were deficient.” You should be able to explain why any feature makes sense from a business perspective before putting it into a system.
Inadequate testing of prototypes. ‘Nuff said.
[ [ [
Deming is associated with Quality with a capital Q. Deming’s impact is profound, not just on Japan but the entire industrial world, although a little out of favor. He is associated with Japan, which is down, but not out, so Quality is, too. With what is called “the Bubble Economy”, Japan has lost some of its luster—even my bank, formerly Sanwa, has been acquired by a French bank and has lost its venerable Japanese name. Things Japanese do have a plus, though: they’re part of American (or Global) pop culture now—sushi, karate, anime, etc. are all commonplace in the USA. Notice Spellchecker accepts such Japanese words as kaizen and keiretsu, indicating how many Japanese business concepts have been adopted into business English. So “Quality is dead, long live Quality!”
Kaizen is the Japanese word for the concept of continuous improvement. Its central tenet is that you must continuously improve your processes to keep a quality product in production. Not just because you can always get better, but because “better” is a moving target. What’s Better? It depends on what quality is: McDonalds is quality to a kid, who would find a fancy restaurant unbearable. Quality is what the customer wants.
Which is faster? A jaguar, an antelope or a human? It depends on the distance. A jaguar is faster than an antelope for about five seconds. The cat will go hungry if it’s not able to catch the antelope in a sort burst of a few seconds. And over a day a human is faster; that’s why humans can hunt antelope and jaguar: the animals can run faster, but can’t walk farther, than humans.
When the Bureau of Labor Statistics tracks price changes for the Consumer Price Index, it attempts to measure changes in price, not quality. They try to factor out any nominal price change attributable to quality improvement. For many years, when the retail price for a particular make of automobile went up, the manufacturers explained the increase as a quality change: “This year’s model is bigger than last year’s!” Reasonable enough. But then came the gas crisis, and the manufacturers explained the subsequent price increases as quality changes: “This year’s model is smaller than last year’s!“ At first blush it sounds absurd, but it actually makes sense. For many years “bigger is better” was the guiding principle, but conditions changed and “small is beautiful” became the new cry. Continuous improvement is necessary just to stay in the same place.
Even our management and technical techniques need kaizen applied to them. We must continue to strive for better ways to manage our processes or quality will deteriorate.
In the San Francisco Bay Area where I live, the mass transit system is known as the Bay Area Rapid Transit System, or BART (pronounced “Bart”, like the male name). Most riders refer to the system as Bart, and say things like, “Let’s take Bart to the concert”, or even use Bart as a verb: “I Bart to work.” My girlfriend, however, always says: “Let’s take the train to the play”, or “I took the train into San Francisco to go shopping”. To most Bay Area residents, this sounds strange, since “Bart” is almost always used to refer to the train, but Lily always says “the train”.
Why would she use this uncommon nomenclature? Because she worked at BART. Only from outside does the train represent BART, and since Lily worked at the Bay Area Rapid Transit District, she and her co-workers needed to distinguish the parts from the whole. After all, if you called BART’s legal department you might have spoken with Lily, and if you did, you might later quote her, saying, “BART said ….” From your perspective, Lily could be “BART”. In analysis it is always important to consider perspective. Each role, department, and even person has a perspective that must be considered when analyzing systems. For example, the Purchasing Department’s requisition becomes Receiving’s shipment and Payables’ invoice. What to the Shipping Department is an order, to the accounting department is a receivable. The receivable represents the order to the A/R Department; it could be the same entity, except a different group of people care about it, and so it is usually a different entity. Also note that from an accounting perspective, if IOU, my liability is your asset. A worker can be an employee, or a contractor. The manager, the IRS, and HR all see this differently.
Try to walk in everyone’s shoes
Each analysis technique is driven by a certain perspective. So what’s the best perspective? In the beginning, all computer programs were process-driven. Then along came Data Base Management Systems, and we became data-driven—for a time, it was fashionable for Data Administrators to proclaim themselves “data bigots”. Just about everyone now agrees that both process and data are essential, in fact we once called our profession data processing, but how to bring both data and process into the equation? The extreme was to bring the procedures and data together into objects, and become object-driven. But even object gurus disagree on whether we should be driven by the objects: the UML object modeling technique as described by the Three Amigos, led by Ivar Jacobson, is use-case-driven, and Peter Coad has become feature-driven. So how about business rules? USoft was business-rule-driven until it was driven out of business. Workflow brought other possibilities. The first workflow tools were document-driven, while current tools like SAP are event-driven. Of course your eventual goal is to be chauffeur-driven, but to get there you need to design the right system. And to do that you need at least two views, one on the data and one on the process.
You can usually learn more if you take several different perspectives. In modeling, you want both a data model and a process model, or both a class diagram and use cases. Looking at a situation from both the perspective of the East and West can also bring surprising results.
Always analyze from at least two angles.
There is a story, probably apocryphal, about a doctor and a witch doctor. The doctor was bringing modern medical knowledge to a primitive village. When a young colonial administrator and the old physician arrived at the village they were surprised to find the village chief had called the villagers together to allow the two doctors (medical and witch) to enlighten the villagers in turn. The witch doctor went first.
The shaman described a disease that was obviously what we call smallpox, and explained how it was spread: the evil eye. People who have smallpox will, through no fault of their own, give you smallpox by looking at you. If you see someone with smallpox, friend or foe, get out of eyesight as quick as you can.
He described the disease we call malaria differently. It is caused by bad air at night. You should avoid swampy areas, cover up arms and legs, and close windows at sundown, to keep the bad air away.
He went on to describe a number of other diseases that plagued the area with equally preposterous explanations and precautions.
And so it was the turn of the real doctor to speak. The doctor was world-wise, having spent many years in various remote parts of the world, so what he said flabbergasted the ambitious young administrator: “Your witch doctor is very wise, listen to him. He and I have much to learn from one another, and I hope we will be working together to keep you healthy.”
Afterward, the administrator excoriated the doctor. “How could you possibly allow such tripe to go unchallenged?”
“Because,” said the doctor, “if you believe what the witch doctor said, you will do the right thing.”
You see, smallpox is only spread by its victims. If you never come within eyesight of a smallpox victim, you will never catch it. And malaria is spread by mosquitoes that travel in the night air, and so if you avoid the "bad air" you will also avoid the mosquitoes and thus the disease. (Incidentally, “Malaria” literally means “bad air”, because Europeans also once thought bad air was the cause.) And so on for each of the explanations the witch doctor had offered.
[ [ [
It is quite often possible to have a completely erroneous conception of how something works, and yet still be able to use it completely well. An example of an erroneous explanation is most people’s understanding of a thermostat. When they come into a cold room, they turn the thermostat up full blast to heat the room as quickly as possible. In fact, the thermostat is actually an on/off switch, the heater is either on or off and the setting has no effect on how fast the room will heat up. The same is true of ovens. In this case, the user’s misunderstanding does cause some extra work, since it’s necessary to adjust the thermostat after the room heats up, but the cost is slight and so no real harm is done.
There was a woman whose TV would go on the blink whenever a bad word was said on television. The repairman took it to the shop and experimented with it. It turned out that exactly one hour and five minutes after it was turned on the TV would overheat and short out. It turns out the lady always turned on her TV at 10:00, and at 11:00 Divorce Court would come on, someone would say “adultery” within the first five minutes, and the TV would go on the blink.
You can be wrong about the question
but right about the answer.
In some cases the consultant will be most successful by working indirectly. It is not always best to take the most direct route, but to harbor an Ulterior Motive. Here are some examples of the Ulterior Motive at work.
I once worked on a team where one of the contractors, let’s call him Karl, was the darling of the managers. “He is the only one who always completes every assignment on time! Look at his status reports, every target date completed on time, like clockwork.” Those of us that worked on the team with him knew this to be true. He indeed reported virtually every target date completed on time like clockwork. But since we had a policy of 100% testing of all programs by another programmer, each of us on the team had received Karl’s work to check, on the target date, and had learned to set it aside for a week. Karl would be furiously working on the program after he had “finished” it, so you could be sure the program wouldn’t run at all if you tried to test it the day he turned it over to you.
I was later promoted and became the manager of a team that included my old buddy Karl in it. As expected, his status reports always showed everything done on time. So what did I do about this? It might surprise you to hear I resisted the temptation to embarrass him. I realized the “reported as done” task actually served the project’s purposes. As they say, the prospect of your death tends to focus the mind incredibly well: Karl would work furiously to complete those tasks, and if the actual work lagged the reported completion by a few days, there’s not a real problem. What I decided to do was keep my own secret project plan on which I added a week to all of Karl’s tasks.
In What Do You Care What Other People Think?, Richard Feynman relates his experiences on the commission investigating the Space Shuttle Challenger Incident. Shortly after he was appointed, he got a call from another commissioner, Air Force General Donald Kutyna. During the conversation about commission matters great and small, the General mentioned he had been working on a carburetor and he just wondered what effect cold would have on an O-ring, something that was in both the carburetor and the space shuttle. This started Feynman thinking: “That was all he had to tell me. It was a clue for which I got a lot of credit later, but it was his observation. A professor of theoretical physics always has to be told what to look for.”
As you probably know, the tragedy was caused by cold temperature leading to the catastrophic failure of an O-ring. Feynman spends the next eighty pages of the book entertaining us with how this chance insight led to the discovery of the cause of the accident. And then he reveals that he later discovered that General Kutyna had in fact known there was a serious problem with the O-rings all along, because a friend inside NASA had tipped him off. The General’s dilemma was how to get this critical information out without jeopardizing his friend. “His solution was to get the professor excited about it, and his plan worked perfectly.” Machiavellian? Yes. But it worked.
Everyone in sales knows this one. When you’re trying to persuade, get out of the subjunctive and into the active! The subjunctive voice is used to express things that might (“If I were a Rich Man”) happen, while the active voice expresses what will happen (“When I am a Rich Man”). If you want something to happen, speak about as if it already has. Assume you’re vying for a consulting gig. Don’t keep saying “I would do such and such if I get the job”, say “I will do such and such”. Sometimes this sounds presumptuous, so be careful. But if once the client slips into active voice, switch into the active voice and talk as if you already have the job.
Sometimes, you need to look beyond the purpose of the immediate task. An example of using brainstorming for an ulterior purpose is demonstrated by two contrasting approaches to brainstorming. It is not always true that the best way to do a job is to do each part in the most efficient way. I generally prefer a brainstorming session to be a wide-ranging free-for-all. Everyone should yell out their ideas spontaneously, and let the creativity flow. I measure my success in teaching brainstorming by the number of complaints I get from neighboring classrooms: they hear noise, I hear learning.
My friend and co-author Alec Sharp prefers the more structured round robin method. He has each person take two to five minutes to think silently about ideas, i.e. to internally brainstorm. He then goes around the table having each person present a new idea in turn. It’s okay to “Pass”; especially after you’ve gone around a few times some people will run out while others still have ideas to present. He agrees with me his method is not as spontaneous, and probably doesn’t encourage the most innovative thinking. Why does he do it then? Because his goal is to get everyone involved, especially the first few times with a given group. It also helps him get to know the members of the group. So he looks beyond the immediate—brainstorm a list—to the long-term— a smoothly functioning group.
Understanding consensus is key to consulting: What it is; when you want it; and when you have it. Consensus is a part of “Japanese Management”, or Theory Z, in the title of William Ouchi’s book. Consensus is desirable when you want a sense of involvement and need commitment from those involved. Consensus is achieved when each group member can honestly say to everyone else:
Consensus is achieved when each can say to every:
1. I believe that you understand my point of view.
2. I believe that I understand your point of view.
3. I will support the decision, even though it is not my first choice.
First, everyone must feel he had a chance to express and discuss his concerns, and that he was given a fair hearing, so they can say “Whether or not I prefer this decision, I will support it, because it was arrived at in an open and fair manner”. As with all business meetings, it should be understood that “Silence is Assent”. If you don’t object to a decision, you are indicating agreement with the decision, without the necessity of formally polling the jury.
A Rule for All Business Meetings
Silence is Assent
If you don’t Agree, Say So!
Second, each person feels he can support the decision, even if it is not his first choice. Sometimes the word is misspelled as “Concensus”, with a ‘C’ instead of an ‘S’. This highlights a common misunderstanding. Consensus’s cognate is Consent, not Census, so all are giving consent to the project, not voting on their favorite choices. They are saying: “I can live with this choice”.
Knowing when not to seek consensus is as important as when to seek it. Consensus is not appropriate when there is a single answer; for example, don’t seek consensus on whether or not a file can be transmitted over a network in less than one minute. That’s a case where a test is in order, or seek expert opinion if a test isn’t possible. Consensus would be appropriate as to how fast a transmittal must be to satisfy the users. If you want commitment and coordination, seek consensus, but remember it is slower than other methods.
To Gain Commitment, seek Consensus
If there is One True Answer, get Expert Opinion
If you need it Fast, Appoint a Dictator
Watch out for appearances. I had an enlightening experience with a consultant working for me. He very generously invited me and several other employees to lunch at an expensive restaurant, ordered us an expensive wine, and tipped the waitress lavishly. But since he was from out of town, we were paying his travel expenses, and, yes, you guessed it, the lunch bill was attached to his invoice with a claim for reimbursement! I certainly lost respect for him because of this incident, and he was never used again. There were other factors affecting that decision, but this incident was definitely floating in my subconscious when I needed another consultant.
Compare this with this experience. I was once on a consulting assignment when I nearly blundered at the car rental kiosk. It happened they were running short of economy cars, so they offered me, at no additional charge, a beautiful red convertible instead of the economy car I had ordered. I almost accepted, and then realized how bad this would look. Since I was traveling, my travel expenses were paid by the client, so when they saw me in that car they would think I was taking them for a ride.
On another occasion, appearances didn’t matter. I gave some seminars in the LA area to the general public, under the auspices of City National Bank—if customers of “the Bank of the Stars” can be called “general”. City National’s milieu is demonstrated by the accommodations I was provided as one of their visiting vendors. They provided me with one of the cheapest rooms they had in their booking system: a suite in the Beverly-Wilshire Hotel (think of the movie Pretty Woman) in Beverly Hills with a balcony overlooking the pool! The suite naturally was equipped with a fax machine, in case I needed to do any movie deals while enjoying the view. Consulting does have its rewards, and in this case accepting them was fully consistent with the client’s corporate culture.
Copyright ©2003, 2008 Patrick McDermott