The focus of this article is managing requirements, one
of the most challenging areas of application development,
and our feature is an interview with a true guru of requirements
management, Rob Beckmann, who advises our clients on best
practices in this area and explains why it takes more than
a series of client meetings to design useful applications.
Interview
with Rob Beckmann,
Principal, Requirements Management Practice
Read
Bio
By James Houston
Q: Rob,
we are all aware how important requirements are in application
development. Why then, are almost half of project failures
still requirements-based?
A: That's a good question. For me it's crucial
to think in terms of both requirements gathering and requirements
management. That is, you need good people and techniques
to capture requirements as accurately as possible, and an
on-going process which recognizes that requirements will
change over the life of the project. It sounds simple, but
the plain truth is that most organizations don't have the
experience or the resources to do that as effectively as
they'd like to and I think that is why we see such a high
failure rate attributed to requirements. Everything is
driven by requirements, and if they are incomplete or not
managed
well, the application will fail.
Q: There
are a lot of well-established techniques for requirements
gathering - what works best in your experience?
A: This may surprise people, but simply
meeting with the client isn't enough. Talking to the various
stakeholders, the user groups, stakeholder representatives,
business analysts, and so on is essential, but it isn't going
to give you a complete picture. There has to be secondary
research. Caro will typically look at a number of other sources
as part of our requirements gathering process: prior attempts
to model the business processes, legacy data stores and database
schemas, prior project artifacts, legislative documents,
and so on, to help us better understand the requirements.
This background information gives us the insights to ask
the right questions when we do talk to various project stakeholders.
It's all about knowing where to look and it takes an experienced
team to bring that thoroughness to the requirements gathering
process. It is worth the effort though - as we all know,
it's a lot better to understand your requirements as early
as possible than to have them turn up later on in the development
cycle.
Q. Is poor requirements
gathering the biggest contributor to requirements-based failure?
A: The up front work makes a big difference
to the success or failure of the project but it's equally
important that you manage the requirements throughout the
development cycle. Even when you have gathered what you
feel is a thorough set of requirements and have tested
them for
completeness, you have to expect that the requirements
will change. People make mistakes in expressing and understanding
requirements, and will rarely (if ever!) know all their
requirements
up front. Additionally, over a long development cycle,
you could be looking at requirements changes as a result
of changes
in business objectives, competitive pressures or from legislative
influences. The key is to anticipate that change will occur,
and to manage change throughout the development process,
establishing priorities for how you handle them during
the build.
Q. What
in your opinion are the biggest challenges in requirements
management?
A: One of them is a people thing. For successful requirements
management, the various players need to be involved in
ways they might not have been traditionally, and you need
a team
that can help make that happen. For example, representatives
of the business side need to be involved throughout the
project to ensure requirements are faithfully carried through
to
implementation, and to participate in the re-prioritization
and scope setting of project deliverables. Under traditional
approaches the business sponsors were led to believe they
could throw their requirements over a fence and come back
in six months to a successful working system. It just doesn't
work that way. Ideally, you need to show the business representatives
what is happening early on and frequently by demonstrating
working prototypes of the system. By illustrating tangible
results early in the project there is an opportunity to
elicit early and continuous feedback to ensure the project
is on
the right path.
Q. So you're
saying that requirements management is best accomplished
through an iterative development approach?
A: Absolutely, yes. We find that the traditional "waterfall" method
and mindset just doesn't provide the flexibility and responsiveness
needed for good requirements management. We've had great
success managing application development with the iterative
approach of the Rational Unified Process (RUP) methodology.
The value of using RUP is that it requires communication
across the development lifecycle. You involve the business
during each iteration, and the focus is on early feedback
from the stakeholders so you know you are hitting the mark.
So you learn from the development and use of the system
as you go while ensuring the continuity of development.
Q. Given
that requirements gathering is the downfall of so many projects,
what can an organization do about it?
A: Requirements management will always be a challenge for
application developers. Regardless of the development methodology
used, developers need to pay attention to requirements
throughout. In part, that requires a different mindset
and also a different
level of involvement between the various team members and
stakeholders. Caro's approach to managing application development
involves a lot of education of the players involved, especially
where they are acting in non-traditional roles or taking
a non-traditional approach. From the requirements gathering
standpoint, we also offer courses on requirements management
best practices that help you get the most out of techniques
like use cases. In addition to education, we believe that
the introduction and execution of any process will be far
more successful when lead by highly skilled practitioners.
To start on the road to improved return on your software
investments, start with an intense focus on requirements
management. Investing in good requirements management is
the most reliable investment a business can make.