'Measure twice, cut once' not just for carpenters

Everyone has heard the adage: "Measure twice, cut once."  Ironically, not everyone follows this simple principle when it comes to Information Technology projects. 

In the usual stages of performing a software development project (discover > design > develop > deploy), the preponderance of time is often allocated to coding and development.  However, the most important step in assuring a successful software project is gathering and documenting the business requirements from the system users that define the end result of the project.

StoneHenge has a much higher average percentage of time associated with Business Requirements Gathering. This additional investment in time reduces the percentage of time needed to code the project.  Additionally, the extra time allocated to listening to user to create detailed business requirements minimizes scope creep and misunderstandings, as the project is being developed and delivered.

Key steps in requirements gathering

To insure the successful delivery of rock solid business requirements, several issues should be addressed in preparing for documentation gathering:

• The analyst - The first step should be obvious but is often taken for granted.  Specific care should be placed on the task of choosing a Business System Analyst.  Collecting requirements demands a specialized skill set, coupled with a dynamic personality.  Ideally a BSA will be a hybrid of great communication skills and solid technology acumen.  A vibrant and attentive BSA will be able to draw out and define the business requirements from any Subject Matter Expert. 
• Interviewing - Asking basic who, what, where, why questions will aid in fleshing out business requirements.  For many SMEs, the ordeal of cataloging the requirements of a need or task is alien.  Treat them with great interest and get them to tell you about their desired end result.  Look over their shoulder as they perform tasks and ask them how things could be easier.  Repeating back the answers and workflows to the person you are interviewing insures there are no misunderstandings.
• Vocabulary - Always use the SME's language.  By learning the system names, acronyms, product monikers and jargon that are used daily by the SME, you make it easier for them to describe their needs.  Utilizing their language also helps to define a glossary of terms that System Architects and Software Coders will use during the architecture design portion of the project.  
• Visualization - The use of visuals to illustrate workflows, process tables, taxonomy definitions and usability design is critical.  Imagery, as a communication tool, will aid in assuring there is clear understanding of what is being documented as part of the requirements specification -- both for the SME and for the developers who will work from the requirements specification.
• Documentation - A standardized template for gathering documentation will assist in gathering all of the information that is needed.  Working from a template reminds the Business Systems Analyst what questions to ask and in what order to present the documentation.  Also, a regular presentation style guide of documentation is beneficial for a coding staff as they move from project to project.  If the documentation is presented in the same method each time (especially if they work with multiple BSAs), coders will become accustomed to working from a style and will be able to assimilate the requirements more quickly and accurately.

Bridging the gap between IT and business

Why is this so important? In a typical corporation, a gap exists between business units and the company's information technology unit. Business people tend to think of IT in terms of sales support, or inventory control, or office productivity -- "how useful is IT to  me." IT technologist tend to think in terms of plattforms, environments, infrastructure, systems architecture -- "how well is IT built."

At StoneHenge Partners, our Business Analysis consultants bridge the gap between the two sides, speaking the language of business to stakeholders and the language of technology to technologists, and in the process we find technology solutions to business problems. That's our company's mission statement in a nutshell.

A Business Analyst (BA) is a person who practices the discipline of business analysis. A business analysis consultant is responsible for analyzing the business needs of their clients to help identify business problems and propose technology solutions. Within the systems development life cycle domain, the business analyst typically performs a liaison function between the business side of an enterprise and the providers of services to the enterprise.

A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.

StoneHenge Partners has a core team of experienced Business Analysts. On a typical engagement, we consult with the business units to better define their business problem, then consult with the technology unit to define a technology solution, then wrap the whole problem/solution in a package that can be delivered as a report, as a knowledge base, or whatever best fits the organization; plus, we can stay on through the life of the project to make sure the technology solution keeps on course to solve the business problem.

StoneHenge has a proven methodology of collecting and documenting great business requirements.  We can provide our Business Analytics methodology as a service and as a training offering.  If you'd like to hear more about getting your project started out right with rock solid business requirements, give us a call.