Ten Requirement Traps...

Author: Karl E. Wiegers

The path to quality software begins with excellent requirements. Slighting the processes of requirements development and management is a common cause of software project frustration and failure. This article describes ten common traps that software projects can encounter if team members and customers don’t take requirements seriously. I describe several symptoms that might indicate when you’re falling victim to each trap, and I offer several solutions to control the problem.

Be aware, though, that none of these solutions will work if you’re dealing with unreasonable people who are convinced that writing requirements is time-wasting bureaucratic overhead. To persuade such skeptics, present data such as that from the Standish Group’s CHAOS report - a study of 8,380 IT projects which found that more than half were "challenged," with reduced functionality being delivered over-budget and beyond the estimated schedule. The top three contributing factors on challenged projects were lack of user input (12.8% of projects), incomplete requirements and specifications (12.3%), and changing requirements and specifications (11.8%).

Trap #1: Confusion Over "Requirements"

Symptoms: Even the simple word "requirements" means different things to different people. An executive’s notion of "requirements" might be a high-level product concept or business vision, while a developer’s "requirements" might look suspiciously like detailed user interface designs. Customer-provided requirements often are really solution ideas. One symptom of potential problems is that project stakeholders refer to "the requirements" with no qualifying adjectives. The project participants therefore will likely have different expectations of how much detail to expect in the requirements.

Another symptom is that the users provide "the requirements," but developers still aren’t sure what they’re supposed to build. If requirements discussions focus exclusively on functionality, the participants might not understand the various kinds of information that fall under the broad rubric of "requirements." As a consequence, important stakeholder expectations might go unstated and unfulfilled.

Solutions: The first step is to recognize that there are several types of requirements, all legitimate and all necessary. A second step is to educate all project participants about key requirements engineering concepts, terminology, and practices.

I think in terms of three levels of requirements, all of which must be addressed during requirements development (Figure 1). At the top are the business requirements, representing the high-level objectives of the organization or customer requesting the system or product. They describe how the world will be better if the new product is in it. You can record business requirements in a product vision and scope document.

The second level addresses the user requirements, which describe the tasks that users must be able to perform using the new product. These are best captured in the form of use cases, which are stories or scenarios of typical interactions between the user and the system. However, the use cases alone often don’t provide enough detail for developers to know just what to build. Therefore, you should derive specific software functional requirements—the third requirements level—from the use cases. The functional requirements itemize the specific behaviors the software must exhibit.

The software requirements specification (SRS) serves as a container for both the functional requirements and the nonfunctional requirements. The latter include quality attribute goals, performance objectives, business rules, design and implementation constraints, and external interface requirements. Quality attributes (such as usability, efficiency, portability, and maintainability) need to be elicited from users, along with the use cases.

Trap #2: Inadequate Customer Involvement

Symptoms: Despite considerable evidence that it doesn’t work, many projects seem to rely on telepathy as the mechanism for communicating requirements from users to developers. Users sometimes believe that the developers should already know what users need, or that technical stuff like requirements development doesn’t apply to users. Often, users claim to be too busy to spend the time it takes to iteratively gather and refine the requirements. (Isn’t it funny how we never have time to do things right, but somehow we always find the time to do them over?)

One indication of inadequate customer involvement is that user surrogates (such as user managers, marketing staff, or software developers) supply all of the input to requirements. Another clue is that developers have to make many requirements decisions without adequate information and perspective. If you’ve overlooked or neglected to gather input from some of the product’s likely user classes, someone will be unhappy with the delivered product. On one project I know of, the customers rejected the product as unacceptable the first time they saw it, which was at its initial rollout. This is a strong—but late and painful—indication of inadequate customer involvement in requirements development.

Solutions: Begin by identifying your various user classes. User classes are groups of users who differ in their frequency of using the product, the features they use, their access privilege level, or in other ways.

An effective technique is to identify individual "product champions" to represent specific user classes. Product champions collect input from other members of their user class, supply the user requirements, and provide input on quality attributes and requirement priorities.

