Sometimes, it’s hard to visualize the importance of business analysis and change management. So here’s a story about a nutty place near where I live. There’s a recycling center just a short ways from my house and the experience at the drop off center is unlike any I’ve ever had. While I haven’t experienced enough drop off centers in my life to know what is standard, the way this particular place is set up boggles my mind. The experience is like this: when you approach the drop off center, you drive along like at a drive through at McDonald’s. There is a person waiting right before the drop off bins to solicit donations. To actually drop off your recycling, you pulls your car up alongside the building and unload. Sometimes there are a lot of volunteers to help you, sometimes there are not. Once your are done unloading, as long as there are no other cars in front of you, you are free to leave. The maximum number of vehicles that may be simultaneously unloaded at any time is about three. The inevitable queue that forms behind the cars unloading can stretch up to eight cars at a time and the wait can be as long as twenty minutes. This seems wasteful and not good for environment. What, with all those cars idling.
I’ve volunteered at this particular drop off center as one of those who helps unload the cars and I have some awareness of the reasons for why things are done this way. The center desires to maximize their chances for realizing donations from those dropping off their recycling and they wish to exact front side quality assurance by ensuring the right recycling is placed within the right bins the first time. This reduces the chances of a loss of revenue if one of their buyers rejects a bin for having too many inappropriate materials within it. This is precisely what you are told when you go through orientation as a volunteer there. There may be other reasons as well.
When I started to volunteer at this place, its primary center of operations was a semi-permanent structure in the form of a large framed tent. When it came time to design a new building for them to move, this would be the chance for a change of business process. Eventually, there was a permanent structure built for this recycling center in accordance with their business processes. The design of it is tightly tuned to the center’s current workflow. Which means nothing changed.
There’s simply no evidence of change. From the outside looking in, it appears that the building was ordered in accordance with their current practices with no thought of flow, customer experience, or even environmental good. Now that there’s a permanent structure, there’s almost no possibility to make changes.
You want a quicker drop off time? It can only be achieved through pre-industrial era means: adding more people. Seems pretty inefficient to me. There’s no parallelism of work. Work is performed serially in an assembly line fashion. It drives me batty.
I can’t imagine what it must’ve been like to be the architect for that project. Architects have long been frustrated with helping people move beyond what is to what could be long before there was anything remote to information technology. Architects and IT professionals could probably go to therapy together.
This example is illustrative of the challenges facing the business. IT professionals often see inefficient business processes in action. As Clay Christensen pointedly illustrates in, “The Innovator’s Dilemma“, business processes by their very nature are highly resistant to change. If they weren’t, they wouldn’t be processes. So when IT is approached with a software purchase or project outline for some in-house development, they’re looking to have a very special conversation with the requester. It’s a conversation that doesn’t come along very often. It often comes in the form of, “So what are you trying to accomplish?” It’s born out of a recognition that our business processes, whether we like to admit it or not, evolved against the tools available. Times have changed, technologies have changed, and organizational capabilities (hopefully) have changed. The iron is hot and the time to strike is now.
It’s not uncommon for the requester to balk at this conversation. They’ve worked closely with their colleagues, they know the nature of their business. In a sense, they’ve already had this conversation, so why are they having it again? My wife and I experienced something similar when we drew up our designs for an addition to our home. My wife took the lead on the project. We had a few conversations about what we wanted, she drew them up, I gave them a vote of confidence, and she took them to the architect. With no prior experience, we didn’t know we would go through a few iterations of needs analysis and design before we reached a final plan.
To be candid, it would’ve sucked if the contractor built what we had envisioned. There were lots of considerations we hadn’t made that the architect surfaced in our conversations. He asked us lots of questions. At first, since we were naïve to the process, there was an element of annoyance. We kind of expected the architect to just take our hand drawing and turn it into a design document for the contractor. We didn’t expect him to start asking questions. I had to laugh when I realized I was eating my own dog food! It took three months for us to finalize the design for the addition. Things started later than we would have liked and we didn’t get settled into our home until just before the first snowfall. But the final product was very satisfying. It met our needs.
Bringing a request to the IT department is not unlike the first hand drawing we brought to our architect. It’s just a starting point for a series of conversations. Business analysts and architects will want to ask a lot of questions. A rip and replace update of the existing workflows handicaps the organization from meeting its future needs. Are you remediating today’s problems or preparing for tomorrow’s opportunities?
Jerry Mechling at Gartner has an approach he refers to as, “Slow trigger, fast bullet“. While Jerry is concerned predominantly with the public sector, I believe there is a general value to this approach. While not all change management techniques are created equal, there is considerable value in any approach that slows down the change and includes a heavy amount of planning and preparation. I don’t mean requirements gathering. I’m referring to larger considerations such as understanding the kind of changes are we seeking for our organization, “What do we want to be able to do? Who do we want to be? Who do we want our customers to be? How do we deliver value today and is it sufficient?” There’s also budgeting for support and ensuring capacity for making the change itself. This question is most profound and often ignored. If your staff is already working at maximum capacity, what won’t get done while the staff is involved with telling user stories, testing, and so on? If there’s ever a time when the old patronizing view of professional staff ever works its way back into full view, it’s the usual response to this question, “They’ll just have to work harder.” Your project just failed right there. It will most undoubtedly be late, over budget, and not meet expectations. To be successful, IT must have the full support of their colleagues. Those colleagues can’t do that without adjustments or additional accommodations for their own work.
For most kinds of changes, the non-disruptive ones, there is little, if any, advantage to being the first mover (see “The Innovator’s Dilemma“). What’s most important is getting the change as right as possible, allowing for refinements along the way.
Our home was built in 1953. Long before we took ownership of it in 2007, the building underwent a number of changes in accordance with the then occupant’s needs. Many of these changes, because they didn’t affect the as-built, went undocumented. So, naturally, once the design was finalized and signed off on by the local permitting department, our contractor found issues that required change orders. On one occasion, our contractor called us in a panic thinking they had found a pipe filled with asbestos. Thankfully, it was just a whole bunch of gypsum. Why it was there we’ll never know. Those change orders begot an adjustment in deadline and budget.
The parallel with how the organization is structured is uncanny. Like it or not, those manuals on the shelf in many department are out of date with how things are actually done. As any new employee will tell you, there’s what the manual says and then what the senior staffer showed them. Job shadowing is where the new employee learns, “How it’s really done around here”.
So when it comes time to purchase that groovy new software, IT and the other department will need to have a series of conversations. Yes, a series. Because change management is more than just installing software, it’s about organizational change. When it comes time to configure the software against your business processes, it’s going to be a lot like pulling back dry wall on an old, old home.
The field labeled, “IT”, contains within it a value chain analogous to the entire building design, construction, and maintenance chain. As any IT professional will gladly share, technical implementation is actually the easiest part of IT work! Consider carefully around how the IT budget is assigned. Are you budgeting for architects, project managers, and analysts? Or are you expecting the IT equivalent of carpenters, electricians, and plumbers to design and manage the construction of your new home from soup to nuts?