Skip to main content

Embrace Change, But Make Sure It’s for the Better

“Embrace change” is a useless platitude mouthed by managers or motivational speakers who have not thought through its full implications – or they are masochists who enjoy suffering. Changes that bring new opportunities or propel us forward are easy to embrace. But many changes look quite negative and are tough – if not impossible – to welcome. This list might include loss of a relationship, a loved one, health, job, money, and such.

We usually don’t choose the difficulties or negative changes that spring upon us. But we always choose how we respond.

Above or Below the Line: It’s a Critical Choice

For the past few years, I have been using a simple concept to discuss our choices in dealing with difficult problems. Surveys and feedback from my workshop or retreat participants continually point to the few minutes we spend on this basic model as the most powerful part of our time together. It may be basic and seem obvious, but many of us seem to need constant reminders and help because it is so easy to sink “below the line.”change1.png

There are grey areas slightly above and slightly below the line. This is “survivor” mode. When this is our response to a difficult change or problem, we’re sitting on the fence to see what might happen, or we are waiting for someone else to do something. There are times when waiting in survivor mode and not acting immediately is quite wise – as long as we are above the line.

Examples might be when we need more information and have to do some research, or to see whether a change is going to become a trend, or which way the new boss, government, or customer is going to go. The top of the graph – well above the line – is proactive “navigator” mode.

When we’re here, we’re trying to capitalize on the problem or change. Or, if capitalize is too extreme a word, we may be at least trying to figure out how we can make the best of – or work around – a bad situation. In this mind set we’re like the seasoned ship captain of old, he knew he could not control the wind and currents, but he could adjust the sails and steer the ship to make the best use of the winds and currents to move toward his destination.

Below the line is the dangerous territory of reactive “victim” mode. When we’re in this head space, we’re bitter, helpless, and feeling like others are out to get us or deliberately want to do it to us. In this “blame storming” mode we might point fingers at politicians, bosses or senior management, other departments, customers, competitors, and the like. Decades of research by University of Pennsylvania Psychology professor, Martin Seligman, shows that explaining events in our lives in this state of “learned helplessness” leads to lower performance, poorer health, and higher rates of depression.

What Pulls People Down

The feeling of helplessness shared by many people in their organization is a major contributor to low organizational morale. Here are some of the common causes:

Forces beyond our control. Mergers, acquisitions, changing governments, organizational power games, bureaucratic decisions, new technologies, competition, boom/bust cycles, security threats, dumb rules and forms, globalization, and such leave many people feeling like dispensable pawns.

Nobody ever tells us anything. In a world overflowing with information, most organizations have little open and transparent communication. So “us against them” rumors attempt to explain what’s going on and why.

We’re swamped. Many people’s e-mail inbox, voice mails, phone calls, and meeting schedules are overwhelming, as work encroaches on personal time and stress levels keep rising. This leaves many people feeling helpless and frustrated.

It’s popular. Cynics, doomsayers, and conspiracy theorists often get more attention – especially if they use disparaging humor, sneering personal putdowns, and mocking sarcasm.

Fear is more believable. In a Canadian poll probing irrational anxieties, pollster Allan Gregg asked, “If someone told you something was safe and someone else told you it was unsafe, which one would you believe?” He found that an astounding “68 percent would accept the message of doom and gloom” without questioning who was telling them and what they were talking about.

Society encourages victim thinking. People who make bad decisions to hold paper cups of scalding coffee between their legs while driving, drive drunk or carelessly, take drugs, or smoke cigarettes for 40 years are encouraged to “make somebody pay” for what they have done to themselves. Watch daytime TV talk shows for plenty of examples. Seeing positive possibilities in a calamity or making the best of a bad situation is much tougher than joining the crowd that’s given up and wants to play the poor-little-victim against some other group or external force.

It comes naturally.  Most people can quickly identify what’s wrong. It’s less instinctive to focus on what’s right and build upon that. It takes much more courage to correct a problem than to point and complain about the problem while waiting for somebody else to fix it.

Shift Your Perspective: Life isn’t Fair