This approach is particularly valuable when developing systems for internal corporate use; for commercial product development it might be easier to convene focus groups of representative users. Focus group participants can provide a broad range of input on desired product features and characteristics. The individuals you select as user representatives can also evaluate any prototypes you create, and review the SRS for completeness and accuracy. Strive to build a collaborative relationship between your customer representatives and the development team.

Trap #3: Vague and Ambiguous Requirements

Symptoms: Ambiguity is the great bugaboo of software requirements. You’ve encountered ambiguity if a requirement statement can have several different meanings and you’re not sure which is correct. A more insidious form of ambiguity results when multiple readers interpret a requirement in different ways. Each reader concludes that his or her interpretation is correct, and the ambiguity remains undetected until later—when it’s more expensive to resolve.

Another hint that your requirements are vague or incomplete is that the SRS is missing information the developers need. If you can’t think of test cases to verify whether each requirement was properly implemented, your requirements are not sufficiently well defined. Developers might assume that whatever they’ve been given in the form of requirements is a definitive and complete product description, but this is a risky assumption.

The ultimate symptom of vague requirements is that developers have to ask the analyst or customers many questions, or they have to guess about what is really intended. The extent of this guessing game might not be recognized until the project is far along and implementation has diverged from what is really required. At this point, expensive rework may be needed to bring things back into alignment.

Solutions: Avoid using intrinsically subjective and ambiguous words when you write requirements. Terms like minimize, maximize, optimize, rapid, user-friendly, easy, simple, often, normal, usual, large, intuitive, robust, state-of-the-art, improved, efficient, and flexible are particularly dangerous. Avoid "and/or" and "etc." like the plague. Requirements that include the word "support" are not verifiable; define just what the software must do to "support" something. It’s fine to include "TBD" (to be determined) markers in your SRS to indicate current uncertainties, but make sure you resolve them before proceeding with design and construction.

To ferret out ambiguity, have a team that represents diverse perspectives formally inspect the requirements documents. Suitable inspectors include:

• the analyst who wrote the requirements
• the customer or marketing representative who supplied them (particularly for use case reviews)
• a developer who must implement them
• a tester who must verify them

Another powerful technique is to begin writing test cases early in requirements development. Writing conceptual test cases against the use cases and functional requirements crystallizes your vision of how the software should behave under certain conditions. This practice helps reveal ambiguities and missing information, and it also leads to a requirements document that supports comprehensive test case generation.

Consider developing prototypes; they make the requirements more tangible than does a lifeless textual SRS. Create a partial, preliminary, or possible implementation of a poorly understood portion of the requirements to clarify gaps in your knowledge. Analysis models such as data flow diagrams, entity-relationship diagrams, class and collaboration diagrams, state-transition diagrams, and dialog maps provide alternative and complementary views of requirements that also reveal knowledge gaps.

Trap #4: Unprioritized Requirements

Symptoms: "We don’t need to prioritize requirements," said the user representative. "They’re all important, or I wouldn’t have given them to you." Declaring all requirements to be equally critical deprives the project manager of a way to respond to new requirements and to changes in project realities (staff, schedule, quality goals). If it’s not clear which features you could defer during the all-too-common "rapid descoping phase" late in a project, you’re at risk from unprioritized requirements.

Another symptom of this trap is that more than 90% of your requirements are classified as high priority. Various stakeholders might interpret "high" priority differently, leading to mismatched expectations about what functionality will be included in the next release. Sometimes developers balk at prioritizing requirements because they don’t want to admit they can’t do it all in the time available. Often users are also reluctant to prioritize because they fear the developers will automatically restrict the project to the highest priority items and the others will never be implemented. They might be right about that, but the alternatives can include software that is never delivered and having ill-informed people make the priority trade-off decisions.

Solutions: The relative implementation priority is an important attribute of each use case, feature, or individual functional requirement. Align use cases with business requirements, so you know which functionality most strongly supports your key business objectives. Your high-priority use cases might be based on:

• The anticipated frequency or volume of usage
• Satisfying your most favored user classes
• Implementing core business processes
• Functionality demanded for regulatory compliance

If you derived functional requirements from the use case descriptions, this alignment helps you implement the truly essential functionality first. Allocate each requirement or feature to a specific build or release.

