The foundation of any project, strategic sourcing or otherwise, is the requirements. They must be known in order to finish the project and, in turn, solve the problem the project was trying to address. According to the IIBA Business Analysis Body of Knowledge®, a requirement is a condition or capability needed by a stakeholder to solve a problem or achieve an objective. So it can be reasoned that without clear identification of requirements, a problem is less likely to be solved, if at all. From a strategic sourcing perspective, identifying requirements is especially important because a third party will often need to be involved to provide a solution. Proper requirements must be gathered to identify the ideal solution to the problem. The gathering of requirements is a process that oscillates between research and asking the right questions. So, the issue at hand is how do we go about finding what the requirements are?
The first and most visible requirement is that there is a problem. Problems can appear in various forms, for example:
- Our current infrastructure is becoming too expensive to maintain
- Are the prices we are paying competitive?
- Do we have the resources or subject matter expertise necessary to accomplish this initiative?b
- We need to create a mobile application to market our services/products, etc.
Next the validity of the problem must be addressed. Is the problem valid? Will addressing this problem help the business overall or will it only address the small individual need/want of a stakeholder? This is a critical juncture for a project, because if the project only addresses a small need and does not add value to an organization or department it may be best to forgo the project all together, to avoid tying up resources that could assist with larger, more business critical projects.
As an aside, if a project is too small to be a worthwhile endeavor, it may be beneficial to search within the organization for similar sized needs and combine them. From an organizational perspective, this allows needs across multiple departments to be fulfilled. From a strategic sourcing perspective, the prospect of having a potential supplier be part of multiple facets within an organization can create powerful negotiation leverage and may help organizations reduce costs.
Once the validity of the problem has been established; the project team must gather the predefined requirements. They are requirements that have been identified by the stakeholders as necessary to solve their problem. They can be as simple as “We need Microsoft Windows Azure for our European offices” or the more cryptic “We need a cloud computing platform and infrastructure.” Other requirements already identified by stakeholders are usually quantitative in nature. The quantitative requirements are relatively easy to identify and analyze. In IT, this can be something as simple as the number of licenses required and/or amount of storage capacity desired, etc. All known predefined and quantitative requirements must be collected and validated at the onset of the project, as they provide crucial details that will influence the rest of the requirements gathering phase.
The project team must combine its general knowledge of the problem at hand and their organization’s business processes, with the previously gathered requirements, to conduct appropriate research. All requirements gathering phases begin with research. Research can be conducted in a variety of ways, such as, reviewing stakeholder provided documents, similar past projects, articles by research companies such as Gartner, Forrester, IDC Research, etc. or good old Google search.
Please review the following article on how to maximize your Google search results.
The research phase is meant to give the project team additional insight into various aspects surrounding the project that a stakeholder may not have known or communicated. Once this phase is complete, the team must take their new found knowledge and use it as a guide to ask appropriate questions of the stakeholders. It is ideal to start asking broad questions, using the answers provided to chisel down to get to the heart of the requirements. Typical questions include:
- What will you use the solution for?
- How did you come up with the (insert quantitative requirement) need?
- Do you prefer an open source or proprietary software solution? Why?
New questions will bring new insights, which lead to new avenues of research, which leads to further questions. This recursive process is continued until the requirements are fully understood and articulated or how long the project timeline permits.
The gathering of requirements is a process that fluctuates between research and asking the right questions. By this stage the typical questions, such as what is the problem, why it is important, who are the stakeholders, and quantitative needs have been answered. The answers provide direction regarding where further research should be targeted; therefore, they form the building block of the requirements gathering process, which ultimately creates the foundation of a proper sourcing project.
Michelangelo once said “The sculptor's hand can only break the spell to free the figures slumbering in the stone.” In business analysis terms this quote means, the requirements are there, it is up to the project team to identify them.
*Image courtesy of www.msktc.org*