Articles Archives - Page 397 of 424 - Business Analyst Articles, Webinars, Templates, Jobs

Business Process; A Thing of Beauty

Written by Suzanne Jane Maxted on March 3, 2009. Posted in Articles.

The English romantic poet John Keats wrote in the poem Ode on a Grecian Urn ‘”Beauty is truth, truth beauty,” – that is all/Ye know on earth, and all ye need to know.’ This article proposes that, by recognising and reflecting on how a business behaves, we can find, cultivate and hone its beauty by clearly seeing the culture and behaviour that will make that business uniquely successful in its chosen field.

The previous articles in this series looked at seeking out good by setting the scene using a business context model, and at finding the truth within a business by understanding what real things exist and are true at any time of the day, however the business behaves, using a business domain model. This article looks at why we model the dynamics of a business and its people.

Unless we can see how the business behaves, it is very hard to understand it. It is therefore important that we can encapsulate what the business does so that we can refine and streamline its behaviour, reduce unnecessary complexity and focus on purifying its business offering. As an analogy, an athlete will develop a process to maximise performance, eliminating all unnecessary activity. There may be a small measure of uniqueness in the process depending on the physical and mental nature and build of the particular athlete, but most athletes will follow a similar process for their sport.

There are two main camps nowadays when choosing a notation for modelling business process. I like to use the Unified Modelling Language (UML) because my business customers tell me that it is easy to pick up and read and because it covers all the types of business modelling that I require (dynamic and static). The Business Process Modelling Notation (BPMN) covers only business behaviour (both notations are owned and managed by the Object Management Group). In addition, many government bodies and industry groups such as the United Nations, the World Customs Organisation and the Telemanagement Forum set standards and industry patterns using the UML.

There is another faction – those who describe the business without a notation – the textual modellers who have the genuine concern that their business people will not like or understand the standard notation.

I have only ever experienced positive feedback on the notation, willingness and enthusiasm from the business and an immediate understanding of a few simple symbols, but, it is our job to create and communicate understanding, not the notation’s job. The notation is simply a language with a ‘dictionary’ and some ‘grammar’ rules. It is our job to ask all the right questions in the workshop (remembering we should always model with the business), to apply logic to a number of jumbled verbal descriptions of what is going on and to label each model element in a meaningful way in order to communicate the understanding reached. Otherwise the business will not understand the result! It is the combination of analytical skill and of the UML notation which won the following accolade. Recently during a domain modelling session (please see the article “The Importance of Business Domain Modelling“), a fellow business analyst, new to the UML, told me that he had looked down to think about something, then had looked back up at the whiteboard and exclaimed to himself how well the entire discussion had been recorded in a matter of seconds.

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) UML activity model of an outdated UK government business process to do with the international trade of food, specifies the business activity requiring automated support.

Note that a business process always has a starting point, a finishing point and directions on where to go when there are several paths to choose from. These are three of the most frequent review comments I make. Apply rigour and logic! For instance, I can only trade goods if a certificate was issued. Also note that the activity swimlanes (Goods Trader and Certification above) can be derived from the business context model (please see the article “The Business Context Model: As Good as it Gets“) by reusing the actors and business services or areas of interest already identified. The most frequent review comment I make is about the words used to name an activity. Each element in any model must be labelled in a meaningful way. I often see activities labelled like this – “Do Administration” or worse “Enter Data”. These have no meaningful business goal and therefore we cannot hope for good understanding.

Incidentally, it is useful to model at a higher level as we learn about the business; the business use case model is an ideal way to model disjointed business processes that do not logically flow one to another. For example, in international trade, we might identify the processes that are important to our piece of work in the following way, perhaps including a description (in a good modelling tool of course) before we model each process. They should be named to express an important result of value to the business or a major goal. We could even use the strategic business objective as the business use case name.

A business use case is also a useful container for business policies, business rules and constraints which can later be inherited by any software specified.

While some people think that specifying software requirements is the only aim of a business analyst, my view is that this activity should be regarded as a possible end goal depending on the findings of analysing the business. While the focus of this series is on business analysis, I will diverge a little to help refocus our attention on the business when we do step further into software specification i.e. to specify structured functional software requirements as system use cases (because a use case describes a single interaction between a user and a system that meets a goal of the user). There is misunderstanding about why we have use cases. Briefly, a system use case exists to partially or wholly automate and support a business activity in a business process. Therefore, we should not invent use cases from thin air. They should be derived. I have just read an article giving guidance on how to choose whether to model use cases or business process. I claim that we cannot know which use cases we need without studying the business process they are there to support. Otherwise, it’s like administering medicine without knowing what’s wrong with the patient.

