PROJECT MANAGEMENT KNOWLEDGE SERIES

10 Ways Requirements Can Sabotage Your Projects Right From the Start

10 Ways Requirements Can Sabotage

Your Projects Right From the Start
The future success of Project Managers (PM) and the Project Management Office (PMO)s
Most PMs and PMOs have
comes down to one thing—identifying and eradicating the causes of project failure
right at the source. not identified the 10 ways
that requirements cause
This paper shines a spotlight on a major root cause of project failure in every their projects to fail
organization—requirements. And while the first reaction might be to place blame on the
requirements author, the Business Analyst, this is incorrect. The REAL root causes run
much deeper than that.

Take a look at the real reasons why requirements-related issues sabotage your
organization’s key projects before they even get off the ground…

1. Dramatic project overruns stem from requirements

When things don’t go right in the requirements stage, the impact often shows up much
later in development, when the cost to make corrections are staggering. Consider these
numbers: one in six projects have budget overruns of up to 197%, and the cost to fix
requirements issues in production is 200 times that of fixing the issue in early parts of
the life cycle.

The requirements efforts in most organizations are fragmented, costly, and largely un-
optimized. Your CIO may not know exactly where all the cracks and holes are but they
expect the PMs and PMO to fix the problem.1
One in six projects have budget
overruns of up to 197%2
2. ‘Over-build’ expands project scope unnecessarily,
and can always be traced back to requirements
On average, almost half of all delivered features are never used. Half! What would it
mean to your project budget and timelines if the number of requirements were cut in
half on every project?
Whenever a feature is built unnecessarily, it’s a sure sign that something has gone
wrong in the requirements stage, since the requirements define what is supposed to
be delivered. Any confusion, unresolved debates, unanswered questions, or missing
information in the requirements stage opens the door to scope creep and a flood of
unnecessary features work their way into your projects.

78% of IT professionals believe

Business is ‘usually’ or ‘always’ out of
synch with project requirements3

© 2012 Blueprint Software Systems Inc. 1

 PROJECT MANAGEMENT KNOWLEDGE SERIES
10 Ways Requirements Can Sabotage Your Projects Right From the Start

3. Approaching requirements in the same old way

won’t work in agile environments
While everyone is racing toward agile in the enterprise, there seems to be very little
agreement on what constitutes “good requirements” in agile environments. It’s an
elephant in the room, which puts Project Managers and the PMO in a predicament.
There’s pressure to explore, embrace, and demonstrate the benefits of agile
development, yet exactly how agile will work in a practical sense within the enterprise
isn’t yet clear.
The big, thick requirements document simply can’t scale in an agile environment. At
the same time, it’s also clear that a simple user story alone isn’t enough. As enterprises
struggle to adopt agile practices, what’s needed is a richer, more expressive, more
comprehensive requirements process.
Requirements remains the elephant
in the room when it comes to agile
development
4. Continuing trends toward outsourced and physically dispersed
team members strains the ability to produce quality requirements
Good requirements depend upon quality communication and collaboration. However
the trend toward outsourced team members introduces the following challenges to the
requirement phase:
· Contractors generally do not have a long-term focus within the company,
· Outside firms introduces the dynamics of contractual relationships, and
· Getting different corporate cultures aligned under a single common vision
can be difficult.
Add to these challenges the reality that most team members are NOT located in the
same physical location, and the barriers to effective communication and collaboration
are exacerbated. 10% to 20% of PMs now have
contract management as part of their
PMs must clearly understand these barriers to communication, and then remove them job responsibilities4
in order to increase the likelihood of producing quality requirements.

5.   Effective collaboration is largely absent from

the requirements process
True collaboration isn’t happening in the requirements process, as evidenced by
the amount of rework (essentially, ‘fixing’ what was mis-communicated or not-
communicated) on every project.

In most organizations, what is labeled as “collaboration” is really just a lot of

information flying around to several people, largely by email.

This isn’t collaboration, it’s chaos.

Project Managers need to take control of the situation so that the benefits of
collaboration—a high quality product, delivered on time, with very little need for
rework along the way—can be realized. 45% of IT professionals admit to
being “fuzzy” about the details of a
project’s business objectives5

© 2012 Blueprint Software Systems Inc. 2

 PROJECT MANAGEMENT KNOWLEDGE SERIES
10 Ways Requirements Can Sabotage Your Projects Right From the Start

6. Requirements suffer as it becomes harder

