We are committed to teach and provide you any tools addressing Information Management using a holistic approach which combines people, process and technology to focus in unison and brings you true success.

Business and Systems Requirements:

What are they and why should I care?

By Bob Larrivee (14th November 2008)

In order to identify our business and systems requirements, regardless of the technology segment, one must first understand the differences and yes there are differences. Typically we think of business and systems requirements as technology. It is not our fault, as we have been conditioned this way. Much like the conditioned responses of Pavlov’s Dog to food, we have been conditioned to think in terms of technology when referencing business requirements and solutions. 

How many times has someone asked of you, “How are you currently managing email?” and your response is, “We are planning to buy XYZ technology?” The answer question was not specifically about what technology you prefer, but the answer is. The fact is technology is merely a piece of the overall approach and solution. Policy, process and people are just as important and have just as much impact on what we should do in relation to our business issues. Thus, the need for us to distinguish and define our business requirements from system requirements is essential to our approach in procuring and implementing the best possible solution. 

Simply put, business requirements are the strategic goals and objectives, the legal and organizational framework by which we function and the people and processes in place to make it all work. We must process and secure an average of 1,000 new account applications daily and reach the projected growth rate of 35% year over year for the next 5 years while adhering to our industry’s regulatory guidelines. Systems requirement then, are the features and functions that tools and technologies used by the business unit must provide in order to support the processes and activities of the business unit combined with the non-functional and domain aspects of our environment and solutions. The system must be able to capture information from any source using a simple and intuitive user interface. Simple right? Well, maybe. In order to be effective in developing business and systems requirements we must:

·         Understand the strategic goals and tactical efforts of the business unit

·         Develop criteria for a solution based upon those needs and goals

·         Identify features or attributes that have a value for the business unit and user

This is extremely important if we are to ensure that our selection of technology is appropriate to the need, implementation is tuned to the audience and establishment of our environment yields the benefits we hope to attain. How is it possible to get the highest return and value for our time, effort and costs if we do not first know and understand the needs and requirements of our organization? This would be called a serendipitous approach which seldom if ever works. We need to be calculating and focused in our efforts and that is where business and systems requirements come in to play. Now, let’s keep this in mind and explore further how this approach works.

Understand the strategic goals and tactical efforts of the business unit

If we believe that business and systems requirements capture and articulate the needs of a business unit and the stakeholders within that business unit, we must first try to understand the goals of the business unit and identify the tactical efforts on the part of the stakeholders in order to achieve those goals. While this might sound like a simple step it is actually one of the most misunderstood and underestimated in the business and systems requirements process. This is true mainly due to the fact that not everyone will know or understand the goals and tasks.

Ask anyone in a business unit what the strategic goals or visions are for that business unit and you will likely get a variety of answers from I do not know or to make money, all the way to what might appear to be a real vision statement. When you ask how one performs their daily tasks to achieve these goals there may also be a myriad of possible answers from the workers and a differing set from management. In fact you may find there are actual documented processes for the worker to follow but the question is do they actually follow those steps or have they been modified over time and the changes never documented. In this case, management might feel they know the processes and tasks performed when in reality what they refer to is “the book” and not the reality.

Here is a case in point. I once had the opportunity to work with a small business anticipating the purchase and implementation of an ECM solution. When I asked the question of strategic vision, the owner had a stated vision of growth and service levels while the employees referenced a vision of maintaining sales and staying in business. When I asked the employees how they did their jobs and what they did as a process, many indicated large amounts of time spent searching for files and relevant information while the owner indicated they were an example of efficiency and precision. Several weeks later, while enjoying a cup of coffee in the break room, the owner witnessed reality and was overwhelmed by the amount of wasted time and effort chasing information. Likewise, he began to ask this simple question, “What is the purpose of our business and vision for the future?” In many cases the answer was to sell product and make money so we all have jobs. They did not know his vision was to become the largest, most widely recognized and trusted representative agency in their region.  His vision was not theirs and the way they worked was not known to him. There was in fact a huge disconnect between them.

This is a small example of the typical and not unusual disconnect I have seen within business organizations. Management and the workforce are not in sync with each other regarding strategic direction and tactical operations.  In order for the connections to be made we must first open the lines of communication throughout the organization and take time to share information and perceptions in a way that we can clarify, refine and agree upon our realities. As we go through this process we must also capture and document our findings to establish the core vision and goals, identify a set of prioritized stakeholder needs to achieve those goals and do this is such a way that it aligns to the focus of the strategic objectives and is made clear and understood by the entire organization.

