A business run without a system is like a car driven by a man with short-term memory loss, continually having to guess which pedal is the brake, the gas, and the clutch. It will, most likely, eventually, and with luck, go forward, but the passengers aboard will not find the ride comfortable or smooth. And if the environment the car is in is a fast-paced, highly-competitive Philadelphia freeway, then the passengers may not even survive.

I worked for a number of years across the street from what in the flower world would be called an “annual” cafe. It flowered approximately once a year, under a new name, with new owners, and a new, though usually similar, menu. The owners tried a number of different tactics–higher prices, less food, catering, advertising–but they all had one thing in common–they did not have a system. These folks served excellent food. I drooled over their burgers–yet the McDonalds down the street made more money than them. They did not have a system for ordering, for buying food, for cooking the food, for serving the food, for obtaining customers, for retaining customers–they figured “make it good and they will come.”

In the United States, the overpasses must be 14′ from the road way in urban areas, and 16′ in rural. It’s odd that they wouldn’t standardize on one–in fact, many people might be downright angry at a system with dual standards. I don’t know the historical background to this, or what competing factions had to compromise to get there. One thing is for sure, though–it is better to have something for the truck manufacturers and the freight carriers to rely on than to make no system of standards at all.

Lazy people have an edge over the more hard-working among us: they tend to do the same thing that barely worked last time. This, over time, multiplied by many lazy people working in concert, will mean that eventually some sort of ad hoc system will emerge. It will not be the best, it will not be perfect, and it may fail at times, but it will be a system. An unorganized, but hard-working group of people, by contrast, will have a tougher time. They will realize that the way they did it last time didn’t work so well–that maybe it barely worked at all. So they decide to try a different way, which they believe will work better. A local auto repair I use is like this–they are excellent, hard-working mechanics, who charge less than most and are completely honest, but they struggle to deliver on time, and have problems with cash flow, billings, and customer retention. They keep changing things, trying new methods, working ever harder, and generally staying fairly disorganized.

The lazy people would be helped by consciously putting together a system that works, instead of having a system emerge on its own–by the time the system emerges, it may just be too late. And the hard-working ones would be helped by realizing that consistency, even in a flawed system, can be helpful.

Don’t wait until the software you’ve just purchased for 50,000 dollars is configured exactly the way you want it, and don’t wait for all the users to be bought in. Don’t make the mistake of thinking that change for change’s sake is a good thing. Don’t think for a second that you couldn’t be helped by having some sort of system–software or hardware or practices or procedures–that would help you in your work. But remember that perfection is the enemy of the good. Get something going, and then change it incrementally, in thought-out iterations. But just get it going!

Stability v Change

September 9, 2010

Are stability and change mutually exclusive? Is it possible to create a stable, changing system? Can you reinforce the value of a stable product or environment or business without sacrificing the ability to change?

The UAW feeds on people’s desire for stability. They promise a stable wage with stable benefits while working at a stable job. This is immensely appealing for the workers in the system–especially those who’ve been shocked or betrayed by unscrupulous employers.

Our political system feeds on people’s desire for change. People want forward progress, they want something to be done, and they want to feel like they are part of something new. The “swing” voters are quickly “disillusioned” which leads to a shift in power from left to right, or vice-versa.

Often times laziness or complacency is disguised as stability. Low turnover in a company may mean that the people are content and there is stable management–or it might mean that the company is suffering death by ambivalence. Software programs that were written for MSDOS in the ’80s and are still used today represent stability–they also may represent a lack of IT know-how.

People (especially managers) often use unprincipled change as proof of progress. Switching to an Oracle ERP system in a 50 million dollar company may be more about showing that the company is technologically savvy than about positive change. Buying new automated robots to machine the parts may be more about impressing the tour visitors than about cost savings.