Lots of unfair and unjust stuff happens to undeserving people. Whatever hits the fan is usually not evenly distributed in most workplaces. But it’s our choice whether to stand in it or not. Taking a navigator response to difficult issues means facing problems head-on by focusing on what’s within our direct control or what we can try to influence. We then need to figure out how to let go of, or at least not ‘awfulize’ and give more power to problems or issues that can’t be controlled or changed.

It’s recognizing that the best thing to do when it’s raining, is to…let it rain. Here are some ways to be less of a victim and more of a navigator through difficult career or workplace changes: Be aware of your mental state and limit downtime – the ever popular and rapidly growing “Pity City” – or even its suburb, “Frown Town,” can be a therapeutic place to visit occasionally. We all need to grieve or vent our frustration when faced with major losses or setbacks. But don’t join any co-workers wanting to take up residence in Pity City (one workshop participant claimed her department head was mayor!).

That leads to deepening cynicism, despair, and inaction. Pay attention to your own moods and watch for defeatist language like “they will never listen,” “what’s the point,” “we’ve tried that before,” or “why bother.” Keep the problem in perspective – don’t get so drawn into the issue that it’s all you can see. Step back and look at the bigger picture. What’s going right? What’s working in your favor? How could this change lead to something better? What are the possibilities?

Talk through the situation with a colleague, mentor, coach, or spouse. Describing and discussing the circumstances will force you to re-focus on what’s happening – as long as you don’t commiserate with people who love to find conspiracies everywhere and be a victim. Dispute your doomsday scenarios. When your head is buzzing with dread and worry, examine your beliefs about this issue or change.

Challenge your thinking through weighing objective evidence against your fearful outcome. List more desirable alternatives or what you would prefer to happen. “Decatastrophize” your long-term fears by recalling all the times things have worked out successfully in the past. Examine and question the usefulness of dwelling on your feared belief or concern. Harness the power of imagery and counterbalance fears of what all could go wrong by ensuring you have a clear picture of what outcome you want from this situation. What would a successful result look like? What would you be doing with the key players involved? How would you be feeling? What mind set have you adapted to rise above the difficulties and problems? What actions might this lead you toward? Step back to step ahead. The busier and more frantic the pace of work becomes, the more critical it is for you to carve out personal reflection and renewal time.

Avoid the busyness trap of adding ever higher quantities of work time to compensate for the diminishing quality of that time, as you slowly burn yourself out. Set limits on your workday or workweek. Pursue hobbies, personal interests, or family activities. Get away on periodic mini and longer vacations. Meditate or learn other stress reduction techniques. Monitor and carefully manage your creative energy.

Change your self-talk – catch yourself saying things like, “I am too old to change,” “That’s just the way I am,” “He makes me so mad,” and replace them with more accurate phrases like, “I choose not to change,” “I am comfortable with the way I am,” or “I make myself mad when he says/does…”, or make action plans to change. Help pull others up In dealing with changes and problems in your workplace; you’re either part of the problem or part of the solution. Here are a few ways to help your colleagues or your team navigate more effectively through your endless challenges and issues: Speak up! Challenge, involve, or problem solve with those people who insist on picturing the worst outcomes and living in Pity City. By letting those comments go (or even worse,  joining in), you’re allowing the naysayers and cynics to set your team’s emotional tone and spread helplessness.

Refocus their thinking. Focus discussions on solutions and the future, not on the past or why nothing will work. You might need to point out that raising complaints without possible solutions can be unproductive and even harmful to the team. If team members or co-workers insist on remaining a victim, you might encourage or even help them to find another job.

Celebrate progress. Look for small wins and steps in the right direction that you and the team can build upon. You might periodically list what’s going well, or list your team’s accomplishments.

Find healthy ways to ventilate frustrations.  One team initiated a fine system whenever a member made a hopeless victim statement. It was a useful way to raise money for the United Way and called anyone to account for comments that brought the team down and poisoned their spirit. However, they soon found a need to vent frustration with the actions of another group or the challenging problems they were facing. So they added rituals like someone raising their hand at a meeting and asking for “permission to visit Pity City” for a limited time or scheduling a “grump dump” as part of their meeting agenda. It’s important to do a periodic “reality check” on how we deal with adversity and change.

