After
working with technology for last 12 years I have sensed that most crucial area
in project life cycle is not give due focus required to ensure success at end. REQUIREMENTS also referred with
different names like request, need, end state etc. With no prior knowledge anyone
can predict that unclear and vague requirement is a recipe for failure.
Requirements gathering in itself; is a very specialized area which requires domain
knowledge and writing skills. Based on my experience and discussions with
various friends and colleagues I have tried to put together what I think should
be the right approach towards providing technology requirements.
To start
with it is important to understand what is Technology Requirement? Everybody
seems to have a different interpretation and expectation from Technology
Requirement. One point of view is that Technology Requirement is provided to technology
teams to develop a solution which will enhance the product capabilities to meet
the business need. Technology requirement needs to be detailed and documented
in such a way that, each product team should be able to use it to produce a
detailed design and complete build to support it.
Complexity
is not in producing this requirement document, intricacy lies in the journey
that requirements travel from inception to technology requirement. Let us start
by looking at one of the myths around it. “Technology Requirement is the
inception of requirement stage”. However fact is that it is the end product not
the start.
Inception
of the requirement is a “Business Need”.
This need or desire is transformed and translated through different stages into
final product “Technology Requirement”.
The trick lies in getting the right driver and correct direction for this journey
to be successful.
Right Driver
Getting
right driver or commonly known to most of us as “Business Analyst” plays a very crucial role in this journey. He is
the soul of the requirement document, as it is not what business wants that is
documented in technology requirement it is what business analyst interprets
that becomes the requirement document. One of the common mistakes that most of
the organization perform is to recruit technology product expert as a business
analyst with the assumption that good knowledge of product will crystalize the requirements
in a much better way.
However my
experience has been different, having a technology product looking at business
need is like showing an egg to a chef. Like chef will only thing about roasted
chicken by looking at egg, similarly a technologist will directly think about
how to configure the product based on business need. There could be number of
reason why this is not a good way of documenting requirements firstly it engulfs
the business need with a half-baked solution, secondly this technology product
expert (a.k.a business analyst) probably does not know that product might have
developed and customized after he took out his technology shoes.
This does
not mean that a technology expert cannot be a good business analysts, I have
also seen many technologist carving beautiful requirement documents. And also
as we will see later in the document we do need these technology experts to write
technology requirements document. This probably is bit confusing as at one
point I mentioned we should not have technology expert looking at business
needs and now I am saying we need technology expert writing technology
requirements. To solve this mystery we need to review the next section which
explains stages between business need and technology requirements.
Requirement Journey
Given below
is a simple map for going from business need to technology requirement.
As shown
above between we have 2 stages on journey from business need to technology
requirement “Business Requirement”
and “Concept Solution”. To
understand what each of these mean let us take a simple example:
Business need– I want to go to office from home
Business requirement–
· I want to go to office in shortest
possible time and should not cost me more than 10 SGD.
· It will be good if I can pick up a
coffee from Starbucks.
· Though not a must but I will prefer
using a public transport
Concept Solution–
· Considering the distance and traffic
congestion between my house and office, I should take a train to the nearest
station
· Once I reach office station I can
walk to office and pick up coffee from Starbucks at station
Technology Requirement -
Product – Taxi
· Need a taxi pick up at 8 am from
home
Product – Train
· Train should travel from home
station in north direction
· Train should stop at office station
Product – Starbucks
· Starbucks at office station should
provide cafe latte
Point I
wanted to make using above example is not that I am an addict of Starbucks
coffee (that anyway happens to be a fact),
but what I am alluding to is that we need a business requirement and a concept
solution before technology requirements.
System
Agnostic Requirements
Unlike
Technology Requirements which are product specific business requirements are
system agnostic. What that means is that when writing business requirements the
analyst should not be thinking about which product will support respective
requirement, instead what should be documented in business requirement is a
story around business need with business need as a title of the story.
Not
documenting business requirements might not produce a product that fulfil the
business need also directly jumping to technology requirement might not be the
most efficient and scalable solution to meet the goal.
Extending
on our home to office need. If we directly produce technology requirement based
on business need, and assuming our business analyst was an ex-expert on our
technology product Taxi. I can bet
our technology requirement document will look like “Take a taxi to office and
stop and Starbuck on the highway”.
Writing
system agnostic requirements is not simple but also not impossible task.
Expanding on business needs requires us to think from business point of view
and a common approach towards that is to look at every business need in terms
of customer value chain or customer journey.
There can
be different levels of looking at customer value chain and selecting the one
which meets the business need is not difficult. An example for this is if
business need is to introduce a new product then business requirement should
consider the complete value chain and processes within each.
However if
the business need is about changing the application processing process then
value change to be considered will be more specific to customer acquisition, an
example give below.
In business
requirement stress should always to document and validate with business on what
is required and not how it should be achieved.
Concept Solution
Concept
solution or high level solution or end to end solution or birds view solution
etc are all referring to same or similar thing. In the ever growing complex
world of technology I have not heard of one product which can solve or support
every requirement. So what we have is a mesh of products performing a
specialized function in customer value chain. All these products are dedicated
to complete one or more function but not all functions.
Concept
solution is what takes the business requirements and starts mapping each
requirement to individual products to ensure right product are used for right
function. *It is not just ensuring right product performs right function, but many
other parameters goes into decision for complete this requirement mapping.
Technology Requirement
Now going
back to technology requirements the end product and juice of this paper. Once
concept solution maps business requirement to various products, then what
business analysts (with an knowledge of the product) should do is take specific
business requirements and produce a technology requirement specific to the
product and convert what is expected from the product in a language that
technology product team can understand. It is also important to note that
technology requirements are not for business to review as for them what is
required is already part of business requirements. This technology requirement
is more for the individual product teams to understand what is expected from their
product and produce design etc.
Without
doing step 2 and 3 and taking short cuts will in most cases give you a roasted
chicken when need was to have a fried chicken.
This brings
forth another important consideration. With so much focus on “time to market”
and new development methodologies like AGILE being used for development wont
these additional steps slow down the process. Short answer to this difficult
question is “NO”. Reason being “Time to Market” does not mean time required to
complete build but time required to produce an end product that meets business
needs. Skipping these steps might end with more rework more testing and
integration issues, at the end will not save time by taking short cut.
AGILE Requirement or Compartmentalized Requirement
Another
pertinent item to the topic is being AGILE in documenting requirements. I feel
that it is not only project executed in AGILE methodology that should follow
the concept of user stories and features, but also every other project.
Looking at
requirements with a lens of customer value chain help to break the business
need into vertical requirements i.e. by each area in value chain and what
feature based lens help to do is look at the requirement horizontally. This
serves us 2 purposes, firstly it ensure that all the requirements are not left hanging
in a value chain but also are tied up together avoiding any loose ends, and
secondly it helps to compartmentalize the requirements into features which probably
can be used independently.
Compartmentalized
requirements is obviously an pre-requisite to AGILE but can be a good starting point
to organizations which want to follow a waterfall model but still want to
deliver business value in shorter time to market.
Conclusion
Whatever is
discussed in this paper probably is not a EUREKA type realization for all of
us, but these are some small areas which are overlooked and can result in major
rework or gaps in meeting business expectations.
System Agnostic Requirement and Compartmentalized Requirements are just two ways which can help in
realizing the full business value by ensuring business needs are translated
correctly to technology requirements.
Author – Saket Mathur
(Vice President @ Barclays)
Dated 29.10.14
No comments:
Post a Comment