How do we derive use cases? By studying the current behaviour of the business and improving it to a more desired state and then by looking at which activities we can enhance and support further. Please reference the Capability Maturity Model Integration [CMMI] which is an open framework for business process improvement describing five levels of business maturity: Level One is otherwise known as the ‘Beast’, and we might nickname Level Five as ‘Beauty‘. This begs the question – how do we know when we have found a system use case? The answer is when the goals of the business process are understood. What I mean is that we must model goal focused activities and those goals, once recognised, will guide us in informatively naming those activities in Verb + Noun format. When we understand the goal we have a system use case – possibly with the same name. If we don’t understand the goal of an activity, then we must look closer, like we do when showing a bee on a flower to a child – what is the bee doing and why? It may be that the activity identified is too ‘big’ or too ‘small’ and we need to ask many more questions.

Only by deriving use cases from a good logically thought out business activity model can we be sure that our software requirements analysis will be fit for purpose. How else would we know? By writing down the wish list of our business people, hoping that everyone can remember exactly what they said in the requirements meetings so that the 300 pages of free text that resulted are not subject to an endless round of revision? In addition, praying that the statements made can act, in a timely manner, as an accurate specification that really does meet the subset of business goals and objectives assigned to the piece of work from the overall business strategy?

Many business process modellers like to model in ‘layers’ and I am often asked how many layers one should model and what level of detail is required at each level. Some industry standards also model in layers, such as the Telemanagement Forum’s eTOM business process model. My preference is not to layer the business process, because I want the model to be public and exposed, say on my business owner’s wall, and I want the model to be useful as a focus for meetings and discussions. This means that it must fit on one page if printed! I have often seen four walls completely covered by a single layer process, or layers upon layers of business process never used again after the model is “completed” – incidentally the model can never be completed in my book. It is really a judgement for each modeller to make depending on their piece of work, but I prefer a single layer with exceptions modelled on further pages so that I can keep the main process on one page (“main” = what happens most of the time with exception activities shown to indicate when something goes wrong). This may mean that I must keep the goal of each activity quite ‘big’.

Of course, the best businesses are never complacent, always proactively striving for enduring beauty: measuring and optimising business objectives and activities; and visualising the business economics (cost, revenue, benefits). Therefore a model of the business process can never be complete – it is a snapshot of an ever evolving set of activities.

With a smoother running process, we can focus our attention on what really counts – the value chain; designing and pricing products and services. It can be a painful realisation when we know we must actively go looking for inefficiencies in our daily business life. After all, beauty is pain, so the saying goes.

The Art (or not) of Blamestorming

Written by Cynthia Low on March 3, 2009. Posted in Articles.

When times get tough, when people get stressed, and when they are faced with a crisis, it is interesting to observe how many people seem to suddenly become skilled in the Art of Blamestorming. Loosely defined Blamestorming is a meeting of like-minded people who enjoy sitting around in meetings, deciding who or what they are going to blame for their current plight.

How many good Blamestorming sessions have you had in your own organization recently? You probably know some people who are highly skilled at Blamestorming. Some people are so proficient that they do not even need an organized meeting in order to practice their art. They do it at the water cooler, in the elevator, on the phone and some are even skilled enough to record it on paper or send out by email.

In our current economic climate it is not difficult to become a skilled Blamestormer as there are so many easy targets to pick from; Wall Street; The Government; Over Spending Home Owners; Greedy CEOs; Oil Prices and the like.

Unfortunately though, Blamestormers tend to lead their organizations on a vicious downward spiral of panic, falling morale, resignations, lack of focus on solutions and a lack of vision for the future because they are too focused on finding someone or something to blame for the past.

What organizations need now more than ever are not people who are looking to place blame, but for leaders who are prepared to step forward and take some responsibility. To take responsibility for how we got here, what needs to be done about it, what does the future look like, and how are we going to execute a plan to get there.

Good leadership is always about responsibility and never about blame. Of course there are always things that occur that are beyond your control and yes they can affect your current situation. Strong leaders though will instinctively know that sitting around discussing who is at fault will achieve very little.

Instead they will ask themselves some of the following questions:

