Business Modeling, Teenagers, and Primal Scream Therapy

I was going through my shed, looking for an autographed copy of Sonny Bono’s autobiography (long story), and came across a stack of old magazines from my IBM days, and thought I’d republish some of the still relevant selections. I co-authored this with my friend and company co-founder, Darren Pulsipher, who now works for Intel.

This article was originally published in the April 1999 edition of Rose Architect Magazine. Copyright © 1999 Rational Software and Miller Freeman, Inc., a United News & Media company.

Management of daily interactions with a demanding set of customers, internal or external, can be a time consuming and sometimes frustrating endeavor. An expanding project definition is a battle hard fought. The client wants more gadgets, faster processing time, less back-end management. I don't know about your clients, but mine seem to invite every other software vendor to give a presentation on the latest products -- after which I am buried under a barrage of phone calls and e-mails asking "Can our software do this too?" or "What would it take to add in this functionality?" or even "I've changed my mind about that piece -- I'm really more interested in
taking the software in this (new) direction."

Come to think of it, talking to customers sometimes resembles conversations with teenagers. What a fickle lot. How do you talk to a teenager, anyway? That's one of the questions passed down from generation to generation -- and one that may never be completely answered. It seems that each and every day is full of new problems, new adventures, and growing pains. I submit that the same is true with most customers, and I'd like to illustrate these similarities by analyzing four of the most prevalent issues affecting most projects (in no particular order): unrealistic timelines, scope creep, funding issues, and changes in technology decisions.

1. Unrealistic Timelines. Customers have been known to
   make requests with unrealistic timelines. While their intentions
   may be good, they are often unfamiliar with the process and
   tools necessary to complete the task, or they may not
   comprehend the impacts on your scarce team resources.
   Teenagers, on the other hand, are known to make unrealistic
   time estimates -- whether it affects your time or their time --
   when dealing with such topics as cleaning their room, mowing
   the lawn, or taking the family car out to "get some gas." In
   these situations, they clearly do not comprehend (if you're an
   optimist) or are ignoring (for those of us who are pessimists)
   the family ground rules.
2. Scope Creep. The dreaded expansion of a product or project
   where the definition has not clearly been defined and, more
   than likely, documentation is not being tracked. What usually
   happens is an agreement is reached on some limited
   functionality, but as soon as the project is underway, the scope
   falls under attack. Compare this to teenagers. No matter how
   clear you are on "house rules" or "family guidelines," teenagers
   will push definitions of the finer points of your instructions to
   the legal limit. Don't fall into the all-too-familiar trap of "You
   said to be home by 10, but you didn't specifically say 10 PM!"
   Most teenagers find safety in the "gray area" of even the most
   explicit statements, always expanding the scope of your original
   intentions.
3. Funding Issues. Customers want a Mercedes, but only want
   to pay for a Yugo. Who doesn't want the best possible product
   for the least possible cash outlay? This problem is usually the
   result of the aforementioned project scope creep. While the
   project definition gets tweaked, adjusted, expanded, altered,
   refitted -- whatever you want to call it -- rarely (if ever) is the
   financial support appropriately expanded. Do I need to even
   interpret the parallels to teenagers on this point? Let me put it
   this way -- how many times have we given our teenagers
   money for work and chores they should be doing anyway
   (cleaning their rooms, doing the dishes, etc.)?
4. Changes in Technology. One of my major fears is the
   perceived technological jump amidst a major development
   effort. Not that I fear change in general, or the wealth of
   technological leaps and jumps being made in many industries,
   but customers are often drawn like mosquitoes to a light bulb
   when a vendor plays the technology card. Even more applicable
   than the insect analogy is that of teenagers and any consumer
   product. They endlessly pursue the latest/greatest toy, gadget,
   or trinket. Hey, who am I fooling -- this is one problem that
   extends to all of us. We want the newest car, the latest
   fashions, and the fastest computer. Why would it be any
   different with our customers?

Seek First to Understand...
So what does all of this mean? Hopefully my somewhat entertaining depiction of the similarities between customer behavior and teenage behavior illustrates that both of these entities can be demanding, temperamental, and even illogical. Most of us can relate to some of these examples, having lived through them on a number of projects. Now that we've identified some of the major problems, let's discuss the process for obtaining solutions. How do we get past these barriers in communication, allowing us to fully realize our customers' needs and to build software that meets their requirements? Here's the secret -- you need to understand your customers (and your teenagers).

I know what you're thinking -- this is an over-simplified answer to a very complex issue. How does one "understand" a given project? Let me suggest that the answer can be gained through business modeling. The purpose of business modeling is to determine who and what the customer is -- but not necessarily the requirements of the project. The point is to seek to
understand the client's perspective, and not make any judgements about possible solutions or what the customer thinks he or she needs. We are not trying to identify the requirements at this stage -- the business model is the 'problem domain' while the requirements are the 'solution domain,' which come later in the development process. Instead, it is critical to know what you are building and why -- and yet this step is often downplayed. In fact, I would venture that business modeling is the most undervalued part of the software development process.

Let me put it to you this way -- a sick man enters a doctor's office with severe pain in his chest and abdomen. The doctor doesn't simply prescribe medicine based on the external symptoms the man is exhibiting. The doctor examines the patient, takes x-rays, and performs blood tests. Only when he
truly understands the cause of the symptoms does the doctor assign a prescription. And yet many developers dive right into solving their customer's problems without truly understanding the root cause. Business modeling begins much like that of normal system modeling, but we need to remember the focus is on the current state of the business -- i.e. the problem domain, and not the solution domain.

