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

The Business Context Model; As Good as it Gets

Written by Suzanne Jane Maxted on December 1, 2008. Posted in Articles. 2 Comments on The Business Context Model; As Good as it Gets

The Greek philosopher Socrates said “In the world of knowledge the idea of the good appears last of all, and is seen only with effort”. This article proposes that as business analysts we must have the audacity to seek out the good of a project using thought and effort to find the real business goals early on.

A business context model needs to express the current business problem and to propose the goodness and scope of a project.

I vividly recall after one particular business context modelling workshop, a senior business manager at a government agency said to me “if only we had started project x in this way, we would have reached agreement about what we were trying to do so much faster.” I have received positive feedback from stakeholders in multiple projects and also from other business analysts who see this technique as a useful tool to engage the business and to orient themselves in the program of work.

The business context model should identify the actors (people, organisations, systems) who play a significant role in the business process or in the business domain, and the business areas of interest relevant to the scope of the work and potential change which may require exploration and further analysis.

At this early point in the project we are business modelling at a very high-level in a fairly imprecise way i.e. taking a helicopter view of the business. We should not model detail such as inputs, outputs, business rules, attributes, operations, or states. We are simply trying to set the scene. By doing this graphically, we gain all the usual benefits of modelling, not least using the business context model as a vehicle for merging differing business viewpoints quickly, and for asking the right questions.

We may start more detailed analysis alongside our context modelling depending on our style of modelling. We may create a snapshot context model to kick-start our project, or we may continue to correct the context models through the project, again, depending on need or style.

I have seen all manner of “context” diagrams – current state, future state, environment diagrams, system diagrams, network diagrams, communication diagrams, business process diagrams, relationship maps, organisation charts, etc. Most of these use inconsistent notation within the diagrams themselves and, more significantly, do not set the scene for a newcomer. They are usually meaningless and business illiterate. Putting business context modelling “in context”, we need a snapshot of the business and its problem and another of its intention.

How do we start modelling context? After gathering the business customers in a room, the end customer is the first thing I draw on the whiteboard. Otherwise I am unable to ask meaningful questions about the problem or to begin the task of analysis. Then we need to discuss the problem and draw it; this represents the current state only and the reason for initiating the piece of work. The example below represents the current problem with importing and exporting goods in some countries.

For readers not familiar with the Unified Modelling Language (UML), a package indicates an area of interest. A stick man represents any actor in the business domain – a person, an organisation (which in turn represents its customer facing channel such as a website or business-to-business gateway), or a system. I prefer to show a system as a stick man because I need to remember, as a business analyst, that it is playing a part i.e. it is an actor in the business process, performing some of the business activities. I am not in the business of drawing a map of the organisation’s systems but of focusing on the business activity and business logic. It is also worth bearing in mind that when modelling context, we are not yet trying to elicit software requirements.

I use the UML notation for context modelling because the modelling language is consistent with other model artefacts, such as a business domain model (please see my article, The Importance of Business Domain Modelling in the November 1/08 Business Analyst Times). It is understood worldwide and by audiences outside the current piece of work, for example, another business analyst on another project, and I can reuse or trace to elements already created.

I have always had positive feedback from my business customers while using the UML notation. Moreover, they have always understood what we have created together in the UML. There is no perception that I am using “IT speak”. In workshops, I talk about the business objects that we are interested in and only briefly mention, as we go along, the four or five simple symbols that I will introduce that day. I can only say that, as a business modeller and analyst, it is so much better, so much easier, so much quicker and so much fun compared to all the other techniques I have tried and used over the years.

The following business context model expresses how to “make good” the import / export problem expressed above. The scope of the project is indicated by the boundary box. I have named the new package as “new bunch of stuff” to highlight that we need to think carefully about a new name. We can include important statements such as business objectives – they may be sourced from a project brief, from some statements made and clarified in the context modelling workshop, or from any other source such as a staff communication from the Chief Executive.

Critical to the business modelling activity is traceability, from our solution defined elements, such as a use case, to the original business statements, such as business outcomes, objectives, benefits or scope statements, which the project activity is addressing. By including significant project statements in our model we begin immediately to create traceability and business engagement to clarify meaning.