One reality we can choose is to transform tough changes into positive results. Another possible reality is to wait for somebody else to take action or tell us how we should feel. Or our reality can be anger, bitterness, and helplessness. To choose our response is to choose our reality.


Jim Clemmer’s practical leadership books, keynote presentations, workshops, and team retreats have helped hundreds of thousands of people worldwide improve personal, team, and organizational leadership. Visit his web site, http://jimclemmer.com/, for a huge selection of free practical resources including nearly 300 articles, dozens of video clips, team assessments, leadership newsletter, Improvement Points service, and popular leadership blog. Jim’s five international bestselling books include The VIP Strategy, Firing on All Cylinders, Pathways to Performance, Growing the Distance, and The Leader’s Digest. His latest book is Moose on the Table: A Novel Approach to Communications @ Work.

Facilitating Discovery Meetings; Be Prepared

When I was a Boy Scout we had a simple motto; “be prepared”. The same motto applies to facilitating discovery sessions with your stakeholders. In general, people are tired of attending meetings and discovery sessions. In the business world, business analysts, project managers, senior managers and all other stakeholders are busy people who deserve to have their time leveraged wisely. Here are some of the techniques you can use to get participation, gain consensus and leverage your stakeholders in discovery sessions and meetings.

  • Get your introductions established with key takeaways from the participants. This helps the facilitator align the session objectives with stakeholders expectations. 
  • Establish the “rules of engagement” and “who they are as a team”. The rules of engagement provide a context for the session structure and acceptable behaviours. The team question helps establish how the participants see themselves. 
  • Be clear on the “business problems” being addressed and the “solution context”. Clear business problem definition should be created in partnership with the sponsors and senior stakeholders prior to the session. The solution context provides a framework for the participants to frame their thinking in addressing issues. It does not mean the facilitator is providing solutions. 
  • Use a variety of people and group dynamic tools and techniques. For example,
    Brainstorming in a non-judgemental way to capture the thinking of individuals and teams. Make sure that you follow brainstorming rules.
    Buzz Groups to buzz on an assigned topic for 10 to 20 minutes that have been established by the facilitator.
    Team Pods to group people into working units at common tables facing one-another so they get engaged.
    Play games. Do not be afraid to play games. Games provide a means of getting participation engaged and the information you need to have a successful session. This is where your creativity comes in. Have fun!
    66 Technique. Six people discuss a topic for six minutes. Give the group structure by assigning a chair, a scribe and an auditor to provide feedback on the groups’ efforts.
    POPs. Get the POPs (points of pain) and align them with the organizations maturity.
    Nominal Group Technique. Use the Nominal Group Technique to have team members identify their best solution to business problems through a process of rating and elimination.
    Cost, Ease, Benefit. Use Cost, Ease, Benefit analysis to have participants clearly define and understand the impact of their recommendations.
    SWOT. Get the SWOT, that is strengths, weaknesses, opportunities and threats, and identify those things external and internal that the team needs to focus on.
    Fish Bone. Throw them a Fish Bone (a diagram) to stimulate ideas and thinking as to the root cause of a business problem.
    Debate Teams. Create Debate Teams and have the groups discuss all sides of an issue. Ensure that there is structure and everything is timed and scribed.
    Smart Objectives. Have the groups make objectives SMART through ensuring they are specific, measurable, attainable, relevant and timely.
    Implementation Plan. Build an implementation plan with assigned tasks, core responsibilities and timelines. Ensure there is a follow up mechanism.
  • At the end of the session there are a few other things the facilitator should do. Consider these items:
    Summarize and Review all that has been said to ensure clarity and alignment with the sessions key objectives.
    FUDs. Get the FUDs (fears, uncertainties and doubts). Have the stakeholders write these down, in confidence, and hand them in at the end of the session. There is nothing better than knowing the stakeholders concerns.
    Communication. Establish a follow up plan. Communication is key to understanding what the participants expect. Be clear on expectations and follow through.
    Positives and Deltas. Request the positives and the deltas regarding the session. Review these as they will provide the facilitator insight into areas for improvement.
    Scale it 1 to 5 and ask how the stakeholders feel about the decisions, recommendations and the overall initiative. You might find that they see things as just another shade of what they did last year. Be prepared to leverage the information gathered.
    Get yourself evaluated. You need to grow.