In a single, small piece of software, stability can be surprisingly hard to come by, especially when written by an inexperienced or unskilled programmer. But stability becomes exponentially harder to achieve the more complex the software becomes–each component has to successfully interact with every other component. Further, as the system becomes more complex, it becomes more and more possible that an individual change will cause instability-which in turn causes change to become harder. And here’s the central point: COMPLEXITY INCREASES THE POTENTIAL FOR INSTABILITY AND DECREASES THE POTENTIAL FOR POSITIVE CHANGE.

Don’t mistake instability for positive change, and don’t mistake lack of change for stability. Don’t associate complexity with grandeur. Just make sure your system is simple, doesn’t break, and can change easily–easy, isn’t it?

There are all sorts of situations where a single localized optimum equals overall badness:
  • A top-of-the-line video card that is the best in the world but hogs so much computer resources that the other components are starved.
  • A project manager that is the best at getting the best employees to work on his jobs, so the company’s other jobs suffer.
  • A factory that cheaply produces 10,000 gadgets when the market only wants 5,000.
  • 10 salesmen hoarding information to ensure their coworkers don’t get the commission.
  • A customer service representative that is so highly trained in answering phones that she isn’t capable of pinch hitting for a sick coworker in shipping.
  • An electrical grid that optimized to the T for the current system load, but doesn’t allow for growth.

We cannot confuse individual components’ good work with a system working well. We have to realize that in a complex system, parts must have their individual ups and downs in order for the whole to benefit. Consider:

  • A lawyer who spends 50% of his billing hours in a month on pro-bono work.
  • A pharmacist who spends 25% more time checking prescriptions for errors when a new drug is introduced.
  • A rolling operation in a steel mill that produces only just enough 3/4″ plate, resulting in more set-up time for the week per ton

We must as good system managers reward and encourage a tribal mindset. We have to help the people-ness of our people get out–because people, when allowed to, will sacrifice for something bigger then themselves if they feel they are a part of it.

This idea is almost unheard of in our capitalistic mindset–in the 5o’s, it may well have labeled me a communist. But why should we reward workers or managers for local results when those very results might be restricting the performance of the whole? Why would we reward project managers based on an individual projects profit if that profit was achieved at the expense of other projects? Why would we commend a factory boss that has produced it’s portion of the widget very efficiently, but in so doing has neglected to consider the cost of storing 100,000 efficiently-produced items? Why would we pat a software engineer on the back for elegantly-written code that does not talk well to the good-enough code of the rest of the department?

Rewards and commendations and pats-on-the-back should be used when the system as a whole advances, not when one part advances independently. The dog sled is not much better off with a single dog that is twice as fast as the rest.

But wait! Am I telling you to reward conformity to a system??? No, no, a thousand times no! I have stated before and will state again that the system that will prevail is the system that can and will change. But it is extremely important to communicate the system values, the system goals, the system objectives, to all the players in the system, and then back that communication up with matching actions.

Implementation Fatigue

May 11, 2010

The main danger that a company faces in implementing a new system of any sort is not budget overruns or schedule delays, or even a poor end product. Rather, it is that the intended users of the system do not actually become users. Though there are many causes of this disconnect, one theme that runs strong in modern corporations is implementation fatigue.

Imagine this scenario: a gung-ho college intern suggests a company use Twitter instead of email for everyday communication between field employees, the corporate office, and key customers. Incredibly, upper management buys in, and all the employees, some of which are nearing retirement, are taught to use it, with varying degrees of resistance. Two months later, upper management cans the entire system and instructs all employees to return to using email. Meanwhile, the engineering department, in coordination with the marketing department, finishes a year-long project to modify an existing CRM product for use company-wide. How does the first (the Twitter debacle) impact the second (new CRM)?

People aren’t, as a general rule, resistant to change–provided the change is well planned. But a well-planned change can be negatively impacted by a change immediately prior to it. Furthermore, the amount of time spent in transition is more important than magnitude of the change.

Here are some things to think about when planning change:

  • An earlier change always negatively impacts a future change
  • The negative impact of a failed earlier change is exponentially worse than a successful earlier change
  • Two sequential changes of size x are harder than one change of size 2x.
  • Reducing the amount of time spent in transition dramatically increases the likelihood of success

