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.
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.
Post A Comment:
0 comments so far,add yours