May 21, 2002
From a senior management perspective, everybody pretty much expected and liked BAP's efforts toward aligning HomeWorks' IS and the business in the areas of financial accountability and IT strategy. Although his work was valuable and well received, Jesse Reed's strategy efforts really didn't touch (directly) many people beyond the executives and a few other key business leaders on a daily basis. The same applied to Steve Wilson's financial improvements — everyone expected that IS would become more financially accountable and secure (Mills' job depends on it!), but the average day-to-day person at HomeWorks was not affected by Steve Wilson's efforts. Not so with Rebecca Morse's team of business analysts. The most dramatic and visible example of IS's commitment to alignment that the average HomeWorks person saw would result from the work of BAP's business requirements and analysis group. I'm not exaggerating when I say that the ultimate success of the whole BAP initiative rested on this team. Morse's eight business analysts are truly the unsung heroes of BAP. And although they may be more visible simply because they represent the largest group under BAP, they also interact with practically everyone at HomeWorks — from the upper-level executives down to the operational people who really run the place.
In staffing the business analyst team, Mills and I were particularly mindful that to a great extent, these people would be on the front lines representing IS to the rest of the organization. Therefore, training and communication were our two main concerns in getting the group up and running quickly and effectively. "Up to now, there's been virtually no process for gathering and validating requirements and no effort to substantiate the business-side benefits when a new project is launched," said Mills in the group's first briefing. "It's your job to change that paradigm. The average user here wants more than anything to know that their needs are accurately communicated to the people responsible for building and installing new applications." Mills went on to explain that the business analysts would serve as the communications bridge between IS and the business and that he expected the analysts to foster a dynamic flow of information between the two groups. The analysts were charged with systematically gathering requirements for the IS development folks while communicating questions from the tech people back to the business side. Big Group = Big ChallengesSimply getting this group off the ground is a huge challenge. We've intentionally put people with a wide range of IT and business backgrounds and experiences together to form this team. Few if any of them have done formal requirements gathering before. Sure, some of them have been involved with requirements gathering sessions, and all of them were chosen because of their analytic minds, but most have never been involved in an effort quite this formal and visible before. My goal in forming the business analyst group was to create a heterogeneous team comprising business and technical people. This was a key objective of Mills when he asked us to form this part of BAP. "There's not enough of a business focus in IS," said Mills in one of our early status meetings. "Too many people want to build a bright and shiny technical thing but don't understand or even care about the business benefit that that thing provides." The business analysts group needed to represent a cross-section of HomeWorks business and couldn't be dominated by any one group or part of the business. Half the team was IS systems analysts who wanted to get away from coding and do more work on the business side. The other half was made up of people representing the business units who, once the opportunity was explained to them, were anxious to participate in helping bridge the gap between IS and the business here at HomeWorks. To start, I'm working closely with Rebecca Morse to train these people on how to gather business requirements. We're developing business requirements templates and showing the team how to ask the right questions, how to effectively run a requirements gathering session, how to write our findings in a way that the IS folks will understand, and how to format a finished requirements document. For the first six months, Morse and I are actively involved in all requirements gathering sessions to make sure the team is trained properly and covering all the bases.
|
 |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
| |
| |||||||||||||||||||||||||||||||
