It seems that there are many forces at play that are almost designed to create or exacerbate change anxiety. Professionals in industries whose business models depend on stoking our change anxiety bombard us with article after article on social media. Industry conferences that consistently display whichever adoption curve you’re supposed to be on at the moment—hinting that you’re seriously behind where you should be, with the looming possibility that you’re about to go out of business because of it. Yesterday it was the cloud, today it’s RPA and AI (or IA depending upon whom you ask), and tomorrow it will be something else.
But even with all of this change coming at us, perhaps most troubling is that feeling that if you just stop for a minute to think and reflect, you may be labeled as entrenched, unwilling to adapt, a dinosaur, or something worse.
The transformational programs that we work on tend to reveal many of the stresses that permeate our clients’ professional lives. In deal work, one of the first places you see this is when a request for proposal (RFP) is being drafted that is supposed to reflect a progressive vision.
These deals are fascinating and exciting because there really is a lot on the table. They can be game changing—the change is challenging and we very well may be creating some new ways of operating. Each new relationship, and each new deal, has the potential to be the first to solve a problem or exploit some unforeseen opportunity.
But it is important to remember that as exciting and energizing as these programs can be, when there is a lot on the table, the opportunities and new operating methods could go either way, and in many cases the perceived pace of change is driving execution at a speed that can make the change lose its effectiveness.
Not all projects or programs are created equal, and while it may be okay to “fail fast” when you’re automating a process or two, there are times when failing fast can have real and dire consequences.
If you are in a situation where you or your team are feeling some unusual anxiety about the change wrapped up in a transformational program, you may be bothered for reasons that transcend the challenge of the transformation itself.
This can be tricky to handle, particularly if momentum has built around the project and that makes it difficult to speak out. Taking a step back and doing a little basic blocking and tackling can still go a long way. This is particularly true in the current environment where terminology can mean different things to different people. A simple real-life example from a few years ago might help illustrate.
Back in the “old days” (2015), when “innovation” was the hot buzzword in outsourcing, there was a particular deal that was supposed to be transformative, and was procurement and IT led. The requirement from the RFP that “the client will retain innovation” was brought to our attention by a person on the team who had worked with us before and wanted to clarify the statement’s intent. It took a little prodding, but it turned out that the statement was really a reflection of the client’s view that its business was constantly changing, and the requirement was actually that the potential partner had to be responsive to very challenging market demands that require relentless product, delivery, and promotional innovation. The client really wanted to be liberated from technology constraints and retain its ability to direct its product development and deployment.
As far as technology was concerned, this client was looking for a partner that could bring new and innovative solutions to the table based on the demanding product innovation cycles noted above. In other words, the actual requirement was for the vendor to be very responsive to quickly changing requirements, and to deliver new development methodologies that would enable the tech cycle to be as short or shorter than the product marketing cycle it was supporting.
Had the clause in question been left as written, the RFP would have (1) completely missed an important requirement for the relationship; (2) set up a point of failure by requiring the client to take on a responsibility that it did not intend to take on; (3) used a word that was essentially devoid of meaning in the context it was being used; and (4) prolonged the contracting process because an issue like that is more difficult to deal with in the contract stage than the RFP stage.
This is a good example of the positive impact of someone who had an uneasy feeling about a requirement and took a quick step back to reflect.
In today’s environment, you may get called upon to participate in something that feels like it’s moving too fast, is changing too much, or involves jargon that makes you feel uneasy. At times like this, a little reflection, and taking the time to just think about what is driving the change, can go a long way.