Many organizations use a three-level prioritization scale. If you do, define the priority categories clearly to promote consistent classification and common expectations. A more robust solution is to analytically prioritize discretionary requirements, based on their projected customer value and the estimated cost and technical risk associated with construction. (A spreadsheet to assist with this approach is available online; see this article’s Web Infolink for more information.)

Trap #5: Building Functionality No One Uses

Symptoms: I’ve experienced the frustration of implementing features that users swore they needed, then not seeing anyone use them. I could have spent that development time much more constructively. Beware of customers who don’t distinguish glitzy user interface "chrome" from the essential "steel" that must be present for the software to be useful. Also beware of developer gold plating, which adds unnecessary functionality that "the users are just going to love." In short, watch out for proposed functionality that isn’t clearly related to known user tasks or to achieving your business goals.

Solutions: Make sure you can trace every functional requirement back to its origin, such as a specific use case, higher-level system requirement, business rule, industry standard, or government regulation. If you don’t know where a requirement came from, question whether you really need it. Identify the user classes that will benefit from each feature or use case.

Deriving the functional requirements from use cases is an excellent way to avoid orphan functionality that just seems like a cool idea. Analytically prioritizing the requirements, use cases, or features also helps you avoid this trap. Have customers rate the value of each proposed feature, based on the relative customer benefit provided if it is present—and the relative penalty if it is not. Then have developers estimate the relative cost and risk for each feature. Use the spreadsheet mentioned under Trap #4 to calculate a range of priorities, and avoid those requirements that incur a high cost but provide relatively low value.

Trap #6: Analysis Paralysis

Symptoms: If requirements development seems to go on forever, you might be a victim of analysis paralysis. Though less common than skimping on the requirements process, analysis paralysis results when the viewpoint prevails that construction cannot begin until the SRS is complete and perfect. New versions of the SRS are released so frequently that version numbers resemble IP addresses, and a requirements baseline is never established. All requirements are modeled six ways from Sunday, the entire system is prototyped, and development is held up until all requirement changes cease.

Solutions: Your goal is not to create a perfect SRS, but to develop a set of clearly expressed requirements that permit development to proceed at acceptable risk. If some requirements are uncertain, select an appropriate development lifecycle that will let you implement portions of the requirements as they become well understood. (Some lifecycle choices include the spiral model, staged release, evolutionary prototyping, and time-boxing.) Flag any knowledge gaps in your SRS with "TBD" markers, to indicate that proceeding with construction of those parts of the system is a high-risk activity.

Identify your key decision-makers early in the project, so you know who can resolve issues to let you break out of the paralysis and move ahead with development. Those who must use the requirements for subsequent work (design, coding, testing, writing user documentation) should review them to judge when it’s appropriate to proceed with implementation. Model and prototype just the complex or poorly understood parts of the system, not the whole thing. Don’t make prototypes more elaborate than necessary to resolve the uncertainties and clarify user needs.

Trap #7: Scope Creep

Symptoms: Most projects face the threat of scope creep, in which new requirements are continually added during development. The Marketing department demands new features that your competitors just released in their products. Users keep thinking of more functions to include, additional business processes to support, and critical information they overlooked initially. Typically, project deadlines don’t change, no more resources are provided, and nothing is deleted to accommodate the new functionality.

Scope creep is most likely when the product scope was never clearly defined in the first place. If new requirements are proposed, rejected, and resurface later—with ongoing debates about whether they belong in the system—your scope definition is probably inadequate.

Requirement changes that sneak in through the back door, rather than through an established and enforced change control process, lead to the schedule overruns characteristic of scope creep. If Management’s sign-off on the requirements documents is just a game or a meaningless ritual, you can expect a continuous wave of changes to batter your project.

Solutions: All projects should expect some requirements growth, and your plans should include buffers to accommodate such natural evolution. The first question you should ask when a new feature, use case, or functional requirement is proposed is: "Is this in scope?" To help you answer this question, document the product’s vision and scope and use it as the reference for deciding which proposed functionality to include.