There are lots of approaches, tools and techniques that you can apply to creating discovery sessions and meetings that provide value to the participants and stakeholders.

Your job? Be prepared!


Richard Lannon is an international business and technology industry veteran turned corporate speaker, facilitator, trainer and advisor. He specializes in aligning the enterprise and technical skills to common business objectives. Richard helps organizations and professionals identify what’s important, establish direction and build skills that positively impact their bottom line. He provides the blueprint for your organization to be SET (Structured, Engaged and Trained). His clients call him the SETability Expert. He can be reached at [email protected] or 403-630-2808.

Six Attributes of Leadership

Does leadership have an effect on project success? Is there a difference between management and leadership? Can leadership be learned? The answer to all these questions is yes. In this article, I will look at six attributes of project leadership. This is certainly not a complete list, just a start. One that I believe can help project managers achieve project success.

1. Think Laterally

The first attribute, lateral thinking covers a variety of methods to get us out of the usual line of thought. It is this kind of thinking that cuts across the instilled and predetermined patterns we all too often employ when working on a problem. With this type of thinking we try different perceptions, different concepts, and different points of entry and consider multiple possibilities and approaches instead of a single approach. Many problems we face as business analysts and project managers require different perspectives to solve them successfully.

2. Empower the Team

Often, there is little or no recognition for people who spend time on elementary problems, it’s the big problems that receive all the attention, yet, big problems start as minor problems. All too often, because of leadership attitudes, employees develop the habit of ignoring problems until they explode, at which time they become big problems, then leaders want to go on record for being a problem solver. Empowered project teams correct this attitude. They focus on getting the job done while solving or preventing problems while the problems are still minor.

The ultimate paradox of project leadership power is that to be an effective leader, one must turn all team members into leaders. In this way, processes such as relationships and the issues of leadership and empowerment become important. Successful leaders are able to motivate, to energize and to empower others. When people are excited and empowered, it affects both their task initiation and task persistence. That is, empowered people get more involved, take on more difficult situations, and act more confidently. Empowered people expend more effort on a given task and are more persistent in their efforts.

3. Be Optimistic

 The third attribute is optimism. Leaders are optimistic. They think positively. Positive thinking is more than just avoiding negative emotions; there are actions and forethought involved. When negative events happen, excellent project leaders purposefully look for something positive. Instead of feeling that they can’t do something, they look at the problem as an opportunity for themselves, the project team, team development, bonding and growth.

4. Demand Better

On-going self-assessment and self-evaluation are critical for ensuring that your project is meeting its objectives and having a positive impact. Demanding better is actually a simple idea. All one has to do is ask, “What can we do even better?” Essentially that’s all there is to it. Asking the question over and over again focuses leaders on challenging themselves and team members. Further, it sets into motion an on-going self-evaluation and a focus on the process of achievement. In return, this focus on the process brings results.

5. Encourage Delegation

Delegation is one of the most important roles of your job; as a leader your job isn’t ‘to do, it is to gain or accomplish things through your team members. Your time should be spent on such things as visioning, motivating, controlling and goal setting, and not on trivial jobs such as fighting fires or responding to interruptions and correcting errors.

 Delegating relieves time-pressures on you. It provides your team members with an opportunity to expand their own skills in decision making and problem solving and encourages their creativity and initiative, while motivating them to become what they are capable of being.

It forces you to spend time with your team members, thus developing your interpersonal relationships. Your feedback and attention will encourage them on to greater things. It helps set performance standards based on member’s accomplishments or results, rather than purely on their activity. It helps to increase results by releasing you from some of your activities. You will be able to step back and look at the bigger picture instead of being caught up in the internal activities of the project. You will be able to think outwards for the better of the organization and not lose sight of the real goals.

6. Reside in the Future

To meet future challenges, leaders must reside in the future. Only then can they set a vision with reasonable goals and promote the process of developing effective strategies to achieve them. Considering the future enables leaders to think constructively about it, and do the things that contribute to achieving their visions. Proactive future oriented thinking can lead to greater project success. The future will happen, no matter what we do. If you want a successful future, you need to work at it.