Did we really have a contingency plan in place for recessionary times?
Have we created a culture of innovation so that we can look at new ways to grow?
Have we created an agile organization that can adapt quickly to changing needs?
Have we built a loyal engaged workforce who have faith in their leadership and will stay with us?

In the days ahead, organizations that have developed strong leadership will be thinking about how to learn from the past, be innovative today, and provide inspiration for tomorrow so that they emerge stronger, leaner and well prepared when the upsurge occurs. They will not be wasting time with the Art of Blamestorming.

Bryn Meredith is a principle of Bluepoint Leadership Development. He has extensive experience as a business leader, entrepreneur and leadership development specialist. Bryn can be reached at [email protected]

ITIL for BAs – Part VIII; What is Design?

Written by Terry Longo on February 24, 2009. Posted in Articles.

A colleague of mine who is much wiser than I (that could be pretty much anyone!) defined “design” as “the art of tradeoffs”.

It is easy to “design” an IT solution for 100% availability, more than enough capacity, extremely secure, with all the functionality currently desired, etc. – and such a design would surely meet business needs! But in most cases such designs are neither practical nor feasible and are thus empty exercises. True design replaces thoughtless overkill with a prioritization of the dimensions of a solution in a way that reflects the solution’s intent. That prioritization informs tradeoff decisions driven by the realities of cost and schedule.

In earlier posts I had discussed ITIL’s general coverage of Quality of Service (QoS) requirements. In ITIL V3, the Service Design book covers five specific QoS-related processes that should be considered during design. (The book also covers Service Catalog Management and Service Level Management, which we discussed earlier). During elicitation, analysis, and solution investigation, it is quite important for the BA to engage IT, through these processes, to ensure that

those QoS characteristics are properly prioritized relative to the solution’s desired business outcome (not just the business requirements, but the outcomes that ought to be realized by meeting those requirements), and
tradeoffs between these various QoS requirements, functional scope, cost, schedule, and risk are rigorously rationalized

Capacity Management ensures “that cost-justifiable IT capacity in all areas of IT always exists and is matched to the current and future agreed needs of the business, in a timely manner”. The consideration of “current and future needs” is at the level of specific applications and solutions as well as the overall IT infrastructure and organization itself (e.g., the possibility of mergers and acquisitions).

Availability Management ensures “that the level of availability delivered in all services is matched to or exceeds the current and future agreed needs of the business, in a cost-effective manner.”

IT Service Continuity Management supports “the overall Business Continuity Management process by ensuring that the required IT technical and service facilities (including computer systems, networks, applications, data repositories, communications, environment, technical support and Service Desk) can be resumed within required, and agreed, business timescales.”

Information Security Management seeks to “align IT security with business security and ensure that information security is effectively managed in all service and Service Management activities.”

Supplier Management’s goal is “to manage suppliers and the services they supply, to provide seamless quality of IT Service to the business, ensuring value for money is obtained.”

ITIL V3 defines a “manager” role for each of the above processes. The more mature these processes and roles are in IT, the more IT is able to participate effectively with BA in

requirements elicitation and analysis
negotiation (since there will undoubtedly be times when the business asks for more than IT is presently capable of delivering)
solution rationalization

Furthermore, IT in and of itself is not in a position to make tradeoff decisions but needs the BA’s involvement in and knowledge of the requirements and desired business outcomes, in order to make those tradeoffs.

There is of course much more to design than is covered here, such as designing for manageability and supportability, planning the solution’s retirement, etc., and the Service Design book covers all of that and more.

The key takeaway from today’s post is (a) QoS requirements can and should be reflected in the IT’s organizational structure and capabilities and (b) omitting consideration of these QoS characteristics can open the business to significant risks.

How mature is your IT organization with respect to these design activities? Do you and your fellow BAs engage IT early on in the requirements process? Are there past cases where in retrospect that did not happen but should have?

Please feel free to share your comments with your fellow readers.

When Needs Become Conflict

Written by Richard Lannon on February 24, 2009. Posted in Articles.

Recently I was reminded that only 10 percent of conflict is extreme and that 90 percent of conflict is acceptable. In working with a client, I noticed some needs that were not being met. Those needs erupted into what we would call conflict between several people on the team. It was interesting to observe what took place. Mostly it was a flight situation. The people in the conflict situation left the area. This is not a bad thing as sometimes you just need to get out of Dodge. When it comes to conflict we all need to take some common thinking into consideration.