Apparent scope creep often indicates that requirements were missed during elicitation, or that some user classes were overlooked. Using effective requirements gathering methods early on will help you control scope creep. Also, establish a meaningful process for baselining your requirements specifications. All participants must agree on what they are saying when they approve the requirements, and they must understand the costs of making changes in the future. Follow your change control process for all changes, recognizing that you might have to renegotiate commitments when you accept new requirements.

Trap #8: Inadequate Change Process

Symptoms: The most glaring symptom of this trap is that your project doesn’t have a defined process for dealing with requirements changes. Consequently, new functionality might become evident only during system or beta testing. Even if you have a change process in place, some people might bypass it by talking to their buddies on the development team to get changes incorporated. Developers might implement changes that were already rejected or work on proposed changes before they’re approved. Other clues that your change process is deficient are that it’s not clear who makes decisions about proposed changes, change decisions aren’t communicated to all those affected, and the status of each change request isn’t known at all times.

Solutions: Define a practical change control process for your project. You can supplement the process with a problem- or issue-tracking tool to collect, track, and communicate changes. However, remember that a tool is not a substitute for a process. Set up a change control board (CCB) to consider proposed changes at regular intervals and make binding decisions to accept or reject them. (See "How to Control Software Changes" by Ronald Starbuck in STQE, November/December 1999, for more about the CCB.)The CCB shouldn’t be any larger or more formal than necessary to ensure that changes are processed effectively and efficiently. Establish and enforce realistic change control policies. Compare the priority of each proposed requirement change against the body of requirements remaining to be implemented.

Trap #9: Insufficient Change Impact Analysis

Symptoms: Sometimes developers or project managers agree to make suggested changes without carefully thinking through the implications. The change might turn out to be more complex than anticipated, take longer than promised, be technically or economically infeasible, or conflict with other requirements. Such hasty decisions reflect insufficient analysis of the impact of accepting a proposed change. Another indication of inadequate impact analysis is that developers keep finding more affected system components as they implement the change.

Solutions: Before saying "sure, no problem," systematically analyze the impact of each proposed change. Understand the implications of accepting the change, identify all associated tasks, and estimate the effort and schedule impact. Every change will consume resources, even if it’s not on the project’s critical path. Use requirements traceability information to help you identify all affected system components. Provide estimates of the costs and benefits of each change proposal to the CCB before they make commitments.

Trap #10: Inadequate Version Control

Symptoms: If accepted changes aren’t incorporated into the SRS periodically, project participants won’t be sure what all is in the requirements baseline at any time. If team members can’t distinguish different versions of the requirements documents with confidence, your version control practices are falling short. A developer might implement a canceled feature because she didn’t receive an updated SRS. I know of a project that experienced a spate of spurious defect reports because the system testers were testing against an obsolete version of the SRS.

Using the document’s date to distinguish versions is risky. The dates might be the same but the documents may be different (if you made changes more than once in a day), and identical documents can have different "date printed" labels. If you don’t have a reliable change history for your SRS, and earlier document versions are gone forever, you’re caught in this trap.

Solutions: Periodically merge approved changes into the SRS and communicate the revised SRS to all who are affected. Adopt a versioning scheme for documents that clearly distinguishes drafts from baselined versions. A more robust solution is to store the requirements documents in a version control tool. Restrict read/write access to a few authorized individuals, but make the current versions available in read-only format to all project stakeholders. Even better, store your requirements in the database of a commercial requirements management tool. In addition to many other capabilities, such tools record the complete history of every change made in every requirement.

Keys to Excellent Software Requirements

While these ten traps aren’t the only ones lurking in the requirements minefield, they are among the most common and most severe. To avoid or control them, assemble a robust toolkit of practices for eliciting, analyzing, specifying, verifying, and managing a product’s requirements:

• Educating developers, managers, and customers about requirements engineering practices and the application domain
• Establishing a collaborative customer-developer partnership for requirements development and management
• Understanding the different kinds of requirements and classifying customer input into the appropriate categories
• Taking an iterative and incremental approach to requirements development
• Using standard templates for your vision and scope, use case, and SRS documents
• Holding formal and informal reviews of requirements documents
• Writing test cases against requirements
• Prioritizing requirements in some analytical fashion
• Instilling the team and customer discipline to handle requirements changes consistently and effectively

