Determining Your BPM Software Requirements

"A software package implemented using phantom business requirements, or those born of the IT developers' imagination, will most likely generate discord, inefficiencies, and occasional outright resentment of the tool."

-unknown author

All Process Management software products are not created equal. So determining which one is right for your company takes more than a wish and a prayer. Now we’re not experts in the Procurement process, but the typical vendor RFP (Requests for Proposal) and software implementation requirements we've seen are so vague they could easily wind up producing unintended results as depicted in Figure 1.

FIGURE 1 – The Result of Good Intentions vs. Good Requirements

If Figure 1 looks familiar, you are not alone. According to the Standish Group, a market research and advisory firm specializing in strategic software, incomplete business requirements are one of the top-three causes of unsuccessful IT project implementation. So how do we build better business requirements to ensure that what we get is really what we wanted?

GUIDELINES FOR BUILDING QUALITY BUSINESS REQUIREMENTS

Understand the Purpose. Technically speaking, a requirement is a condition or capability to which the system must conform. However, building requirements is not an exercise in tedium intended to make your project team break out in a cold sweat. They are a way of clarifying the project vision and scope. They make it tangible. As you develop requirements, you confront issues and make decisions about what the project outcome will be. You are, in fact, building the blueprint that will guide the design.

Business requirements are called "business" requirements for a reason. They should reflect the perspective of the business- what the business needs the solution to do or provide. They are not the intended to indicate how the solution will be implemented or the technology that should be used.

Apply Structure to Each Requirement. To build good requirements, there are some basic guidelines you can follow to ensure they will be interpreted as you intended. Every requirement should be:

Ensure You've Covered All the Bases. For any software implementation, you should document requirements related to the functions it must perform and the performance required. But we also recommend capturing requirements related to people and the processes affected by the implementation.

Functional Requirements describe what the system must be able to do in order to achieve the business goals. Functional requirements typically include:

Non-Functional Requirements are qualities or attributes that the system must have in addition to the functions it performs. Common types of non-functional requirements include:

People and Process Requirements describe what the people or process must be able to do and are often more implementation-oriented. Common types of people and process requirements include:

Capture Supporting Information. No set of requirements is complete without an understanding of the constraints, assumptions and dependencies upon which they are based. Document these items to paint a complete and comprehensive picture of your software package requirements.

CONCLUSION

Developing requirements is a critical and necessary part of selecting the right Process Management software package. Their purpose is to clarify the project vision and scope. They make it tangible by building the blueprint that will guide the design. So follow the suggested guidelines to document your functional, non-functional, people and process requirements. Then augment them with supporting assumptions, constraints and dependencies to ensure you effectively capture and communicate comprehensive, quality business requirements.

REFERENCES

Alexander, C., Silverstein, M., Angel, S., Ishikawa, S., Abrams, D. The Oregon Experiment. New York: Oxford University Press. 1975, p. 44.

"The CHAOS Report", The Standish Group International, Inc. 1995.

Means, J. and Adams, T. Facilitating the Project Lifecycle: Skills and Tools to Accelerate Progress for Project Managers, Facilitators, and Six Sigma Project Teams. San Francisco: Jossey-Bass, 2005.

For more information on good requirements practices, check out Karl Wieger’s Process Impact website at www.processimpact.com/pubs.shtml#requirements

Ms. Adams is the Managing Partner of Chaosity LLC and specializes in Project Facilitation and Business Process Analysis. As a certified facilitator and quality manager, Ms. Adams works with project teams in a variety of industries to elicit, capture and translate their shared knowledge about processes, products and services into project and design deliverables.

They are co-authors of the book “Facilitating the Project Lifecycle: Skills & Tools to Accelerate Progress for Project Managers, Facilitators and Six Sigma Project Teams” and regular speakers at International Facilitator, Quality, Business Process and Project Management Conferences.

Bookmark / Share This

Bookmark or share this with others.