Spending an hour or two in workshop with our business customers at this stage will save hours of revisiting these discussions amongst individuals. The workshop might be intense and hard going but it sets us up well for a smoother run when we begin modelling proper.

Replicating the model in a good modelling tool to formalise what was agreed in the workshop takes very little time and is simply a rubber stamp exercise, while of course having the enormous benefit of being straightforward, explicit and not open to individual interpretations and agendas. As an aside, in this example the scope context model took less time to create than the problem context model because I reused the model elements already created.

We can introduce other model elements for clarity. In this new example, the following context model expressing scope includes a package that contains a particular service offering (as an object) as a scope statement. We might also add primary information flows such as “customer order”. Of course, by moving the boundary box we can easily express the scope of another project.

A package in the UML can be used as a way of breaking up the mass of business complexity into manageable chunks; I use them to indicate a business area of interest. It is for each business analyst to judge just how these are cut, however it is important to name the packages in the same way that the business customers think of them. The general guideline is to use the package to contain a “bunch of stuff”. Hence, collective nouns are good words to use e.g. xyz management, family. I have named packages as departments, areas of functionality that align with an industry pattern e.g. sales order management, or again, simply a ‘bunch of stuff’ e.g. border security.

If we put effort into seeing the good in a business or in a project we can easily set ourselves up well for further analysis and full traceability to the original business need, saving us so much time later. Each area of interest could be the basis for some business process relevant to the piece of work. The package name may become a swimlane of activity in the first cut of our business process, alongside swimlanes for each actor identified in the context model, if appropriate. The packages within our boundary box will contain the business logic, rules and use cases to support the business activities and interactions in scope. One of our goals as modellers is to give ourselves maximum opportunity to reuse model elements already created.

We can use context modelling for anything important we wish to think about, perhaps even for making family plans or for helping us to think through strategic decisions and commitments, and regulatory requirements. Below is an incomplete example that I baked earlier about reaching fulfilment in all aspects of life.

The packages, actors and associations have been depicted in this way to allow analysis to take place, the results of which may relate directly to elements in the context model. We are aiming to reduce our workload and reuse work already done. Using a good modelling tool, not a drawing tool, allows us to do this provided the notation is consistent and is used correctly, i.e. we do not deviate from the standard UML to Pidgin UML. After all, we do not use Pidgin English if clarity is the order of the day in our written material.

If we are honest with ourselves and listen to the problem statements made by our project managers (“it takes too long”), our solution architects (“the requirements are not clear or consistent with one another”) and our business customers (“I don’t have the time to review so much written work or indeed the time to wait for it.”), we would stop writing and spend only the time it takes to clarify a few significant verbal statements as a baseline for traceability purposes, and invest in the intellectual activity required to model the business. We must use our time asking all the right questions, listening carefully to the answers, capturing and structuring the knowledge gathered as clearly and as explicitly as possible, using a formal notation such as the UML.

As Jim and Michele McCarthy say in their book Dynamics of Software Development, which provides us with rules for delivering great software on time, “the real task of software development management is to marshal as much intellect as possible …” If such investment is made in the early stages of a project, the business analyst can capture the essence of a business vision, the goodness of a project and then focus on channelling the business intellectual property (IP) into the subsequent business analysis artefacts.

Modelling the business context is not a mechanical assembly line task to map some of the things that already exist in the organisation. It is an intellectual activity that requires the business analyst to elicit the business problem and to visualise with the business how to make good that problem.

In a future article, we will look at modelling the business process and the rules that govern the activities it comprises.

This article is based on one of the “Truth, Beauty & Goodness” presentation series given by the author in 2008 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: LD, BL, JM, HT.

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 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. Suzanne can be reached at [email protected] or [email protected]

The Uncertainties of Integration Projects

Written by Cynthia Low on December 1, 2008. Posted in Articles.

Integration is burdened by a lot of misconceptions. The uncertainties of an integration project can be deep enough to evoke hundreds of questions, specific to a company’s back-end systems. This article will focus on five common thoughts where we have seen Integration sales reps dance around one or more questions, possibly because of either shortcomings in products or a lack of knowledge on how Integration really is implemented.

Building Integrations isn’t really easy, right?
How much will I need to spend on professional services, and what particular expertise will that entail?
What is the true time to develop integrations?
What are the real costs/options of the software?
With all of the Standards out there, isn’t Integration pretty straightforward?