Victor Teplitzky is a Principal Consultant at Advanced Management Services, Inc. (AMS), a full service management consultancy servicing an international client base. Victor is an Industrial Engineer and Behavioral Scientist (HRD/OD). Since 1974 he has provided training, consulting and assessment services to a wide variety of organizations in both the public and private sectors including; the National Guard, US Postal Service, National Institutes of Health, Sara Lee Corporation, DoE, DoD, GPO, USACE, FAA, Wal-Mart, The Hartford, ING and many more Fortune 100 and Global 2000 companies. Victor has designed and developed over 100 training workshops including both general programs for “off the shelf” presentations and workshops tailored to meet specific client needs in the areas of Project Management, Business Analysis, Professional Development and Business Development.

ITIL for BAs. Part III

 

How ITIL Can Help Solve the BA Identity Crisis

 

This post is a slight digression from but still very relevant to the series we started a couple of posts ago regarding the interdependencies between BA and ITIL.  But I want to take this digression to establish a fundamental aspect of ITIL that can greatly simplify the BA’s job in working with IT-based solutions in an ITIL world.

 

 

In a May 2008 post I raised the question of where in the organization – IT or the business – a BA should be hosted.  Some great comments were posted pointing out the complexities of the issue, in terms of lines of reporting, experience, variations in the definition of the BA role, the presence or absence of the Center of Excellence, etc. 

 

My  answer to the question is that the BA – as a role – should be defined in both business and in IT.  Furthermore:

  • The BABOK is the best source for defining the responsibilities of the “Business BA” (and believe it or not, in at least one organization I know of, “Business Business Analyst” is an actual title!)
  • the role of the IT Service Owner, as defined by ITIL V3, is in fact the “IT BA”

 

In attending the PMI Global Congress, Project World, BA World, and itSMF Fusion events during the last six months, I have had discussions with numerous PMs and BAs who have heard of ITIL and wanted to know what it was all about, in 20 words or less – to which I typically respond: “ITIL is to IT management what the PMBOK is to Project Management and the BABOK is to Business Analysis”.  They pretty much get it right away.

 

Back to my reason for this digression, though, to take that analogy a bit deeper: ITIL is a practice through which the IT organization is encapsulated by a layer of IT Services, and in which:

  • the IT Service Catalog describes what IT’s capabilities are, in the Customers’ language,
  • the Service Level Agreement (SLA) defines how specific IT Services are to be delivered to specific customers, and
  • the IT Service Owner embodies those IT Service capabilities, marshals the IT Service through its entire life cycle, owns the SLAs, and is measured according to the degree to which actual IT Service delivery meets the terms and conditions of the SLA.

 

(Actually, the practice of encapsulating IT in this way – the “what” that IT is striving for – is known as IT Service Management, with ITIL being a best practice in “how” IT Service Management can be accomplished.)

 

Now, getting directly back to the purpose of this “ITIL and BA” series….  The process of identifying business requirements and solutions is iterative and hierarchical – a process of elaboration, as the PMBOK so eloquently points out.  At some point in that process of elaboration, the BA encounters the IT part of the overall solution.  Here is where the BA meets the IT Service Owner and why an understanding of the BA/ITIL touchpoints is so important:

  • Without ITIL and the presence of the role of the IT Service Owner, it is typically the BA who is expected to know the ins and outs of the IT infrastructure and IT’s capabilities, risks, etc.
  • With an ITIL-based IT organization, the IT Service Owner is expected to know the ins and outs of the IT organization, and the costs and risks related to the IT Service required in the solution.

 

To put it another way, the BA can depend on the IT Service Owner to elicit, analyze, and document, in the form of a Service Level Agreement, what is needed from the IT Service, while the IT Service Owner is responsible for understanding the how – that is, the IT infrastructure and IT’s capabilities to satisfy the what.

 

With this in mind, the BA’s view of an ITIL-based IT organization, and the IT Services IT is providing, becomes a matter of understanding IT in terms of

  • the ITIL processes that take an IT Service through its life cycle of Design, Transition, Operation, and Continual Service Improvement, specifically
    • inputs needed from the BA
    • outputs consumed by or of interest to the BA
    • activities that the BA can contribute to
  • the Service Catalog and Service Level Agreements as the basis for understanding IT’s capabilities

 

