We can probably agree that, for the most part, change is good. But it is also disruptive, and can even create chaos. In this column, Becky Winant explains a familiar model of the change process, and offers some ways to acknowledge and cope with change in the workplace.
Twenty-five centuries ago a Greek philosopher, Heraclitus, proposed this universal law: There is nothing permanent except change. While his philosophy may have been a bit abstract, his catchy quote feels familiar to contemporary analysts.
Isn't it amazing that we sometimes act as if change doesn't exist? The fact is, it is everywhere. Customers request changes. Then they interrupt us to add a few more changes. Developers make changes to accommodate technology. Testers weed out undesirable change. And of course, the implemented system, by intent, changes the customer's routine.
We can't control change and we certainly can't fight it, but we can learn how to cope with it. We can be sensitive to how it affects our customers, our colleagues, and ourselves; we can introduce practices to cope with project and requirements changes; and we can seek assistance with both.
The Phenomenon of Change
Psychologist and family therapist Virginia Satir observed that a predictable process of change applied to individuals and groups alike. Her model looks like this:
She explained that people would be jolted out of the familiarity of status quo by a foreign element heralding that change has occurred. The source of the foreign element may be outside influences—a competitor releases their product ahead of yours—or internal decisions—features planned for later versions are abruptly added to product development. For many people, the foreign element throws them into chaos, resulting in confusion, indecision, or inappropriate responses. A transforming idea can take you out of chaos; you realize how to move forward through change. Assimilation and learning begins, as you adjust to change. The new status quo takes over when comfort returns.
Acknowledging Chaos
Satir's model explains why change is disruptive, and our jobs are all about change. By being aware of how change produces chaos, we might find transforming ideas sooner.
- We impose change on ourselves
We embrace new ideas about improving our ability to identify true requirements. Sometimes we embrace these new ideas successfully. Maybe you have heard something like this: "If we adopt the XYZ process everything will fall into place" or "If we send everyone to class to learn the ABC techniques, then we will have everything under control." This might or might not happen. With change initiatives, organizations can unwittingly introduce a "foreign element" then expect "new status quo" to follow directly.
- We push change on others
My consulting work frequently falls in the wake of a foreign element. Managers hire me to facilitate change or new approaches, which people may not want. During one such meeting for a client, Jim arrived late and sat tight-lipped with arms crossed. When I asked people about their experiences with requirements definition, Jim drew dart-like arrows, a clear message. He loathed the process, explaining that in his last job the requirements were used to control the software developers. Jim was forced to change his code every other week without a satisfactory explanation. Now he feared my presence confirmed the changes recently announced by his manager. For us to develop a process that would include Jim, we had to respect the fear and insecurity that change brings.
- Our customers dive into change
Customers want systems to keep pace with changes in their business. When requesting a new system they might be reacting to a foreign element they haven't quite grasped yet. As we ask questions expecting people to know what they want, they may be honestly unaware of their needs because they are still trying to figure them out. Change may be forced upon them, and in turn, they ask us for more! For this reason, people may ask for changes that won't solve their problem and that they don't really need.
- We love innovation, yet suffer through change
Customers may be nervous about system changes. Replacing a critical system, people would be understandably anxious: What if it doesn't do what I expect and affects my ability to perform my job? Customers might delay upgrade purchases: Let's wait and see if it does what we really wanted. People watch for turmoil in new products and new releases in the form of bugs. We may want the new features, but wait to see if it will be painful.
Below, I have added a list of practices that may help you.
Practices for Coping with Change
Despite attempts to "freeze" requirements, we can't stop people from expressing their wants and discovering new needs. How do we accept this new information without blowing the schedule, the budget, and our patience? Here are four useful coping practices:
1) A change request process for requirements
Have you ever been on a project where someone took notes about changes to the original direction, but never formally wrote them up as the project was racing forward to implementation? A process for handling all types of change avoids slip-ups. Two key ingredients make this process work: a) having a clear interface and a mechanism for capturing the request, and b) having a clear means of reviewing and assigning priority.
2) A section for future concerns and needs in requirements documents
As we listen to what is wanted now, we often hear about other ideas and expectations people have about the future. These possible scenarios can be explored and recorded. When working as a designer I found "future" statements particularly helpful in guiding my software architecture choices, which contributed to easier changes later on.
3) Version planning
A common practice is deferring requirements to a next release or version. If customers change or add requirements, the whole set might be assessed or renegotiated to determine what to do now and what to do later. Generally this process weighs customer preferences, partitioning of features and functions, technical feasibility, risks and opportunities, and estimated effort.
4) Document baselines
While requirements work is exploratory, many analysts develop significant industry expertise. A friend, May, has spent many years in the insurance industry. She knows that regardless of type—health, life, or property and casualty— there are common themes: setting premiums; monitoring sales, payments, and claims; adjusting rates; conforming to government regulations; and, for some types, linking to financial instruments. May captures the functions and events that form a basis for these themes. She captures this in several documents, called baselines, and uses them as a starting point. May asks current customers how this is the same as their system and how it is different.
As you start requirements for your next project, remember to acknowledge the cycle of change and build in ways to cope.