To further illustrate my point, let's take a look at how most development efforts begin. How often do we start the development of a system with the Use Case Analysis? While this is an integral part of the model, we really are putting the cart before the horse. Instead of thoroughly defining and understanding the customer and their mode of operation, we often create several use cases for what we perceive to be the customers' needs, only to have the customer come back and make changes later down the development cycle. This process of building blindly continues throughout the development of the system unless recognized and corrected up front. The result? Unrealistic timelines. Scope creep. Funding issues. Poor technology decisions. Ultimately, without understanding the business needs behind the system, your company will end up building the wrong product.

"7 Habits" author Stephen Covey hit the right note when he suggested the secret to communication is "Seek first to understand, and then to be understood." To fall back on my original analogy, the process of understanding your teenagers (and your customers) begins with listening. And I mean really listening -- not just to the words that come out of their mouths, but to the meaning behind the words. How often do we lecture our teenagers without actually listening to them first? Think about how easy it is to jump to the wrong conclusions when all of the pertinent data is not before us. As consultants, software developers, and managers, it is our role to anticipate the needs of our customers (as with our teenagers) by looking beyond the words and, like the doctor, revealing the illness behind the
symptoms.

Business modeling is a mechanism that guides you through the listening phase of your project, helping you to understand every part of the system being designed and to properly integrate all of the functions. The modeling process helps to organize the information gathered from the customer and/or the users of the system. The Rational Unified Process includes many steps and deliverables that, if met, will start you out in the right direction:

• System Glossary -- This living document establishes a common vocabulary for your project, and, if properly maintained, will prove invaluable to the success of your project. The glossary is developed from common words and phrases used throughout the business, and is regularly updated and revised by modifying use case names to fit those in the glossary, and vice-versa. Sometimes a word can be used to mean several different things -- this should be noted and tracked. Having a common vocabulary will strengthen communication. It is important that new terms are documented and presented to the customer as soon as possible.
• Use Case Model - This thoroughly describes the functional roles and processes of the current business. Just as in the normal system analysis, the use case model defines the boundaries of the problem by identifying the actors of the problem domain. Although it seems to be fairly simple, this step can take a considerable amount of customer interaction and communication. Don't get into the trap of making the boundary of your system too broad or too narrow. After the actors have been found, begin identifying the use cases that they use in the current system, and the interactions between them. Once use cases have been identified, scenarios need to be developed. Start with the most common scenario for the use case. Each use case should, at the very least, have its most common scenario developed. It is also important to describe the scenarios that you and your customer consider the highest risk. Don't forget to consult and modify the system glossary for consistency. You may, at this point, find it difficult to keep from jumping into the solution phase. Remember to model the current system, not the future system.
• Class Model - In the previous step of the process we defined the use cases and scenarios of the business and the problem domain. Each scenario has objects and messages between those objects. The next step is to segregate those objects into classes. Many times these objects will be deliverables, documents, or physical things that are currently used by the business and its processes. It may be beneficial to stereotype these classes according to deliverable type. Sometimes, depending on the customer, it may be beneficial to design an icon for the stereotype to aid in communication. Once again -- this should capture what is happening now, not what will happen later.
• Business Specification - Many times customers require documentation for the newly developed model. The business specification is the culmination of all of your efforts to understand -- the System Glossary, the Use Case Model, and the Class Models are the deliverables that define your understanding of the customer and his or her problems. The result of these steps should be a detailed description of what your project or process looks likes today. These pieces are combined into one document and used to convey your understanding to the customer, and, once ratified by the customer, is the foundation of the solution phase of the development
  effort. Use these to generate a document such that the customer understands you.

... And Then to be Understood
When focusing on business modeling, the key is to remember that you are not trying to solve the problem outright -- instead, your purpose is to meticulously capture and document the state of the business, therefore revealing a clear picture of the problem your software must solve. Now that you understand the customer and the customer agrees with your assessment of the current state of the system, it is time to work on the second half of Covey's equation -- how to be understood. Basically you go about this with the same level of detail applied to your efforts to understand the system. I highly recommend finding and following a well-crafted methodology and sound software development practices ... a topic for future articles.

More gadgets, faster processing time, less back-end management. Each and every workday can be full of new problems, new adventures, and maybe even one or two adjustments to the technological direction of your company (I'm still clinging onto past demons). The purpose of my customer/teenager analogy was to present the concept of understanding your customers -- and to illustrate that it all begins with listening. (Hopefully I have accomplished this.) Listening is not a problem if you understand the underlying motivations
behind your customer requests. If you can identify the current system first, your development efforts will more aptly deal with the unrealistic timelines, scope creep, funding issues, and changes in technology decisions that will inevitably crop up during the project. It would be naïve to think that this method is a catchall for every possible system issue -- but you will find that by taking the time to document the current system up front, many potential problems will be diverted, and your chances for success will increase exponentially.

By the way -- you're probably wondering where the primal scream in the title fits into all of this. Well, all I can say is that every project is different -- with some more stressful than others. For those few projects against which time and space seem powerless, I have found that driving to a remote part of town and screaming at the top of my lungs every once in a while can be very therapeutic. This also applies when dealing with teenagers.