Mid-sized organizations may undertake either internal or external Integrations, and projects can cross over data formats and system boundaries. One good example is integrating order data from an on-line store (typically in XML or an intermediary DB back-end) to an ERP system. It’s what many think of as a singular or monolithic integration: it connects two points, crossing data formats and system boundaries.

However, that’s only part of the picture. You may also want to move the information into a CRM application as a subsequent transaction. This can be thought of as a complex (or multi-step) Integration. Some other examples of Integrations involve legacy data movement, EDI, and XML Interestingly, we are seeing an increase in spreadsheet-to-application integration, as spreadsheet formats emerge as a lower-end data-exchange standard du-jour and, as such, represent a tempting staging area for incorporating into other applications.

Why integration matters: islands need to communicate within a company.

Most mid-sized companies have IT departments that are stretched very thin, for any of several reasons:

Limited staff and resources;
Lack of knowledge and difficulty in finding impartial advice;
The cost of solutions;
Lack of time to devote to implementation and maintenance;
Short-range management perspectives;
A lack of understanding of the benefits that IT can provide, and how to measure those benefits;
Lack of formal planning or control procedures.

Without these limitations, many if not all the questions would be irrelevant. But they do exist, and lead to inevitable questions.

Q: Building integration isn’t really easy, right?

A: This is the ugly truth about integration projects. Typically, they’re tough going. There are tools that can help, but you still need to be prepared to get in there and roll up your sleeves.

There are several considerations, not the least of which are the data formats to be used (How well do you understand the data formats and processes?); the processes to define; communications methods; if you are doing an external Integration, how cooperative is your partner (well-defined specs)? What information have they provided? And, what skill sets are available in-house to achieve this understanding?

Integration does not need to be difficult if customers have an understanding of the following “whats” or variables:

Ability to work with data definitions, create definitions that can be re-used;
Easy-to-use mapping tool (graphic, drag-and-drop, connect source and target info. Avoid writing code);
Business process management, something that is often overlooked. We find that companies are conscientious about the data, but often forget about the processes, and how they can improve them or accomplish more with what they have.
Flexible way to use communications adapters. Without them, a company’s infrastructure can really be over-burdened.

So, the key to making the “how” easier is understanding what the tools can do for you. There is a direct link between the capabilities of the tools and the ease of building the integration.

Q: How much and what kind of professional services will I really need?

A: It depends on a few key factors. The first, most logically, is the size of the integration project; then, the capabilities of the tools used; and especially the in-house skill sets.

For large integration projects, “point solutions,” especially where manual programming is involved, can run from 4x to 10x the cost of the software. The sophistication or complexity of the tool, versus in-house skill sets, tends to define the need for consulting. The in-house capabilities need to be aligned with the capabilities of the tool. This may not be an obvious point, but it’s important to keep in mind. You don’t give an 8-cylinder roadster to a new driver, nor send a jet pilot to operate a back-hoe; match the tool to the skills and experience of the user.

Users can, in fact, leverage a pilot project as a mentoring stage, something we see pretty routinely. The real key, where I have seen the best ROI, is to define a small pilot-project and engage a professional services group to mentor your team. This allows a skill-set transfer, won’t consume a large amount of resources, and produces a usable Integration, rather than a throw-away.

In other words, the pilot project doesn’t go away after implementation, it actually goes into production. The concept has been proven, and the results are immediate. Because of the capabilities of contemporary Integration tools, these pilot projects only last a few weeks. They can be an effective way to measure the rate of knowledge transfer and still end up with a usable result.

Q: What is the true time to develop integrations?

A: Several factors tie in to the first question (Integrations aren’t really easy!). I’ve worked with companies where the IT folks staff the new systems inside and out. They were able to grasp the tools and run full-speed. We also have the converse situation where a smaller company has a business analyst who is savvy and is thrown into the mix as the Integration person. They have “some” knowledge of the processes, a passing familiarity with the data formats and a limited background with the notions of mapping and data conversion.

Then, we have “the rest of us.” So, this is too broad a question to answer generically. There are usually metrics available, for example, to map an EDI 4010 Purchase Order into a back-end database. Even though there are tons of DBs out there, you are still doing similar things (header/detail records etc). Professional services teams usually have a good handle on these types of metrics.