First, conflict has its positive place in our lives. Conflict is natural and depending on our disposition we might fight/flight or fend/befriend. We are wired that way.

Second, think of conflict like the ice berg in the ocean; two-thirds of it is underwater. For people the portion under water has to do with our history, values, culture, beliefs and feelings and all the other stuff that is happening in our lives.

Third, one-third of the ice berg is above the water. This is where we observe people behaviours. The above the water iceberg represents the actual conflict event that occurs among individuals and teams.

Conflict thinking is often broken down into four levels. These include:

Position: This is the level that is about facts, data, and information. At this level a person or team takes their position.

Standards: This level is about policy and procedures that do not necessarily fit the individual or team culture. Somewhere a change is mandated without regard to the people impact.

Objectives: There is a lack of alignment in the organization, team and individuals goals and priorities. People are confused and are not sure what is important. There are conflicting interests and generally poor leadership.

Culture: The culture level is about values, beliefs and attitude. This is the level where individual, teams’ and organizations’ interest lies. This level is the deeper under the water level that should be understood and taken into consideration. This level can represent a real challenge.

We all need at least one approach to conflict resolution. The following 10 steps is an approach used in dealing with one on one conflict that, if engaged correctly, can go a long way towards resolving conflict.

Present the issue without emotion, blame, or judgment
Ask for the other person’s point of view
Explain your point of view clearly
Clarify and define the issues in terms of both your needs
Create a joint plan with which you both agree
Brainstorm and discuss possible solutions
Select the best chance of meeting both your needs
Develop a realistic plan of action and determine who will do what, by when, where and how
Implement the plan, make a commitment to it and follow it
Evaluate the success of the solution based on the joint objective

During the conflict resolution discussion, do your best to keep your emotions in neutral. That does not mean divorce yourself from your emotions. It simply means that it is alright for both sides to recognize their emotions and feelings. Each party needs to acknowledge their emotions, be willing to describe the situation and express how they feel. In turn, they must clearly specify what is expected and consider the consequences of individual, team and organization behaviours.

Much of conflict resolution is about acknowledging and settling the emotions through collaborative problem solving to satisfy the various stakeholders’ interests to the greatest degree possible.

Richard A. Lannon partners with business and technology organizations to help clarify their goals and objectives and train their leadership and professionals on how to achieve them. He provides the blueprint for you and your organization to be SET (structured, engaged and trained). That is why his clients call him the SETability Expert. Voice: 403-476-8853 Email: [email protected] Web: http://www.braveworld.ca/

Enterprise View of the Business Analyst Role

Written by Cynthia Low on February 24, 2009. Posted in Articles. 1 Comment on Enterprise View of the Business Analyst Role

BAs Tend to Have a Narrow Focus on Project Related Work

All too often, the BA is unable to focus upon the right areas during a project due to a lack of enterprise analysis prior to the project. Because of this lack, the BA is forced to do requirements elicitation at too many levels at once rather than having focused requirements analysis at the business level leading to requirements elicitation and subsequent analysis at the functional level. This leads to several dangers.

Danger #1

The BA is put behind the curve from the beginning of the project.

If there has not been sufficient elicitation and analysis effort at the business level before the project, the BA is trying to define the business level requirements while simultaneously building the functional and system level requirements that will deliver/support those business requirements. Most of us have been in projects like this and we know that the pain level is high.

Danger #2

The BA is very likely to make discoveries during the project that should radically redefine the project; however, promises have been made and no one wants to explain why this was not anticipated. This leads to projects that deliver what they promised but are perceived as unsuccessful because expectations have changed during the project. One solution is to manage expectations; another is a better use of the change control process.

A Wider and More Appropriate Focus

The Business Analyst’s Body of Knowledge (BABOK) v1.6 has a visual in section 1.6.1 (shown below) that shows the relationship between the knowledge areas. I find the picture is effective in conveying a message that the real role of the business analyst is in project related requirements activities.

One way to look at the BA role is to view Enterprise Analysis as encompassing the other BA activities shown in the BABOK. If you take that view, then the BA has a much clearer set of duties and activities before, during and after any project activity.

Using Enterprise Analysis as the Driver

The following graphic allows us to look at the BA’s role more holistically.

If we look at the role of the business analyst as primarily enterprise focused, we can use distinct phases leading from opportunity identification to solution definition to development to implementation and finally to the analysis of new threats/opportunities surfaced from the solution’s existence. This allows greater clarity in the business analyst’s role and deliverables.