These approaches will help your next product’s requirements provide a solid foundation for efficient construction and a successful rollout.

Managing Change...

Following is an article which appeared in June’09 edition of Aviation today. It brings out factors of resistance for any change and how to manage them (Sourced by Ajay):

Analysis of several failed ERP implementation projects show that, general resistance to any type of change and specific end-user resistance to the ERP implementation efforts are some of the most significant roadblocks that are encountered in the road to success. There are three major reasons why people resist a change. They don't get it (Level 1), they don't like it (Level 2), or they don't like you (Level 3). Any one of those can stop the ERP dead in its tracks. And what you need is the opposite of all three: people need to get what it's all about, they need to like it and be willing to take part in making sure it is a success, and they need to have confidence in you.

Attached article explains some thoughts in change management w.r.t. aviation maintenance. Lengthy article, takes time to read it. Enjoy reading.

Change Happens: Resistance is Futile

By William Maly

In aviation, one thing is for sure — things change. New technologies, equipment and even shift changes can cause consternation. The best employees are flexible and adapt, but it’s not always so easy. As Franklin Roosevelt said, "The only thing we have to fear is fear itself."

Politicians and corporate officers have used the powerful word "change" in recent months to convince voters and lenders to support their causes. The word demands action from those involved and certainly comes with a fair share of risk with everyone concerned.

For years, aviation technicians have encountered their own challenges with change in technology advancement, procedural requirements, administrative laws and a host of other practices. While mechanics normally possess excellent troubleshooting skills and are very resourceful with an excellent mechanical aptitude, some lack the skill of coping with change. Whether it is a new tool to help ease a difficult job or a manager asking for a shift in their schedule time, some technicians develop a resistance and have no desire to try the change.

Fears

When change is initiated, fears develop; we feel we are losing control of our environment, worry about our self-interests and are skeptical that the change is even necessary. In discovering some of the underlying reasons that technicians oppose change, and develop skills to cope with it, we become better within our career and also in our personal lives.

Next-generation aircraft have capabilities and resources far beyond that of aircraft from past years. Onboard computers can pinpoint problems and generate solutions. Engine diagnostic information develops fan balancing without extended engine runs in a remote location.

Computer-generated displays provide tire pressure, engine parameter exceedance, hydraulic, pneumatic, fuel and cabin temperature readings at a touch of a button. These new technologies are tremendous tools when utilized, but are useless when they intimidate the technician attempting to use them.

Gaining Trust

While completing an overnight check and running the diagnostic onboard computer test on the Boeing 777, a mechanic finds a problem. The computer indicates that an engine fan-air modulating valve isn’t working properly.

Trusting the new technology and replacing the valve would be the sensible action. But instead he spends a significant amount of time attempting to reset the latched indication because of past erroneous signals he has chased through the airplane. It is only after he reluctantly tries a new valve that he trusts what the computer already knows; the valve is malfunctioning.

When I asked aircraft mechanics about this predicament, their input explains some of the problems that can be encountered when trusting new technological information.

Arnie Cardenas, a 20-year mechanic, states that "to dismiss a ghost (faulty) message, a technician has to aggressively troubleshoot the system. Randomly replacing expensive parts to repair a chronic problem at times is futile and benefits neither the company nor the technician."

Learning Curve

Gary Lakie, also a mechanic, believes that trusting the computer and not peeling away the layers diminishes the technician’s troubleshooting abilities. "Technicians have lost that edge to troubleshoot problems. It becomes a factory setting in which you just remove and replace the part to see if it corrects the problem," Lakie says.

Jerald Jellison, professor of psychology at the University of Southern California, believes that time may factor in this situation. The mechanic may have more time to diagnose the problem and not immediately trust the computer because of his/her historic experience with the information. What Jellison would find unproductive is if the technician doesn’t change his judgment after the occurrence. "I guess the only fault would be if you didn’t revise your opinion of the computer afterwards. You would have to conclude that you were wrong about that and the next time you’ll trust it more," he says.

