6 Ways to Make Organizational Changes Easier
The words “organizational change” always send a tingle down my spine. There are very few things more ignored in the business analysis and project management than organizational change. Almost every project has some organizational change – changes to roles, processes, data, user interfaces, reports. It’s had to image a project that doesn’t impact that organization in some way however how minor.
When you are in a meeting, and you hear the words “We need you to shake things up,” push your chair back and run like hell. James Bond couldn’t be more wrong with change management with his “Shaken – not stirred” approach.
1. The Big Bang versus Small Steps
I’ve had the pleasure – or displeasure – of being that person who led the charge to a better organization bright eyed and full of “Isn’t change excellent!” all the while going down a perilous path. Organizations don’t like big changes or as I call it the “Big Bang.” The larger the organization the harder it is to control the change and communication out to the entire organization about the change (before and after it happens). Organizational change needs to be “stirred – not shaken”. The exact opposite of James Bond's drink of choice. That means avoiding the big bang approach to changes. And to slowly rolling out small changes over a period of time.
Smaller changes are easier to handle and to digest for any organization large or small. The push back on making small changes is “We have no choice but to make a large change” and the infamous “We need it ALL right now”. It’s a matter of organizational disruption. The larger the change, the larger disturbance to the organization and the more likely the change is viewed as negative. The trick is to take the large a break it into smaller chunks, so the organization is "stirred and not shaken." Business Analysis is critical to breaking larger projects into smaller ones because the Business Analyst understands the relationships between requirements and functionality. They are best able to choose which requirements, functionality or capabilities are best included in each release. The role of Business Analyst aligns closely with the business leadership, and they can use that relationship to negotiate better with the project manager on what to deliver in each smaller release.
Sounds like sprint planning? I would agree. You need the entire team working on it to ensure minor releases are constructed. Prepare yourself to change these release as you get to know more about them and dependencies on other requirements cause you to change what is contained in each release.
2. Go Deep to Reveal the Impact of the Change
When eliciting requirements or changes, keep it in the back of your mind about how that requirement would change the organization which in turn leads to asking additional questions to clarify the requirements further. Let’s take the example of making a change to a user interface or screen. The requirements are simple: add this field, move this field to the bottom and change the values in a drop down box that user selects when completing the form. Simple right? Looking on the surface answer would be yes. You need to dig deeper.
That additional field will require training to the users on how it’s used and why. Where is the data for the new field being stored? Will it appear on reporting? Include it in the data warehouse? How will the data entry be validated to ensure quality data is entered? What are the data validation rules for the new field? How does this impact the users of the interface when this field appears on their interface?
The field that moved should be confirmed with users of that interface to ensure it will not break or place a burden on the existing data entry process. Users get in the habit of performing data entry without looking at times and changing up fields on the screen can cause some significant problems.
Amending the values of drop down also opens a lot of questions. What do the data values mean? What does the new data value mean? Can the existing database handle the new value? What about reporting and data warehousing? Will users need to be trained to understand the purpose of the new value and when to use it?
3. Create Common Ground
One of the biggest reasons change fails in an organization is that the organization doesn’t have a common ground in which to stand on. The objective is to create an environment or place where members of the organization can come to understand the change. This can be a website, but sometimes a physical place is needed. The personal contact of swinging by a room or office to learn more about an upcoming change is powerful in that it is far easier to resolve issues about an organization change in person than with email. A virtual meeting space that is manned over a period of several hours may be another approach.
4. Leading the Horse to Water
Organizational changes require a marketing plan. It’s pretty close to the marketing plan your organization uses to acquire new customers. You will need to market the change to the organization. Not everyone is going to be excited about the change as you are. Some may even be plotting to stop it all together. How would you advertise to communicate to your organization? Remember you are in marketing. The idea is to get as many people in the organization (or the part of the organization) aware of the change. How am I going to sell it? Figure out the user profiles. Based on those profiles (expert user, casual user, warehouse user, etc.) put together a WIIFM (What’s In It For Me?) message. Think about how you could send that message more graphically or in an eye-catching way. Remember you’re marketing and you need these profiles to get aware of the change.
Blasting an email out doesn’t always work. Email overflows big time. Find a new way to communicate the message. One approach that I used on a team of 50 was walking around to each of their desks and dropping off a WIIFM flyer with a little candy.
5. Culture is a Killer
If the organization’s culture is averse to any and all change, then naturally the fight will be uphill all the way. As Peter Drucker said, “Culture eats strategy for breakfast.” As a business analyst, continue to use your Influencing Without Authority skill set to push the change forward. In this scenario, you will spend almost all your time paying personal visits to key individuals to help you influence the importance and acceptance of the change within the organization. The “Snow Plow” approach of just pushing forward with a change will not work. Changing an organization’s culture takes a long time. You will not be able to force it overnight.
6. Fast and Furious is a Movie – Not an Organization
Organization of any size by their nature don’t move quickly when it comes to change. To move faster and faster, the organization need to be small. A team of 5 can absorb change far quicker than a team of 50. The larger the impact to the organization the more time you will need to plan change and communicate it. Smaller teams within a larger organization can create the “Snow Plow” effect. After a big snowfall, you need to plow all the roads to open them up. This is the same with change. The small team fans out and starts “plowing” or removing obstacles to the change through the organization. This speeds up the acceptance and understanding of the change. Be careful as not everyone will respond well. You may need to fall back and approach them differently.
Check out more good stuff on the Bob the BA blog. Swing by our website to subscribe to our monthly newsletter and learn more about how Bob the BA can help your organization think, learn and work differently.