Just as the eyes of Michelangelo's David are fixated on his foe Goliath, an expert business analyst begins the process of business analysis fixated on the task at hand. This is how TDK senior business analyst Brad Wesselmann starts each project: by “finding the eye of David”. Focusing first and foremost on understanding a business, its operations, processes and goals, Brad is able to “build business requirements from scratch” which enable crafting IT solutions that deliver bottom line results.

To Brad, a requirements document begins as an “uncarved block”. He approaches each project with a blank slate, his open mindedness facilitating a clear understanding of the business problem and how technology can be used to solve it. He understands that “every company is different”. Each has unique people, processes and objectives. Yet in many ways “every company is the same”, with problems like “communication barriers to technology, lack of process structure, very limited system documentation, and obsolete functionality”. In this way Brad is able to apply his years of experience in business analysis without making assumptions which might obscure a more ideal IT solution.

Breaking out the “hammer and chisel”, Brad begins determining the needs of key stakeholders and defining the requirements based on the analysis of those needs. “Application review, functionality testing, field assessment, business process analysis, dependency modeling and user interviews” are some of the tools he uses to “carve the block”. He is careful to understand as much as he possibly can about a business and its processes before he begins user interviews, in order to use that time most efficiently.

Once the requirements begin to take form it’s imperative to “polish and refine” them. Brad “reviews and compares business processes to application processes for gaps, looks for ways to eliminate or assimilate underutilized processes and fields, and seeks to focus the business on its critical process path”. This polishing and refinement allows Brad to develop effective, finely tuned requirements documents which include “process maps, field requirements, business rules and proposed screen shots”.

When presenting business requirements to the stakeholders Brad understands that a different approach is required for business managers and engineers. When presenting to business managers he focuses on high level analysis but provides all documentation. He covers the rules of the document, the key areas in detail, the process problem areas, and the proposed screen shots.

When presenting to the engineers he emphasizes that what he’s presenting “are prototype models”. With a goal of keeping the room focused initially on grasping the concept as opposed to letting the discussion diverge into tangential technical details, he “works from the screen shots” and informs them that “the field specifics are in the documentation”. He looks for ways to “leverage their expertise and promote buy-in to the concepts”. He understands when to sit back and let the experts go to work doing what they do best, only interjecting when “they finally put the whiteboard marker down”, in order to assess and validate a proposed problem solution in terms of the requirements.

After his presentation Brad was asked how often he had to educate clients, not only on what exactly he would be doing for them, but what business analysis was in general. His reply was “almost every day”. Thus it is not surprising that he explained in his closing remarks how one of the first things businesses tend to cut when they are in a crunch is business analysis, despite his quite salient point that “a business solution without business analysis is like navigation without a compass”.

Brad Wesselmann, Business Analyst

IT Pros who speak your language: “Business”