The answer lies within the capabilities of the tool and how easy it is to understand and start leveraging it. A good example is a tool that can take a flat-file document and allow you to easily “discover” the structure of the document. That would save you from having to build the data definition by hand. Web services have been designed from the ground up to aid this process by providing a schematic of the services and request/response data formats within a descriptor document called a WSDL. This self-describing nature is also inherent in XML documents, but requires a dictionary to leverage the business relationships of the data.

Understanding your business goes a long way towards developing integration. That is, besides understanding the company’s own business processes, it helps to also have an understanding of the data formats. Awareness, from the general to the specific

There are no real absolute answers, just a range of times that have been observed from projects. However your first pilot project should definitely be scoped to only take a few weeks to a month. You want to attain a completion, without burdening the user with a large knowledge-transfer upfront.

Integration tools can help accelerate the process, and a few key principles come into play:

Easy-to-use visual tools reduce learning curve
Reusable objects improve development efficiency
Integration tools can reduce complexity and therefore reduce dependency on consultants

Testing the Integration is a key area that gets lost in the time estimates, so always keep that in mind.

Q: What are the real costs/options of the software?

A: By their very nature, most sales people want the prospect to buy the whole enchilada. They want the prospect to think of integration architecture and enterprise-wide solutions together. The fact of the matter is that there are packages designed for the company to buy just what they need at the present moment, and allow them to grow into the full solution later.

Oftentimes, a sales rep. has the option to sell you less than the full-blown system, but may not let you know that until you ask. Depending on your corporate setting, you may be addressing a mandate such as an EDI standard from a large trading partner. In that case, you are looking at a tactical solution with some interest in moving into Integration at a later point.

Given the complexity of enterprise-systems today, it can also be overwhelming to think, from the start, about all the touch-points where Integration would be a benefit. Being able to buy a “slice” of a full Integration solution is a valuable way to solve your immediate need, and introduce you to the technology at a hopefully lower price-point.

Finally, be cautious of hidden costs, such as training time/ramp up.

Q: With all of the Standards out there, isn’t Integration pretty straightforward?

A: Yes, one interesting thing about standards is that there are a lot of them (see graphic, for standards relevant to Integration); and they all want you to do things their way. That’s why they call them “standards.” But, there are no “formal” integration standards, just technology standards. There are ways of thinking about Integrations, templates or patterns to follow, but no hard-and-fast rules on how to do Integration. It’s not just about connecting the dots.

Quite often, standards are simply guidelines Understanding your data and processes is a fundamental requirement when thinking about Integration.

Let’s talk about one of the real reasons why Integration exists; it’s what I call the “Standards Oxymoron”… the notion of standards regarding data. There are standards for what the data looks like, how it is transmitted, etc. There is one great thing about these standards; they are so popular that you have a lot to choose from. Every flavor of data has someone attaching a standard to it, from XML (RosettaNet, large-customer proprietary formats) to the EDI (X12 and EDIFACT). That is why we are talking about Integration; if we just had one common layout for File and Database, we wouldn’t have a lot of these issues.

Another aspect is the agility to deal with new data formats, as they emerge. Spreadsheet formatting is at the forefront of this movement. Whoever would have predicted: spreadsheets as a common data foundation for Integration?

Being equipped with these questions will better prepare a company to deal with the inevitable promises and uncertainties of an integration initiative. Considering a few of points will be especially helpful.

Start with a pilot project and mentoring
Think strategically: where is your business going?
Ask yourself, “Do I need the whole picture or just the key pieces first?”
Your existing team, with their existing skills, can be successful.

Vendors ranging from software companies to integrators to some-of-each will do their best to sell their approach. Knowing the questions will better equip you to sift through the answers.

Mark Denchy is Director of Product Management at EXTOL International. With more than 20 years’ experience in the software field, he has a wide-ranging background in application development and platform integration. He works with several clients on leveraging new technologies that enable integration.

This article originally appeared in DM Review

ITIL for BAs. Part IV; The Service Catalog

Written by Cynthia Low on December 1, 2008. Posted in Articles.

The Service Catalog is one of the primary artifacts of an ITIL-based organization and its orientation toward the business as an IT Service Provider. The Service Catalog is the source of information on all IT Services in operation or being prepared for operation and identifies status, interfaces, dependencies, delivery levels, and other attributes. And in the spirit of encapsulation, the Service Catalog is written in the language of IT’s customers, free of the details about how the service is delivered from an infrastructure point of view

Think of the Service Catalog as the IT “menu” and a Service Level Agreement as a particular customer’s order from that menu. (Service Level Agreements and the Service Level Management process will be the topics of a future article.)

For the BA, the Service Catalog is in one sense an inventory of IT building blocks that contribute to the creation of business solutions. The BA then is interested in, and dependent upon, the catalog in terms of its completeness, accuracy, and its suitability as the basis for specifying the requirements of an IT Service to meet business requirements.

Because of its importance in expressing IT’s purpose and value, the Service Catalog must be maintained through the Service Catalog Management process. In looking at the key triggers, inputs, activities, and outputs of Service Catalog Management, it is clear that the BA has much to contribute toward the content and maintenance of a high-quality catalog:

Service Catalog Management Activities

Agreeing on and documenting the definition of an IT Service – that is “What do we mean by the term ‘service’?” Services must defined to a level of granularity and detail to support their use in business cases in terms of functionality, risks, costs, and other attributes of interest to the customer, so the definitions decided by IT need to be useful to the BA.
Interfacing with the business to identify and document customers’ dependencies on the IT Services and those customers’ needs relative to business continuity (i.e., recoverability). When IT is faced with the need to prioritize (and when it is not?!), decisions need to be based on their relative impact on the quality and availability of IT Services – guidance about which is received from those knowledgeable of the business cases for having those Services in operation.
Interfacing with the business to ensure that the information in the catalog is aligned to the business. The Service Catalog needs to be accessible by various business stakeholders, and just as with business solutions in general, the BA would represent to IT any business requirements regarding the operation of the catalog.

Key inputs to the Service Catalog Management process are clearly in the BA’s domain and include:

Information on business strategy, financial plans, and current and future requirements
Business Impact Analysis – information on the risk, impact, and priority of each service

Much of the BA’s involvement in this process is indirect, addressed as part of the normal set of activities throughout the business solution life cycle. In fact, many IT organizations have survived without any Service Catalog, so its role and value can be elusive – so let’s conclude with a few relevant points:

The goal of ITIL is to encapsulate all of IT in terms of IT Services, expressed in the language of IT’s customers – in other words, ITIL helps an IT organization separate the “what we do” from the “how we do it” – lifting from the Customers’ shoulders the significant burden of having to understand the IT infrastructure and its commensurate complexities, costs and risks.
The IT organization’s mission should be to deliver IT Services with a “service culture”: every IT contributor should be able to see his or her contribution to service quality and availability rather than working solely within his or her particular silo.
BAs themselves are also very driven to make a distinction between the what (business requirements) and the how (the solution to satisfy those requirements).

Back to the “menu” analogy we started with – imagine a restaurant where you can order a meal only after you understand the details about how the kitchen operates, what ingredients it has in stock, which kitchen tools are available, etc.

What about your IT organization? What is the maturity of the IT Service Catalog? Have you participated in the design and operation of such a catalog?

Federal Government

Written by Jonathan Malkin on December 1, 2008. Posted in Articles.

The country is buzzing with excitement over the new administration. Promises of a “change in government” have created optimism about government not seen since Reagan.

How will this new administration be effective? How can this new administration properly administer the agencies of federal government and affect change?

My current projects are examples of the complexity of working with federal government:

Data consolidation for nine federal agencies
Multiple systems across agencies and within some agencies
Standardization of 40 agencies on one system and set of business processes

What are your challenges in helping government be more efficient?

We, as business analysts, have the opportunity to help our country by making government more efficient and by getting more accurate information to decision-makers. We can help government standardize and modernize so the type of data available to CEOs of corporations is available to congress and the president.

In summary I leave a challenge to you and to myself:

How will we, as business analysts, help the new administration get the information it needs to be effective and help streamline and modernize government operations?

Post your comments here or email me at [email protected]. Or you can visit me at my LinkedIn page at http://www.linkedin.com/in/jmalkin

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

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

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.