Keeping an Open Mind

Accepting something new requires faith and an open mind. Technology is normally developed for problems in our industry. The goal of the new devise is an easier path for better production, safety and efficiency. Many remember a time when ATA manuals were in book form. There was also a time when the manuals were on microfiche. Then CD-Rom made the process easier through a computer and now most aviation maintenance resources are accessible through a database computer system, which provides updated information quickly to the source.

Resistance to change is not exclusive to technology. Your manager decides that your start time would work better if moved forward by an hour. He explains to you the reasoning, but your belief is it doesn’t address the true problem they are attempting to solve. Because of the disruption in your personal schedule your self-interest is harmed. You reluctantly start your new hours but uncommitted and disinterested. The spiral begins, and as you lose your dedication to the job, the manager loses confidence in you, and so it goes.

Lakie believes that not fully understanding the problem creates reason for doubt. "I think the change is never understood by anyone as a whole; the reasoning they’re implementing it and not taking into account the technician’s who have to rearrange their lives to accomplish it," he says.

These failures provide one common denominator; resistance to the new technology or the idea that change doesn’t work. While the old way will get the job done, the ability to work smarter, safer and quicker is lost if we immediately reject the change.

Why We Fight Change

There are a number of reasons why we resist change. It is important to recognize these negative behaviors to change and develop the skills to correct our immediate resistance to the new process.

Experts consider our self-interest the primary concern when change is announced. Cardenas believes that self-interest also benefits our work atmosphere. "A person who maintains his self interests makes it better for all. It develops a happy workplace as opposed to a miserable one," he says.

"Self interest is the root cause," Jellison adds. "What we don’t always realize about ourselves is the thought of going through a change, because we do become frightened, and we think it (the change) will have a negative impact on our self-interest, we’re going to lose control in a situation, we’re going to make mistakes and look foolish, and at times we may even think we could lose our jobs," he says. "What we do is we exaggerate the consequences of what failure would mean. That’s what I call going over an emotional cliff in that, when we anticipate what’s going to happen, we just inflate it."

Attitude Adjustment

Understanding that going through change is a team activity and a way of developing a healthy attitude for the new process. Mechanics have a vast wealth of knowledge and skills that each can draw from. When taking on that new task we use the internal support system looking for someone who has done this or something comparable. It gives us confidence in doing the job and provides a new skill we can pass on to the next person. During change we can use the same support method. One person can mentor the next until the team is proficient at the new change or technology. Support is more than just management providing resources. It is at the ground level when we assist each other through the difficult or unknown.

When asked how he deals with change, mechanic Phil Wyka says, "I approach my co-workers and ask their opinions of the change and develop my personal approach from that point and if the change is something I have insight on, I will certainly provide guidance if asked." Most importantly, when facing a change at your job, your attitude is the essential factor of your acceptance. The act of closing off and becoming immediately negative to the change does not benefit anyone and only interferes with business and professional goals.

More Than Communication

Managers hastily point to communication as the prime persuasion tool to inspire doubtful employees. Professional consultants agree to an extent, but do advise caution when relying on only this particular resource.

Communication is an open system that allows the manager to explain the change, the reason for the change, benchmark goals, and expected obstacles. It should provide the management and employees a path to discover the difficulty and develop a new technology together. Valuable feedback to management and other departments can assist the change for adjustments when necessary.

Sherrie Campbell, a business professional counselor and host of a statewide PBS special Good News, believes that validating the employee’s fear is critical for a manager trying to implement change.

When asked about resources for managers and employees to tap into for change assistance, Campbell points out, "There are tons of coaching books about change. But the biggest tip — know your employee and you’ll know which resource to use. If you hand an employee a book on how to accept change and haven’t validated their fears, you may have just driven a bigger wedge."

Management Focus

All too often in our careers we witness management speaking at us, but not with us. The manager is divided between accomplishing his goals and satisfying the employee’s needs. When these obstacles appear, it is important for managers to understand that employees are the solution to the problems and have valuable input that can provide answers.

