Improving software processes by engaging the business stakeholders

The last couple of posts about the collaboration between Business and IT have revolved around the active reaching out from one side or the other to engage the other team. Much of the commentary described problems with regard to different teams communicating poorly, which resulted in poor understanding of the total picture. Resolutions to these issues enhance team cohesion, because all participants begin to comprehend what their team mates need.

Another aspect of this, though on a grander scale, is the need for cohesion between Business and IT on projects that involve  process development or improvement efforts. Process work is only one facet of a business analyst’s skill set, but these projects often span multiple organizational units, disciplines, political boundaries, technologies, and personnel resources. So, no matter where in the process a failure occurs, the feeding or consuming portion of the process that surrounds the failure is impacted. To make matters worse, a single failure can have multiple downstream consequences due to dependencies that are sometimes not viewed as direct consumers of an upstream activity.

When I think of process work, I generally think of a business process that starts and ends on either the business or IT side. In other words, the boundaries that currently separate an IT department from an organizational business unit generally contain the processes within each. Recently I came across one that DID cross over (and, no….I didn’t get to speak with my deceased grandmother). I work for an organization that has multiple divisions in different states and multiple business units inside each division. When requests for change to their common application suite come in to IT (which services all divisions), it has not been uncommon to see duplicate or conflicting requests. Moreover, our IT development capacity is limited and the various tidal waves of changes, defects, and project work orders was overwhelming us. To make matters worse, once a change arrived in IT’s hands, the original process no longer was able to handle the request efficiently, thereby double-dipping IT resources.

At some point, I began to look at the process that was governing all this and realized it was very broken. Immediately, I identified the largest siphon to our capacity, and that was the fact that we were spending huge amounts of time facilitating conversation between business partners who had previously not discussed among themselves what their wishes were. Some of these conversations went on for weeks as meetings were adjourned and decisions were delayed. Additionally, we had no method for funneling all work of this nature down a single path to realistically define impacts to capacity. The obvious choice was to push all of this back onto the “business side” to let them fight their own battles.

When I first began to broach this subject, there was considerable consternation, defiance, avoidance and other push back. Much of that was simply because there was no visibility as the consequences of this issue.  Eventually, when a negative dollar value was attached to it, the light went on. What’s a negative dollar value? For this scenario, I showed them step-by-step where business was paying for IT to participate in core business functions (like decision-making meetings) yet were providing no deliverable to business and were also not providing value worth the time we in IT were spending doing it.  I had to come up with a way to communicate that we did need to place some activities on the business side, and I did that by doing two things.

First, I dug deeper into the problem and was able to identify the productivity failures that IT was having due to the high volume of non-productive work when engaging with business on the change process requests. Each one of those was mapped to a function that if taken over by business, would better serve them in the end, because IT would be able to deliver more code when not working through business issues.

The second thing that really helped was two-fold. We created the new process that governed both business and IT when handling change, but each activity was created or modified during a partnership between the two entities. Each improvement in the process also included a value statement for both Business and IT, so there was clear understanding of the goals. All participants were as much a part of the solution as they were the initial problem. I also created a full set of checklists that governed all the major decision making, set expectations for deliverables up front, and assisted in making determinations for when to bypass portions of the process due to emergency needs. The checklists were delivered as aides to business to help them function, and each would start getting used very early in the business-only portion of the process and follow the request through as it is turned over to IT. These set the expectations for business from IT and helped to define areas that business could understand what the expectations were before they started to work on a change (read: less rework).

To wrap this up, I could have reworked everything on my own and presented it as an IT solution. People don’t really like change though, and having them be a valuable part of the solution creation process allowed us to change together for the good of the whole. We are currently in the middle of implementation and are working through small portions of the flow in each phase together. The creation, adjustments, measurements, decisions and successes are all a result of this collaboration….and all of a sudden people are geared up to change. “Their” problem is now “our” problem and we’re fixing it together.