Strategic Phase (the first column in the picture)

Clearly there is (or should be) a phase where the business analyst is working with business management to create and maintain the business architecture, identify opportunities to pursue, and develop a portfolio or projects from which business management selects those most beneficial to the long-term goals of the organization. These deliverables are listed in the BABOK as associated with Enterprise Analysis (EA).

The BA is definitely using all the project management fundamentals here, but the objective is not to produce a specific new application or process. The focus here is to act as a consultant/support arm to the business management so that opportunities can be identified, explored and selected or deselected. I find that most of my clients have too many projects going at once. In addition, many of these projects have conflicting goals and measurements. We, the BAs, have an opportunity at this stage to establish our credentials as a business partner by helping the business management define a portfolio in which projects are prioritized and staged to maximize business benefit. This would also have additional benefits to organizations such as HR and IT that are stretched too thin under the current approach.

This strategic phase is where the BA has the opportunity to elicit and analyze the business requirements so that the portfolio decisions can be made as to which projects are worth pursuing. In addition, the BA has the opportunity to include parties who will be affected by any projects initiated from this phase. This would include, but not be limited to, groups such as project management, quality assurance, and training

The BA at this point should be producing a set of deliverables some of which are listed below. We use the balance as the symbol in the list to reiterate that each is a narrowing of focus and more detailed analysis of a subset of the deliverable which preceded it. These deliverables include:

A set of opportunities from which management decides those to be pursued,
For those selected opportunities, the BA develops alternative solutions with associated trade-offs. Management decides which alternatives to pursue, if any.
For selected alternatives, the BA would be doing a detailed analysis that will be the business case for projects to be done. This will include the business level requirements that will be addressed by specific projects.

Project Phase (middle column)

This phase has received the most attention in the general literature and this is not meant to be a complete coverage of the phase. The intent here is to show how the usage of the strategic and operational phases improves the project phase.

The strategic phase leads to project work. In the project phase, a set of selected business requirements should be used as the base to initiate the requirements effort at the next lower levels. A key point that I am trying to emphasize in this document, however, is that the likelihood of this phase being successful is substantially improved if the business analyst has had the opportunity to produce those products identified in the strategic phase.

Similar to the strategic phase, the BA’s deliverables during the project tend to build upon each other. These include, but are not limited to:

Testing/Acceptance criteria for the business requirements being addressed by this project.
Functional and non-functional requirements that need to be accomplished to support the business requirements.
Trade-offs between different approaches for project delivery
Test strategies that will be used during the project to demonstrate that requirements have been delivered.

Frequently, there has not been sufficient work done in the strategic phase (i.e. the EA work has not been done). If so, the business analyst must retro-fit that work into the project. This puts us right into Dangers 1 & 2, identified earlier. Since we have already launched the project and committed to a delivery/completion date, the business analyst doesn’t have the time needed to produce those work products with enough rigor. Worse yet, the project manager who has been driving the planning and execution efforts based upon the approved project scope will be frustrated when/if the business analyst’s detailed work shows that the project should be redefined.

Operational Phase

In any case, a solution is eventually delivered. Once any solution is in place, the BA enters a new analytic phase. The solution, by its simple existence, opens up new ideas. Once people are dealing with the solution, they start thinking about what could be. This will include high level and low level ideas.

High-level

These will be a mixture of threats and opportunities that the BA should identify by working with all levels of the organization. These ideas can be brought to the attention of senior management and becoming input to the strategic phase.

Low-level

No solution is ever complete or perfect. The BA, working with the solution users and customers, can identify a set of improvements, fixes and general changes that will allow the next version of the solution.

Closing the Loop

The BA needs to be looking at a lifecycle which starts before and lives after the project. We can better acknowledge this by adding the strategic and operational phases to the view of our work. It also institutes a feedback loop to that life cycle which will allow us to establish and build upon the role of BA as a consultant/business partner.

John Slack is a Principal Consultant at Advanced Management Services, Inc. (AMS), a full service management consultancy servicing an international client base. John has over 30 years of experience in business development, project management, business analysis, and professional development. For the past decade he has focused his time on a mixture of active project management and analysis of business operations as well as the development of training for project management and business analysis. His projects have ranged from the retail to high tech sectors including the planning and rollout of business strategy for companies such as Digital Equipment Corp and Intel, to the development and rollout of software applications for companies such as DirectTV, Motorola and American Airlines. 02/09