Leaders will find that employees are very persistent in continuing the old way of doing things. Campbell believes that words carry very powerful meaning; using the term "the old way" implies the wrong significance. "Why not go through the current way and all of the aspects that work. Then ask what aspects may not be working as well. Then brainstorm. Give your ideas and changes along with hearing their ideas. You may be surprised," Campbell says.

Jellison has authored a number of books providing guidance on organizational resistance to change and has developed a program for leader direction during change implementation. Most managers believe they can win over the biggest resistors through persuasion. Persuasion is a silver bullet solution with the concept that influencing employees will alter their behavior. While this course changes a few employees’ minds, more often than not, it does little to motivate a person.

Activation

Jellison advocates a process called activation. This is a bottom up approach designed to get employees to take action even when they have doubt or fear of the change.

Jellison outlines basic concepts that help manage employees through change. Communication, while not emphasized, is necessary between managers and employees. "The key to communicating down at the ground level is to be very specific about what you want the employee to do," he says.

Clarification of the business goals with those initiating the change counters resistance. This step will also present an opportunity to understand the end objective and provide input in the change development while also dispelling rumors. This leaves no ambiguity and provides a definitive leader when employees need it most. "Remove the barriers," he continues. Find the obstacles that will bog down your change implementation and get rid of them. This process will remove footholds that resisters will dig into and defend their assumptions. Front-load the rewards, praise your employees early and often and if incentives are an option provide them immediately. "Praise your employees just for trying the new process, whether they are successful or not, it keeps them going," he says.

Although activation is more time-consuming than persuasion, management gets a tremendous return on their effort. Through the added energy, managers have the ability to include employees in the change while assuring the goals of the company are acquired. It provides ground level understanding of what is working and what isn’t and it establishes ownership in the business.

Technology Transformation

Today’s maintenance problems are more complex and involved compared to airplane issues of the past. Aircraft like the Boeing 777 and the "next generation" 787 come with the standard equipment to fly but also provide useful tools that can improve a technician’s chance at making a quality repair on the first try. It is our responsibility to not only be a quality technician but also develop skills to interpret and use some of these new technologies and resources to help us do our job.

Better technicians realize it is essential to overcome our fear of change to move us forward in our careers. The cliché "thinking outside the box" certainly applies to this situation. As mechanics in today’s complex technical aviation industry, it is in our best interest to understand our struggle with change and adapt to it.

PS:

Continual Improvement

An airline I worked for purchased a new Panasonic Toughbook computer for technical maintenance data improvement. The laptop allowed for maintenance manuals, illustrated parts catalogs, company part ordering and technical information, and a collection of other resources carried directly to the aircraft problem. It was a valuable tool for better efficiency, providing needed resources to the fingertips. Very versatile, it was extremely useful on trips when recovering incapacitated aircraft or use at a station in remote areas. During a training class discussing the computer’s operation it was revealed that the Toughbook was scarcely used for unknown reasons. It was later discovered that a few bad experiences by mechanics spread through word of mouth and the computers went ignored. The Internet speed was slow and connecting to the resources was next to impossible in many areas. Unreported, this developed two problems, the first being that a valuable time-saving tool was not utilized to repair airplanes. The other problem was that those who provided this computer were unaware of the networking issues and did not get the opportunity to fix it. The digital age is moving information faster than ever and only assists us in our jobs. As a technical crew chief I am able to send a digital photo of aircraft damage to the engineering department, technical department and management in milliseconds. Five years ago we were taking pencil rubbings of the damage and faxing them to these decision makers and 20 years ago we were trying to give our best definition of the problem over the phone. There is nothing wrong with a fear of the unknown, allowing it to intimidate you is where we begin to lose our edge. University of Southern California Psychologist Jerald Jellison says that, "there are no promises of ‘try it and you will like it,’ but what can be promised is if you do try it, you will learn and grow." Moving our profession forward requires technicians to understand change is continual and unstoppable. When the computer problems were eventually addressed it gave the airline mechanics a beneficial resource to fix aircraft. The mechanic’s responsibility goes much further than repairing airplanes. We have to develop skills to cope with the new change, give feedback to those who require it and stay positive while implementing it.