Getting Back to Basics – Fifth Fundamental-Choosing the Best Modeling Technique for Success
In April, I began a series of articles devoted to the basic practices of business analysis. With so much information now available, I felt it was important to go old school and make a case for the core principles of the discipline and why they represent the best path to success.
Since beginning the series, I’ve talked about understanding business goals, creating a common vocabulary, identifying sources and choosing elicitation techniques. Now, in this final installment, I’ll be discussing which modeling techniques are most appropriate for a given situation.
Why We Model in the First Place
They claim a picture says a thousand words, but, in business analysis, it’s the opposite. The thousands of words you elicit from your stakeholders make up one picture representing a summation of disparate information. Modeling is essential for drawing a clear, accurate picture of a given project’s true business needs.
In addition, modeling helps you define your project’s scope and begin prioritizing the mountain of requirements you’ve gathered. A well-drawn model is a concise model, which will allow you to clear away the erroneous, redundant information that inevitably clouds your view of the path ahead. The types of models you use may very well address the different levels of knowledge and means by which a stakeholder can best articulate his or her vision or needs. For example, if you’re dealing with highly systematic thinkers and are eager to both elicit and validate requirements, you may likely choose to develop a variety of tables and checklists. Or, for more creative, big-picture, visually minded stakeholders, you’ll leverage story boards and use-case diagrams.
Four Classes of Modeling
Those new to business analysis-and, frankly, those not new-often confuse the terms model and diagram. A model represents information at the highest level, and diagrams are the tools that make up a model. Think of a model as a newspaper, and the diagrams as the many sections within.
Speaking generally, we could put all models into four categories. All four can and should be used to varying degrees for all types and levels of requirements. However, a trick for distinguishing them and determining when one is more appropriate than the others is to align the classes with five questions: Who? What? When? Why? How?
1. Structured Models
When the question is What?—as in, What is supposed to happen?–-developing a Structured Model is an effective modeling technique. An example of an applicable process could be: if an expense is approved via an online approval system, that request is then sent to a third-party payroll organization. The diagrams you could use to build your structured model in this case include a glossary of terms-which we discussed in the second article in this series-as well as domain and location diagrams. By using a glossary of terms, you can ensure the clarity of what is being used or what systems are involved.
2. Behavior Models
Behavior Models are the best tool for answering the Who? Who’s going to maintain a company’s Intranet site? Who’s going to act as a backup in the event that a technical expert is unavailable? Who’s going to be responsible for ensuring that monthly attrition changes are made to a company’s payroll system? This modeling technique can also answer a second question: How? How will a system be updated, manually or automatically? How will progress be reported up the food chain, by e-mail or directly during conference calls?
As the name indicates, we’re dealing with human behavior here, and, in the workplace, that usually translates to individual roles and responsibilities. Therefore, diagrams include behavior categories as well as process maps and use-case maps. Also, when creating a behavior model, don’t forget your stakeholder categories, which we discussed in detail in the third article in this series.
3. Control Models
Now, on to my three-year-old son’s favorite question: Why? Control Models tend to focus most successfully on justifying why something needs to be done, or why it is valuable to do something a certain way. And, quite often, the answers can be found in the business policies and rules that you’ve collected throughout elicitation. An organization’s individual policies, for better or worse, often determine the course of a project. For example: When an associate project manager makes a purchase request in excess of $10,000, that request will automatically bypass his or her direct boss and be sent to the head of the division. Why does this have to be done? Because, those are the rules, kiddo.
4. Dynamic Model
Finally, Dynamic Models, although not used as often as the other classes, are all about When? When will reports be generated? When will the first stage of the project be completed? When is this article due to BA Times? Dynamic Models will be made up of your most time-driven diagrams, which may include event tables or detailed timelines.
Best of Luck
And with that, our whirlwind back-to-the-basics tour has come to an end. I wish you luck in your future endeavors, and hope that you remember the value of our discipline’s basic best practices.
If, for some reason, you missed any of the four previous articles, don’t worry. The film version of the series starring George Clooney will be hitting theaters worldwide this fall!
Glenn R. Brûlé has more than 18 years’ experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI, he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. These engagements focus on understanding, diagnosing and providing workable business solutions to complex problems across various industries. Glenn was formerly a Director at Large for the International Institute of Business Analysis (IIBA) where he was responsible for forming local chapters of the IIBA around the world.