These new systems would be perfect, if it weren’t for those damn users.”
The statement made me wince. But Jerry is a frustrated glass-house IT guy. As the VP of IT, he must incorporate current technology offerings to maximize competitiveness. It’s not only the users giving Jerry fits, though, it’s the flexibility of the client/server approach.
In the past, corporate approval came with a cost/benefit analysis. Jerry often backed into a series of cost-saving numbers to win support. Once signed off, he gathered information from the planned users and then, without their meddling, built them a solution. No user reviews. No requirements changed. No problems.
With client/server, though, his approach isn’t working. Things change too fast. Today’s solution can’t be quantified in the traditional cost/benefit analysis. The big wins aren’t just cost savings but better ways to get the results. Jerry was looking for insight because his credibility was fading fast.
I often see this “legacy garbage,” I told him. Many IT veterans don’t easily change, and until they do, their new solutions have a significant fail rate. Until they embrace the new methods, everybody loses: Users have a system that doesn’t meet their current needs, the corporation doesn’t know if it will get a positive return, and IT faces yet another underwhelming project.
But today, many IT professionals leverage the technology to their benefit. They can be flexible to user demands and still be in full control of the situation. With that explanation I got Jerry’s attention, but his expression was skeptical.
This approach allows the project team to determine the benefits of the new system before, during, and after the development. Commitment starts at the inception of the business solution. Rather than using the traditional snapshot cost/benefit analysis, we need to move to a more dynamic model.
Start by reviewing the corporate strategies and goals. Using an iterative refinement approach, frame and qualify a model that identifies the crucial characteristics of our solution. Once the solution’s critical constructs are known, we can at any point determine how well our system is helping the business.
However, building a successful BIM (Business Impact Model) requires solid knowledge as well as careful thought and work during each aspect of solution development. While this model lends itself well to iterative design, it can be used in a traditional waterfall approach. He was more interested.
Planning is critical
The most crucial point is during the planning phase. In this initial step, we identify the solution’s impacts, risks, and current use cases. Leveraging this information, the team applies insight, experience, and user hopes to define desirable use cases. Once these use cases are grouped into subsystems, stating the requirements, risks, and business impacts of our proposed solution is direct and quantifiable. By tying them to corporate initiatives, we can determine and assess the business impact of any chang es in our project’s plans or focus.
During development, we can now easily address those untimely “damn user demands.” We can now at least acknowledge their requests. Jerry smiled. We were bonding.
Rather than trying to enforce rigid requirements that were developed before the project truly began, we can now embrace users’ suggestions as we prototype. We just inject their suggestions into our BIM and quantify the value of the impact. Armed with this information, we determine if the proposed enhancement makes our cut list.
Additionally during the design process, we determine how to best collect the items underlying our growing presumptions of the identified impacts and risks. Easy access to these base measures will allow us to accurately recompute our BIM after deployment.
After incorporating these information hooks into our solution, we are able to determine the production system’s vital stats. Since our BIM will now be using timely data instead of old estimates, we can get a precise reading as to how well our solution is helping the business. With direct ties to the corporate goals and quantifiable financial impact, we can provide some very solid information.
A welcome solution
Jerry was beaming. Like many IT people, he hates when financial and business execs ask him to quantify the benefits of a deployed system. Anything that can help him overcome those nagging inquiries is welcomed. And a flexible approach with this information as a result is a godsend.
Liking what he heard, Jerry was ready to tackle his next trouble spot. Grinning, he leaned forward and said, “Now about client/server benchmarks …”