Articles Archives - Page 396 of 418 - Business Analyst Articles, Webinars, Templates, Jobs

Facilitating Discovery Meetings; Be Prepared

Written by Richard Lannon on November 17, 2008. Posted in Articles.

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

Written by Cynthia Low on November 17, 2008. Posted in Articles. 1 Comment on 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

Written by Terry Longo on November 17, 2008. Posted in Articles. 2 Comments on 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!

ITIL for BAs. Part II

Written by Terry Longo on November 3, 2008. Posted in Articles. 1 Comment on ITIL for BAs. Part II

Service Strategy

If one purpose of any strategy is to express a consolidated, comprehensive view of mission and direction, then the BA should expect that an IT organization’s IT Service Strategy is embodied within the IT organization’s structure and the roles defined.

In ITIL V3 that embodiment of IT Strategy is realized through the role of the product manager, whose responsibilities include:

driving service strategy
managing services across their entire life cycle (concept, design, transition, operation, retirement)
ownership and maintenance of the service catalog, an essential document that describes IT’s service capabilities in the customers’ terms
understanding IT’s service models and how to drive changes and improvements effectively through those models
knowing the costs and risks associated with the lines of Service they represent
evaluating new technologies and operating models that can be leveraged for greater efficiency and effectiveness
providing financial analysis of existing, planned, and proposed services
supporting the business in building business cases for new services or improvements to existing services

The above responsibilities are only half of the story, as they are primarily inward-focused. On whose behalf is the product manager carrying out those activities? In ITIL V3 it is the primary relationship the product manager has with the business s through the Business Relationship Manager (BRM), who represents the customers and their IT service requirements. Together the product manager and the BRM work to

understand the financial elements of IT Service delivery
express the demand the customers will have on IT Services (new and existing)
build business cases from a life cycle point of view
manage the resulting service(s) within the context of their respective IT service and business solution portfolios

In BA terms, the BRM is the business analyst.

It is interesting to note that the definition of the product manager directly addresses (I think) the question of whether a business analyst should be part of the business or part of IT – the answer is both, for the ITIL V3 product manager is, in essence, a “business analyst”, with a specific focus on IT Services.

For more information, ITIL Service Strategy Appendix B section B2 presents a concise summary of the nature and value of those two roles. ITIL V3 books are available from most major booksellers and also from the IT Service Management Forum (itSMF) at the publications section of their Web site at http://www.itsmfusa.org/.

The Importance of Business Domain Modelling

Written by Suzanne Jane Maxted on November 3, 2008. Posted in Articles. 1 Comment on 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.

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?

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.

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.

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.

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.