In the May 2008 post mentioned above, one reader comment pointed out that it is very challenging for BAs to manage solutions that embrace multiple systems.  Encapsulating those various system components as IT Services, managed by the IT Service Owner, can go a very long way toward empowering the BA to deal with those complex solutions more effectively.

 

If you have any reactions to this concept – pro or con – it would be great to hear them.  I hope you take a minute to mull this over and leave a comment below.  Many thanks!

The Importance of Business Domain Modelling

As human beings we created language and learned to classify objects in the world around us so that we could share concepts and ideas. Then we learned to write … and we haven’t yet learned when to stop! Often, repeated refinement of our customer’s problem and need statements are seen as measures of quality and completeness of requirements. It’s almost as if the greater the weight of the document the higher the quality!


The purpose of business modelling, and of our role as business analysts, is to describe the business and its intentions. According to The Unified Modeling Language (UML) User Guide, “a model is a simplification of a complex reality … so that we can better understand …” A model allows us to find meaning in the business domain and to communicate an understanding effectively to others. It helps the business owners to visualise together with us, and to specify their intentions in a disciplined and rigorous way. It is difficult for the business to manage what they cannot see. In a model, existing concepts and new requirements can be seen logically related to each other.

The beauty and uniqueness of a business is usually found in its business process and most business analysts are familiar with modelling the business process at some level. If we can answer the question “what happens next?” then we are dealing with a dynamic view of the world, i.e. depicting the behaviour and activity of the business area of interest. For example, the following (simplified) diagram of an outdated UK government business process to do with the international trade of food, specifies the business activity requiring automated support.

importance-businessdomainmodeling1importance2.png

The (simplified) use case summary diagram depicts the proposed use of the system for the trader. To specify our requirements, we have developed the business process and the use cases in a model. Is there more to do? Can we assume that any audience of this view will understand the concepts referred to – the ingredients of the business process recipe? This article proposes that a critical part of requirements elicitation is to understand and provide a static or structural view of the business domain.

We may ask “What is the point of business domain modelling?” The point is that we need to understand the things that we are referring to in the business process and use cases. Remembering that human beings need to ‘classify’ objects around them in order to understand the world and to communicate an understanding, we use the concept of a “class” to sketch the important things that exist for our customer. It is a view of what we need to understand and reach agreement about.

It is the view that gives us the truth – it communicates the things that are true no matter how we behave, no matter what time of day it is and no matter where we are in the business process. In this example, we need to answer the questions: What is a “certificate”? Can a “trader” apply for more than one? What does a certificate certify?

importance3.png

For readers not familiar with the UML, the food export business domain model, in the form of a class diagram tells us that a Trade is an aggregation of a set of Commodity Goods Items. An Export is the type of Trade relevant to this piece of work, along with the CAP Export type Certificate.

In this example, if we do not understand the important concept of a certificate and how it relates to a “trade”, the proposed software may not capture the critical business rules to prevent the trader’s potential loss of thousands, even millions of tax refund. Seeing these two concepts, and the business rules that associate them, pictorially, in a formal standard notation, makes it easy for us to ask the right questions and for the business to see whether the description of their business and of their need is correct. Consider the impact of not understanding the ingredients of the business process recipe.

Only the important detail has been captured for the food export requirements, i.e. that one or more Certificates can authorise a single Trade and a single Certificate can authorise one or more Trades. This is important because if a Certificate is not fully ‘used’, the tax refund for the unused part cannot be claimed by the Trader.

It took many questions to understand this because some traders matched their certificates one-to-one with their trades; some traders had lost certificates, some had let certificates expire, some had checked that government regulation would allow them to use up portions of certificates to authorise a trade. It would have been difficult to find those questions had I not drawn what the traders were saying and instead, simply had written down verbatim what they thought they wanted based on their problems. Modelling the requirements was an easy way to resolve any contradictions and to capture the most important business rules to provide real benefit to the trader.

It is important to model the business domain or as my favourite writer on the UML, Martin Fowler says, the “logic that is the real point of the system”.