to get people together
As the need to collaborate increases, it becomes more difficult to get contributors
together using traditional means like conference calls and in-person meetings. Social
technologies that foster collaboration in the requirements process can help because
they enable focused, continuous conversations in real-time—a marked improvement
over the disjointed nature of email, the tool most people fall back on when it becomes
too difficult to coordinate a meeting.

According you Gartner, project managers must focus on “more effective requirements
gathering, fostering vibrant communities and gaining demonstrable executive
involvement”.

Email makes for an abysmal

collaboration tool for requirements
7. Lack of executive involvement in the
requirements stage often dooms a project to fail
One of the primary reasons for project cancellation and failure is lack of senior
management involvement. To guard against failure, Project Mangers will need to
find new ways to court executives to provide focused and consistent input into
requirements. This will mean going beyond email as the primary communication tool in
the requirements phase, and instead exploring purpose-built requirements tools with
integrated social features built in. Such technologies make communication ’natural’,
collaborative and ‘agile’ as opposed to cumbersome and sluggish.

8.  Requirements definition is text-based versus visual, 33% of the time, project failure is
which leaves too much room for misinterpretation due to lack of involvement from
senior management6
Requirements need to be “brought to life” so that stakeholders understand them
better, and much earlier. People mentally conceive and understand ideas using imagery
and pictures, yet most organizations have a requirements process that centers on the
development of a long and detailed requirements document full of text. This forces
everyone to translate their mental visions into flat, dull text.

Then, as the document circulates to stakeholders, each person must read the text and
translate it into their own mental pictures. Misunderstandings are inevitable.

Diagrams and schematics can help, but the optimal way to communicate requirements
clearly is with purpose-built requirements technology that enables visual modeling
and simulation. This lets people ‘visualize’ the requirements prior to development,
so everyone can see and even interact with a simulation before any development
resources are used.
Less than 20% of IT teams
describe the requirements process
as the correct articulation of
a business need7

© 2012 Blueprint Software Systems Inc. 3

 PROJECT MANAGEMENT KNOWLEDGE SERIES
10 Ways Requirements Can Sabotage Your Projects Right From the Start

9. Excessive requirements changes are a major

cause of project failure
It’s the number and the impact of changes to requirements that often cause so many
projects to fail. The first step in reducing the number of requirements changes is to have
better requirements to start with, and best way to do that is to fix the collaboration
problem that is the cause of so many requirements issues. When true collaboration
replaces the sheer chaos and misunderstandings early on, there will be far less need for
changes in later stages.

Further, purpose-built requirements tools that let stakeholders see working simulations
of the new application greatly increase your ability to handle changes. Visual 80% of IT professionals admit they
simulations invites critique, tweaks and changes before development begins, which spend at least half their time on
protects your development resources and goes a long way toward preventing rework rework8
and project delay.

10. Tools that enable compliance are largely missing

from requirements efforts
Adherence to compliance regulations is now a major area of responsibility for Project
Mangers. Project requirements however are largely managed with disconnected
documents and spreadsheets with no built-in traceability or auditing functionality.
This opens the door for all kinds of compliance issues to occur unnoticed. Compliance
can’t be reduced to a one-time check and balance effort that gets placed at the end
of a project. Rather, PMs need requirements technologies that deliver traceability and
auditability in an automated fashion. This ensures visibility and proof of compliance at Reducing compliance to a one-time
every stage of the project. check and balance at the end of a
project is asking for trouble

Eliminate all 10 project saboteurs with Blueprint!

Stamp out these root causes of project failure once and for all with Blueprint – the
purpose-built Requirements Definition and Management software that gives your
Business Analysts the tools they need to drastically elevate the quality of requirements
on every project. Contact Blueprint for a live demo of the software and see how it helps
make project failures, missed deadlines and overruns a thing of the past.
1-866-979-2583
PM@blueprintsys.com
Contact Blueprint: 1-866-979-2583 PM@blueprintsys.com

About Blueprint
Blueprint (http://www.blueprintsys.com) is the world leader in collaborative Requirements Definition and Management (RDM) solutions.
Blueprint makes life easier for Business Analysts by automating the tedious, time-consuming elements of every requirements initiative—
and transforming the business-IT relationship into a visual, engaging collaboration. The result? More predictable budgets and schedules,
faster-time-to-market, and far less rework along the way.

Sources:
1, 2) Oxford University
4) Gartner Research
6) A Replicated Survey of IT Software Project Failures, Ottawa University/University of Maryland
3, 5, 7, 8) Doomed From the Start? Geneca Survey

© 2012 Blueprint Software Systems Inc. 4