Develop criteria for a solution based upon those needs and goals

Assuming we are successful in the above mentioned effort of communication and documenting our realities, we must now develop criteria for a solution that meets those needs and empowers us to achieve our goals. Many think this is the point we spell out a vendor and product set. Wrong. This is where we spell out what our organization needs to perform. This is where sort out and document criteria that will drive the purchase of our solution; real needs from stated needs. Here we prioritize the needs into categories like those things we feel are mandatory, those we feel are highly desirable and then desirable if we can get them.

We should consider looking at industry standards as part of this exercise, and aligning those things in the industry standards to our needs and strategic goals. (The latter being the most important.) Standards that may come into play could be ISO 15480, MoReq2 and Dublin Core to help us formulate our corporate standards in dealing with information, records management and metadata. Criteria of this type could be presented in a matrix format as shown below for ease of presentment and understanding.

This approach allows us to simplify the criteria and segment them categorically in ways that are now easily understood and identified as not simply someone’s dream or wish. When we approach criteria development in this way, the stakeholders can easily relate to what is being requested, it shows there is thought and effort on the compliance front when we choose industry accepted standards and this becomes the foundation for our procurement process in vetting a solution and solution partner.

In addition, this method also helps us ensure alignment with our strategic goals by providing a means to review and tie back to what we are focused on accomplishing with this project. Along with this, we must also consider the solution itself and some of the functionality we feel is appropriate from a value perspective, for our organization.

Identify features or attributes that have a value for the business unit and user

We know the needs and goals of our organization, we have developed baseline criteria as a result of applying standards but we can also see a need to identify those features or attributes of a solution that would provide value to our organization. This is an area where we look at technology and assess what might make sense for us and why it makes sense. For example, if we want to automate the processing of our delivery services paperwork in order to streamline the process of invoicing and attain better cash flow, we might incorporate bar code recognition as a feature we desire. Perhaps we are aware of others in our industry leveraging technology in this way so we feel it s something we would also use and gain value.

This now gets back to our conversation in the previous section and the use of prioritizing those features we feel are mandatory, highly desirable and desirable.  This too, can be presented in a matrix format and when used in an RFP, provide feedback to us that can then be compared across the respondents. Here is an example of how this might look.

As you can see, this method identifies a feature and its importance or value to the organization while at the same time serving as a screen as part of the procurement process where respondents can indicate whether they can provide this feature and how it will be provided. In many cases I have seen, there is a description of the feature along with the priority for an organization and the response area for vendors and service providers to indicate yes or no. Where many fall short is in asking how this feature is actually provided. As a respondent, I could answer that yes I can provide these features but unless you ask the question of how, I will leave it at that and you are left to learn specifics at a later point and possibly additional costs. This method also gives the respondent a chance to standout as well in presenting their full capabilities of delivering a quality, feature rich product and professional services leveraging their experience and expertise that could help you in other ways for adding functionality or even interoperability throughout your organization.

Bottom Line

 The bottom line in all of this is that business and systems requirements are different yet at the same time tied together. One drives the other. Business and systems requirements are not something to take lightly nor are the effort to document them a task that should be trivialized. This is a project unto itself and one that involves a cross section of the business organization from management to worker and IT. This is a team sport.

We can and do create what we believe to be business and systems requirements, reacting much like Pavlov’s Dog when we hear the term and think technology. We must break our conditioning and think anew. We must look at our organizational worlds from many perspectives, understand and document those perspectives and attempt to bring focus toward a strategic end. Our goals should be aligned and our efforts tuned to meet those goals. Many businesses fail to realize the true benefit of their projects due to a lack of focus and understanding. This can be serious and is easily addressed through taking the time and effort in developing solid and realistic business and systems requirements that align to our strategic goals and address our tactical requirements.

Reprint from AIIM eDoc Magazine written by Bob Larrivee, Director of AIIM Global Education Services – Americas

Bob Larrivee is Director of Education at AIIM International, the world leader in providing education and training in ECM, ERM, BPM, IOA, EMM, E2.0 and PDF/A and has over 25 years experience in content and process management with a focus on advanced technology application.