All the above require a well-thought-out plan of which changes you will make to what and when. The more willy-nilly your implementation is, the less likely it is to be accepted and used, regardless of how good the change is technically.

A quote from Eric Evans, a software systems designer:

The thing [our clients] bring to the table is this extensive knowledge of their domain. The thing that we bring to the table is the clarity that we think with. I don’t think our primary thing we bring to the table is our technical competence, although we need that. We need to be good enough to know how to do the implementation. But the thing that we bring that’s really critical to the process is we think sharply. We are able to abstract and we are able to define things crisply. —Eric Evans

I agree with Eric–to be effective in your position, you must have clarity in your thinking. However, you also must “think sharply” about planning the implementation. Define the plan crisply. Plan for who you will introduce to which features when. Identify what can be to done reduce the amount of transition time. Wait until the time is right. Then move in and get it done.

A system is good when the design and implementation phases of the system are well thought out.

A system is good when the users of the system buy in.

A system is good when the stated goal is clearly articulated to anybody who interfaces with the system.

A system is good when the perception of the system is positive.

A system is good when change is built-in.

A system is good when it advances the goals of the team or organization.

Think about your frustrating experiences interfacing with business systems, for example poorly designed, poorly implemented, or abused phone queuing systems. (Press one for English. Press five to wait on hold indefinitely. Press 384 to listen to our overly-optimistic voice tell you yet again that a customer service representative will be will you shortly). When this system was designed and implemented, was it well thought out? What was the stated goal? What’s the perception of the system? Does the system change to reflect changing business goals?

Now think about the systems you use that are so ubiquitous and pleasing that you don’t even think about switching, say searching with Google. Google, the verb, has become so common in the English language that it takes care of several of the points above: the goal is obvious, the perception is positive, and people buy in. The goal of the company, to “organize the world’s information,” is simplified into one text-entry box under one logo. The design and implementation was excellent when it was launched and it continues to change and grow to stay at the top of the pack.

The systems you live in and work in and are building and are fighting against and wish existed and wish never existed should be examined to see if they are good systems. Examine them with an unbiased eye. Communicate what could be better about them. Determine if spending your political capital, money, or attention on that particular system is wise. Then act.

Definition

March 17, 2010

Dictionary.com defines a system as “an assemblage or combination of things or parts forming a complex or unitary whole” or, as it pertains to computers, “a working combination of hardware, software, and data communications devices.” These are both good definitions. They both capture the essence, in a succinct way, of the word. But I would like to add my own definition as it pertains to business and particularly, business success:

System: (n) [sis-tuhm] A series of interlinking parts, processes and people designed to work together to advance a stated goal.

In a for-profit business, the goal must be to make money for the shareholders. If, along the way, you accomplish other important goals (help the environment, increase employee prosperity, promote your community) then it is all well and good; however, these must follow the goal of making money. The business system, then, must work in such a fashion to increase shareholder profits.

Any time you have a business, no matter the size, you have a system. If your business is profitable, and it will continue making money in the near future, you have a system that works. But you don’t have a perfect system. I don’t have a perfect system. Nobody, not even McDonalds, with their system wizardry, is perfect. Perfection, in fact, is the enemy of the good. A business system that will survive not just in the near future, but indefinitely, is desired–and the only way to accomplish this to constantly correct it. Change it. Modify it. Help it along. Analyze it. Question it. Ask your people their opinion on it. Think about it. To rephrase a commonly-held business belief: if a business isn’t changing, it’s dying.

The paradoxical thing about a good system is that change is built into it. A good system, for example, is outlined by our Constitution–it not only laid out the beliefs held by our founding fathers on the proper governance of a country, but change was also built in. It allowed for constitutional amendment. It allowed for the fact that it wasn’t perfect; in fact, it wasn’t designed to be perfect. Business systems are no different. You must build an amendment provision into your system.

Competition changes. The law changes. Employees and vendors and customers change. Your entire business environment can and will change. Build a system that works for your customers, for your business. And then change it.

%d bloggers like this: