Tag: Team

Re-Focusing and Re-Energizing Teams

Written by Cynthia Low on May 5, 2009. Posted in Articles. 1 Comment on Re-Focusing and Re-Energizing Teams

How would you measure your efforts to involve the entire workforce in resolving problems that inhibit productivity and their ability to succeed? Although there are exceptions to every rule, it is a relatively safe hypothesis that most people want some control over how they perform their jobs each day. A key factor in the success of teams assembled to analyze problems, define requirements and offer solutions is how management responds to those suggestions. If those suggestions are accepted and acted upon, this is often the catalyst for motivating the team to reach for, and achieve, higher levels of quality.

In my experience, teams that are most successful and have the longest life span are those with the fewest layers of “leaders.” Each leader added into the mix represents opportunity to compromise the effectiveness of communication within the organization. On high performing teams, leadership is a shared role. All members are developed to take a leadership role as required. This structure increases the feeling of responsibility for all members.

Reviving excitement in a team is a considerable challenge that can be accomplished if the team can be convinced their efforts are important and will be rewarded. The first step is to understand the causes of the team’s loss of focus. Successful teams often “cool-off” or lose interest more frequently than those who are struggling. The reason for the loss of focus is often boredom. Teams need a reason to remain excited and motivated. Each team is different and will be excited and motivated by different things. Your challenge is to understand what will excite your teams and motivate them to see the value and pay-off for the projects you’re advocating.

Many organizations complain about not having enough time to get their products out, and their inability to meet delivery schedules. In this case, the paramount question becomes: How can the performance of the teams be improved? First, it becomes critical to understand why there is a persistent problem in order to move forward with attempts to refocus the teams. Is the pressure to meet schedules due to insufficient staff to handle the work, a need for better processes, or people not adhering to the processes?

If the perception is that team meetings will only take away time required to complete the work, it is going to be very difficult, if not impossible, to refocus the teams. This is a prime opportunity for management to evaluate the current situation, and solicit the help of the teams to reach viable solutions. If there are not enough people to complete the work, it is going to be difficult to address the problem through the efforts of the teams. However, if the problems can be addressed through process improvements, this is an excellent opportunity to return excitement and motivation to your teams by asking them to improve the processes. I have always found it necessary to know the members of a team as individuals in order to achieve optimum results. Coaching the managers closest to the teams to attempt to understand what motivates each person, and rewarding the person accordingly, will help keep the teams focused. It is also important to demonstrate that their outputs are important. This means that meetings must be treated as work. They must be scheduled the same as other tasks, with attendance manadatory.

Dr. W. Pearl Maxwell is a Principal Consultant at Advanced Management Services, Inc. (AMS), a full service management consultancy servicing an international client base. Since 1989, Pearl has developed a successful career as an organizational development practitioner, professional trainer and keynote speaker. Pearl has extensive experience working with process improvement and reengineering initiatives helping clients, such as SCC, Sprint, Rehab Care, Symphony Health Services, to create functional business models for enhanced organizational productivity.

Tools of the Trade Part II; Implementing a Requirements Management Tool

Written by Cynthia Low on April 14, 2009. Posted in Articles.

Part one in this series described how to prepare, plan, and select a requirements management tool. Selecting the tool is usually the easy part. Implementing the tool without causing mass chaos brings a greater challenge. Now that a tool has been selected, what is the best way to gain acceptance and adoption of the tool within your organization? Change rarely comes without some resistance. This article will address how to maneuver through the resistance in order to successfully implement a requirements management tool by recruiting early adopters, marketing the tool, and communicating the change early and often. Finally, I will address some lessons learned while implementing a tool at several organizations.

Implement a Tool

Production is not the application of tools to materials, but logic to work.
~ Peter F. Drucker

Form a Team

Once the tool is purchased, implementation will take some planning, training, and mentoring in order to effectively rollout the tool. If you haven’t already, start with forming an implementation team. This team will represent the tool and its benefits to the greater IT department. The team will also help plan, create guidelines and best practices, and mentor analysts in their given departments.

Treat this implementation just like you would any other IT project. Start with a project plan, determine implementation tasks, and assign resources. Then execute on the plan.

Once the project plan is in place, get the team members completely trained and comfortable with the tool. At one organization we brought in the tool vendor to train the team members and a few key QA folks. We gave the vendor some samples of use cases from our own projects and utilized these as examples during the training. Team members then began using the tool on their own projects. As we met together we learned from our own experiences and utilized these experiences to draft best practice guidelines for the organization. Best practices included how to structure requirements within the tool, creating templates for different types of projects, naming conventions, and tips and tricks for some of the tool’s quirks.

Recruit Early Adopters

Once the team has established some guidelines and tested the tool out on their own projects, it is time to branch out. Find a few experienced analysts who are willing to be early adopters of the tool. Have team members train and mentor the early adopters on how to use the tool. Early adopters should then go through a complete project lifecycle while using the tool. Periodically touch base with early adopters to apply what they learned from their experience to the best practice guidelines. Also, gather feedback from the developers and QA team members on their perceptions of the tool. Since these groups typically consume the output of requirements gathering, they will need to accept the tool and perhaps adapt their work habits to accommodate a new method for managing requirements. Don’t underestimate this change!

Communicate Early and Often

As with any change, there will always be nay-sayers and skeptics. Implementing a requirements management tool will be no different. In fact, writing requirements in a tool rather than a Microsoft Word document requires a change in mindset. This change is easy for some to make and difficult for others. The implementation team can smooth this transition through communication. Hold forums where the tool is demonstrated, the benefits and limitations are discussed, and early adopters’ experiences are shared. Hold these forums on a regular basis so that teams are kept informed as to the progress, and reminded of the tools benefits.

Word-of-mouth advertising will go a long way to help encourage other analysts to adopt the tool. Have the early adopters talk about their experiences and spread the good news throughout their teams. After trying the tool on a few development projects, one early adopter expressed his enthusiasm for the tool stating “I want to write all of my requirements in this tool.” By trying the tool out on a few simpler projects, he became comfortable with the tool, its limitations, and saw the benefits gained from utilizing the tool. We harnessed his enthusiasm to help sell the tool during an analyst open forum. He also spread the word to his immediate team members and more people signed up to use the tool on their next project.

An Excuse to Celebrate

Finally, use the tool as an excuse for a party! At one organization, to gather excitement for the event, we hosted online trivia questions on our SharePoint site. We posted daily questions and the top five winners received gift certificates to the event establishment. At the event we re-iterated the benefits of the tool, provided links to training simulations, demonstrated examples of successful projects, and distributed the best practice guidelines. Once the formalities were complete, we broke out the entertainment and used the opportunity to socialize with our peers.

When it was all said and done, the tool implementation was really a non-event. There was no loud outcry, no grumbling amongst peers, no mass chaos, and no wasted money. We methodically went about our task of implementing the selected tool, sought help from our peers, and repeatedly delivered the same message throughout the organization which resulted in an easy transition to tool adoption. The complete process took about a year. We steadily increased user adoption during that year and by the time we held our event, most people had already begun using the tool. Compared with the previous implementation of a tool mentioned in part one, where little thought went into the needs of the user community, this tool implementation went off without a hitch.

Final Thoughts

Wisdom too often never comes, and so one ought not to reject it merely because it comes late.
~Felix Frankfurter

Despite the claims of many vendors, no tool is perfect. It is better to discover early on in the process the limitations of the requirements management tool. Once you know the limitations, devise a plan on how to work around the limitations and minimize the impact to your organization.

Test the performance of the application prior to purchasing. One of the biggest frustrations of a tool I have personally used is its inability to perform when multiple users are accessing the repository. Loading some projects will take 10 minutes or longer, while working in other projects completely freezes the tool. If at all possible, learn this before you buy! It will save you great frustration and keep analysts productive.

Never underestimate an employee’s need to resist change. It’s only natural. We all do it. Plan for it, accept it, and continue to communicate the benefits of the tool even when met with organizational resistance. Eventually people come around and the use of the tool will become a part of daily life within the organization.

Finally, learn from your experiences. Have an open mind and listen to the experiences of early adopters and implementation team members. Tout your successes and learn from your failures. Success will, undoubtedly, follow.

Renee Saint-Louis is a Senior Systems Analyst with a subsidiary of The Schwan Food Company where she established and led an Analyst Center of Excellence. Prior to joining Schwan, Renee served as the Requirements Elicitation Practice Lead at a large insurance company. Renee has been a practicing analyst for more than 10 years.

Seven Tips to Ensure Requirements Management Success

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

The path to building great software goes through requirements management. It’s easy to forget some times, but the world relies on great software. Software operates the cars we drive, the planes we fly in, the cell phones we can’t live without and the tools we use every day to get our jobs done. Software is everywhere.

As a software professional, you know all too well that software development isn’t easy. A software product is never completed. There’s always an opportunity to improve functionality and there’s no shortage of challenges to overcome along the way:

Lots of people involved in the process
Customers have difficulty articulating their real needs
Requirements constantly change
Teams are spread across multiple geographies
There’s growing pressure to release products faster
The complexity of software doubles every 2-3 years
More projects fail than succeed

Whether you’re building a revenue-generating product or an internal system, your company’s overall success largely relies on your software team’s success. And, the path to building great software goes through requirements management. Organizations that embrace this concept enjoy greater results. They experience fewer errors and frustration, faster planning and development cycles and they’re able to deliver higher quality products to their customers.

What You’ll Learn: The goal of this article is to provide you seven essential tips to help you be more successful with requirements management. For some, these tips might be new. For others, these tips will serve as a good reminder of the fundamentals that are easy to lose sight of during the heat of a project.

Tip #1. Stay Connected

You can eliminate most issues by keeping everyone connected.

Much attention is placed on the high failure rates of software projects, and for good reason. Any time there’s billions of dollars at stake and failure rates ranging between 60%-80%, people are going to pay attention. But, what you don’t hear as much about is the root cause. Last year, in The State of Requirements Management Report we polled over 200 professionals about the top challenges they faced in eliminating project failure, and the resounding theme boiled down to one thing – communication. If you can get connected and stay connected throughout the entire development process, you can eliminate the vast majority of issues.

Terminology	Simple Definition
Collaboration	Keeping your entire team connected throughout the development process
Traceability	Keeping all the requirements, artifacts and other related information connected

There are two parts to staying connected. First, there’s the connectedness of your team, which has been popularized recently as “collaboration” – new buzzword, same meaning. Analysts, project managers, developers, testers, product managers, executives, stakeholders and customers – is everyone on the same page about what you’re building and why?

Keeping everyone connected is often easier said than done, but it’s absolutely critical to the success of your project. Depending on the size and location of your team, you can do this manually through meetings, phone calls and documents or you can use a tool to help keep your team connected. It depends on your situation and the complexity of what you’re building. See Tip #7 for the tipping points when a tool might be valuable.

Second, there’s traceability – the act of connecting up the requirements and other artifacts such as use cases, test cases, tasks, defects and even user documentation – all the details that are related to each other within a project. For complex development projects, there can easily be hundreds or thousands of items involved and it’s critical to establish the traceability relationships between these items – both upstream and downstream.

For example, when a high-level business requirement changes 30 days into a project, through trace relationships you can immediately assess the impact it has on any downstream functional requirements, tasks and defects that a developer or tester might be working on. This helps minimize errors and costly rework because the team members affected are aware of the specific change and its impact.

Implementing traceability and a change control process that’s appropriate for your situation is one of the most important steps to ensuring success. As a simple first step to establishing change control, you can use a change request form manually to document changes right now.

Tip #2. Take Action Now

Don’t wait for your process to be “perfect.”

Doing something is better than nothing. It’s easy to fall victim to what you might call “process perfectitis” – a condition reached by teams that get paralyzed by process and analysis versus delivering working software. How many times have you heard someone say, “Well, we’ll get to that project as soon as we really lock down our process? ” Is any process perfect? More importantly, should that really be your team’s highest goal?

Whether your team is practicing some flavor of Agile or not, there’s one thing we can all take away from the principles of Agile – it’s that working software is the primary measure of progress. Don’t get us wrong, optimizing your process is important, very important. We’re constantly tweaking our process. However, if you have a better process and no product, you still have nothing to show your customers.

Doing something is better than nothing. Start small, identify a few critical requirements and take the approach of continuous improvement where you build, reflect, refine and repeat. Then, with each release cycle you’ll learn more about the needs of your customers and continuously improve and expand upon the software solution you deliver to them. If you think your team suffers from process perfectitis, look for these symptoms:

•· Requirements definition phase seems to drag on and on and on

•· In the last month more time when spent talking about process, while your product stayed the same

•· Lack of a decision-maker to make the call when to move forward with development

Tip #3. Eliminate Ambiguity

Successful requirements management begins with writing good requirements.

One of the things you can do immediately is make a “do not use” word list and post it up on the walls in your office. Visual reminders will help you to avoid using ambiguous terms when writing requirements. Karl Wiegers, a well-respected requirements management consultant, in his book Software Requirements provides a good list of ambiguous terms to avoid in requirements specifications. Here’s a snapshot of a few them.

Ambiguous Terms	Ways to Improve Them
fast	Specify the minimum acceptable speed which the system performs some action.
flexible	Describe the ways in which the system must change in response to changing conditions or business needs.
acceptable, adequate	Define what constitutes acceptability and how the system can judge this.
simple, easy	Describe system characteristics that will achieve the customer’s needs and usability expectations.
shouldn’t	Try to state requirements as positives, describing what the system will do, instead of what it won’t do.
robust	Define how the system is to handle exceptions and respond to unexpected operating conditions.

Source: Software Requirements by Karl Wiegers, 2nd Edition, Microsoft Press, 2003

Tip #4. Reconnect with Your Customer

You don’t have to be an expert to capture the voice of your customer – just committed.

This may sound obvious, but it’s easy to lose sight of customer needs as a project gets underway and the team gets to work building the solution. Keep in mind, we use the word “customers” to refer the end-users of the product you’re building – these customers could be external consumers for commercial products or internal users in the case of internal IT systems where other departments and employees are your customers.

Capturing the voice of the customer isn’t a one-time effort. Most project teams do a thorough requirements gathering session at the beginning of a project, but rarely does the customer interaction carry through to the end. Successful requirements management practices include constant communication with customers. Otherwise you risk falling into the classic trap of delivering a product that end-users reject because it doesn’t resonate with how they expect to use it.

There’s definitely an art to eliciting feedback and requirements from customers and clearly some people are better at it than others. There’s a plethora of books and courses out there to provide training for this specific skill. However, you don’t need to be a requirements management expert to capture the voice of your customers. The fundamental skill required is commitment. Commit to picking up the phone every week and talking to customers. Commit to getting out of your office and sitting down with customers in their real environments. These are things everyone on the team can do, and should do. Even in Agile it’s not always possible to have an on-site customer present, so you have to commit to getting that feedback other ways.

Here’s a quick list of Dos and Don’ts to follow as reminders for how to stay connected to your customers.

Dos	Don’ts
Be a journalist – ask open-ended questions	Think you know best what customers want
Talk to your customers every week	Assume past experience is representative of current needs
Be open and flexible to change	Assume customer needs are static
Just pick up the phone and call customers	Elicit requirements & feedback only at the start of a project
Listen with an open mind during elicitation	Sell customer on your idea for how a solution should work
Sit with a customer and watch how they work	Assume customers know how to articulate their exact needs
Close the loop with customers when their feedback has been implemented in the product	Forget to capture and share the evidence you gather with your team

Tip #5. Prioritize Objectively

Avoid building functionality that customers don’t need and may never use.

Development time is so valuable. There’s nothing more frustrating for everyone than wasting time building features that customers don’t actually use and don’t provide value back to your company.

This is where requirements prioritization is essential. You need to avoid the common pitfalls of building features that seem cool or that someone thought a customer might need. Too often, requirements prioritization happens subjectively. The team holds a meeting and in a debate over the requirements the loudest voice wins; or a request comes in from a salesperson who just spoke to a customer and the most top-of-mind request becomes the hottest priority du jour. With each new feature request or high-level requirement, ask these questions to determine if this is a must-have or a nice-to-have feature:

What percentage of our customers will benefit from it?
Does it fit our brand values and enhance a competitive differentiator?
What is the trade-off if we prioritize this ahead of other requirements?

It’s best to establish an objective prioritization model that quantifies the variables that matter most and that each high-level requirement gets evaluated against. That way, by getting agreement on the scoring model, it’s easier to get consensus on the highest priority requirements your team should focus on, objectively.

Tip #6. Minimize Overhead Select the right tools to get the job done.

If you’re a small team in the same office developing a fairly straight-forward product, you can use a whiteboard, task cards and daily face-to-face meetings to manage requirements. A specialized tool in this case could create unnecessary overhead. Likewise, if your team is building a product where the requirements are all agreed upon upfront and won’t change much throughout the course of development, then documents and periodic status meetings may work just fine.

As projects grow in complexity and teams grow in size and geography, so do the communication challenges and overhead of trying to keep everyone and everything in sync. It’s in these scenarios, where a requirements management tool can add value because the overhead of using the tool is far less than the manual overhead it takes to keep track of changes, manage trace relationships, update documents and communicate with everyone on the team.

Here’s a checklist of a few common tipping points where a specialized tool makes sense and can help reduce overhead by automating the process of keeping people and all the related information connected.

Variable	Tipping Point	Benchmarks
Complexity	The more complex the project, the greater the need. If you have over 100 requirements.	72% of teams have projects that on average have 100+ requirements.
Team Size	The bigger the team, the greater the need. If you have over 25 people involved.	Over 40% of teams have at least 25 members and stakeholders.
Location	The more geographically distributed the team, the greater the need. If 10%+ are virtual.	Over 60% of teams have at least 10% of their team working in different locations.
Change	The more changes, the greater the need. If you spend 10% or more of your time managing changes to requirements.	Over two-thirds of teams spend 10% or more of their time managing change.
Traceability	If traceability is a priority for meeting standards or government regulation, a tool is valuable for automating the management of trace relationships, change control and version history.

Benchmarks: The State of Requirements Management Report by Jama Software and Ravenflow, 2008

Tip #7. Don’t Reinvent the Wheel There are many existing templates and resources you can leverage right away.

Even though every company, project and team is unique, the resources needed to help you be successful, in most cases, already exist. In minutes you can do a search on Google and find a wealth of best practices information. As a starting point, here’s a link to more resources from Jama Software and Karl Wiegers for free companion resources to this article: http://www.jamasoftware.com/requirements_management_resources.php

Eric Winquist is CEO and founder of Jama Software. In March 2006, Eric founded Jama with the vision of providing customers a more collaborative way to develop new products and eliminate the common frustrations with traditional approaches to requirements management. Eric is an accomplished entrepreneur, business analyst and project manager with over 14 years experience working with a wide range of organizations. Previous to Jama, Eric founded Redside Solutions, a software development consulting firm.

John Simpson is director of customer outreach, Jama Software. John represents the voice of the customer and leads Jama’s product strategy and communications. John has over 12 years experience working at software technology companies including Microsoft, WebTrends and Omniture. He has contributed to several books, whitepapers and presentations.

They can both be reached through the following: 503.922.1058 [email protected] I www.jamasoftware.com 3/09

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/

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.