The alternative is to write a similar amount of text as found in this paragraph for each “requirement” and lose the advantage of adding to the model. In addition, the process of documenting, reviewing and refining this text would cost a great deal more than asking our business customers to sign the whiteboard with the confidence that the domain model / use cases (i.e. requirements) covered on it have been captured correctly.

So often errors are found in traditional requirement documents after sign-off because so many statements were made, unrelated to each other, where no logic could be applied to associate them. Another reason for so many errors could be that the requirements i.e. a very long list of textual requirement statements, are never read – they are so very boring and time-consuming to review.

I once reviewed a high-level requirements specification comprising 300 pages of textual requirement statements. I counted 321 instances of the word “customer” and 656 written instances of a few other major business classes. I counted nearly 7000 instances of eight common words such as “to”, “the”, and “system” – words of no value or interest. I wonder how many more words of the total 38000 were unnecessary and meaningless, and that required time to be written, read, refined and read again by numerous people up and down stream of the author.

In a requirements model, these few words of real interest would be written a few times only. In a business domain model, or class diagram, expressing those requirements in relation to each other, it would be necessary to write each word once only as the name of a class (while in a workshop with our business customers of course). If the business architecture was already established in the organisation, then it would be necessary to simply reference them, rather than re-invent them (again!); one would simply familiarise oneself with the area of interest and then visualise the proposed change together with the business owners.

Business domain modelling can be applied to any concept.

importance4.png

Modelling and communicating business concepts in a standard notation keeps it easy for our customers … our service remains consistent and audiences beyond the here and now can understand and reuse our work. When I draw a purple triangle, I know what it means. You, the reader, do not. However, if you or I were to draw the following simple class diagram, every single business analyst and solution architect in the world, even the occasional project manager, should be able to understand it.

importance5.png

I am currently working in a project team with English speaking Russians – there is no language barrier when we show them our model drawn in our common language – the UML. The UML modelling notation, for the purposes of describing business, commonly uses about 15 simple symbols which can be nonchalantly explained to subject matter experts during a workshop session without burdening them with any lengthy training. My experience of appropriately exposing the UML to my customers has been, without exception, very positive.

Modelling or graphical notations were invented to precisely convey a concept and to depict a great deal of information in a concise way, rather like electrical circuit diagrams or architectural drawings. Their other purpose is to act as precise shorthand for what we verbalise and know to be true. Would it be natural for an electrician to write “the electrical system must allow the electrical current to flow into a capacitor which must discharge into a resistor”? A simple line drawing with universally understood meaning and without ambiguity suffices to say the same thing. Its advantage is that further requirements will be part of the same drawing and any defects or conflicts can be spotted easily in relation to the other elements on the diagram. In addition, should any changes to the implemented electrical system be necessary later, the model could be reused by other people to understand the current system and the impact of the proposed changes. That is impossible with hefty volumes of prose.

Business modelling is much more fun than writing a requirements novel that few people have time to read. I call on project managers and business analysts to dispense with their document weighing scales and embrace clear, correct and effective communication of ideas and business concepts.

In a future article, we will look at modelling the business actors and areas of interest in order to express the current business problem and to propose the goodness or scope of a project i.e. setting the scene or business context ready for further analysis.

This article is based on one of the “Truth, Beauty & Goodness” series of presentations named “The Importance of Business Domain Modelling” given by the author at the Business Analysis World Symposium 2008 held in Wellington, New Zealand. The author wishes to express her thanks to the following people for their thoughts and ideas freely contributed to this article: Lawson Davies, Brent Lewis and John McPherson.

Copyright © Suzanne Jane Maxted, October 2008, [email protected] or [email protected]


Suzanne Jane Maxted is a Certified IT Professional Member of the British Computer Society. She gained a Bachelor of Honours degree from the University of Sussex, England, in Mathematics & Statistics with European Studies (French). Suzanne is a business analyst with 16 years information systems experience from around the world. She is an accomplished workshop facilitator and presenter in the business analysis space and has given presentations to senior Member State representatives at the European Commission and at the United Nations, among others. She takes pride in applying logic and order to differing business viewpoints and in communicating common understanding. Suzanne teaches ballet to 3-8 year olds on Saturday mornings and fills her spare time dancing and having fun with her two little children.