Looking back across my career, I’ve had the opportunity to work with many different and unique businesses, operating in various industries. I’ve also worked on a wide variety of projects, from new application development, to solution selection, to solution integration and implementation. One thing that I’ve learned during that time is that for all the differences and uniqueness, most businesses and projects have much more in common than most people expect. Sure, the culture of a business or industry might be different, and work being performed might be completely unique, but many of the underlying needs, attitudes, approaches, personalities, and behaviours that you encounter from one project or business to another are fundamentally the same.
As a business analyst, you begin to see the patterns over time and it often doesn’t take very long to evaluate the impact that a new project will bring to an organization. I’d like to talk for a moment about one thing that is nearly universal – how the perception of loss can overwhelm any possible gain that a project might offer. It’s something that anyone working on a project team, in any role, should seriously contemplate when planning project work.
How many times have you worked on a project, implementing a solution that would allow your customer to modernize and streamline operations, improve business performance, or provide new business opportunities, only to wind up in meeting after meeting addressing that one piece of functionality that the customer will lose? In many cases, the impact of the lost functionality might be relatively small when compared with the potential gains from the project, but that single element of lost functionality can cause significant delay to projects, or can turn potential project champions into project roadblocks.
You can go online and find all sorts of research about the topic in the area of economics – you can expect the average person to perceive a loss to be about twice as important as an equivalent gain. I’ve personally found this to be true with my project work, often at an even higher rate than just double. Stakeholders are afraid of change, worried about how it will affect their jobs, worried about dealing with problems and issues. They don’t trust process change or new software systems, and they might not trust you if you are the one bringing the change.
So, what are some ways to address this huge difference in the motivation of loss vs. gain? Take a look at the work being done in change management. The whole concept with change management is to analyze how the changes in a project will affect stakeholders. Most projects spend much too little time analyzing their stakeholders, and identifying and developing project champions while creating strategies to manage resistant stakeholders. In change management, you need to build awareness of the change, work on removing the fear, and give your stakeholders the tools and training that they need to succeed.
There’s definitely a psychological impact that most projects avoid or completely ignore. Change is a very personal thing. A small negative change can trigger surprisingly large reactions, while significant gains can easily be forgotten or minimized by your clients and stakeholders. It is extremely important, as a business analyst, to develop trust with your client and stakeholders. Be honest and upfront. Provide as much information as you can. Sell your project. Don’t forget to consistently and regularly talk about all of the positive elements of your project. Consider doing this formally, and mapping out both the positive and negative impacts for your project. Work hard at understanding the impact of lost functionality. Spend time looking at underlying requirements, and search hard for creative ways to mitigate negative consequences of your project’s changes.
When you start your next project, consider taking the time to analyze any possible perceived loss from your stakeholders’ perspective. If you take the time to formally identify these issues early, and develop a strategy and approach for addressing loss, you’ll be in a better position to deal with project resistance. Make sure that you regularly and formally communicate all of the positive results from your project, and look at some of the great change management practices that have been developed and investigate how you can apply these practices to your project.
In my last post, I mentioned that one problem with my earlier unit tests was their dependency on database access. Having my tests directly dependent on the database created slow-running tests and tests that were prone to failure as the database changed. Over the course of this post, I’m going to demonstrate some of the techniques I have learned that provide the ability to decouple a set of code from using direct database access. Note that the examples are in … Continue reading
I recently took part in a course called “Mastering the Complex Sale” by Prime Resource Group. One key thought the instructor, Jeff Thull, communicated really stuck with me: “If you don’t have a system, you will be going into somebody else’s.” This thought is really becoming one of my mantras as it relates to me as a consultant and to consulting companies. The “system” being referred to is simply “the way we do things.” The message is basically one of … Continue reading
← Older posts