The future success of Project Managers (PM) and the Project Management Office (PMO)s

comes down to one thingidentifying and eradicating the causes of project failure
right at the source.
This paper shines a spotlight on a major root cause of project failure in every
organizationrequirements. 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
organizations key projects before they even get off the ground
10 Ways Requirements Can Sabotage
Your Projects Right From the Start
2012 Blueprint Sofware Systems Inc.
1
When things dont 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. Dramatic project overruns stem from requirements
Most PMs and PMOs have
not identified the 10 ways
that requirements cause
their projects to fail
One in six projects have budget
overruns of up to 197%
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, its 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 requirements
PROJECT MANAGEMENT KNOWLEDGE SERIES
10 Ways Requirements Can Sabotage Your Projects Right From the Start
2012 Blueprint Sofware Systems Inc.
2
3. Approaching requirements in the same old way
wont 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. Its an
elephant in the room, which puts Project Managers and the PMO in a predicament.
Theres pressure to explore, embrace, and demonstrate the benefits of agile
development, yet exactly how agile will work in a practical sense within the enterprise
isnt yet clear.
The big, thick requirements document simply cant scale in an agile environment. At
the same time, its also clear that a simple user story alone isnt enough. As enterprises
struggle to adopt agile practices, whats 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.
PMs must clearly understand these barriers to communication, and then remove them
in order to increase the likelihood of producing quality requirements.
5. Effective collaboration is largely absent from
the requirements process
True collaboration isnt 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 isnt collaboration, its chaos.
Project Managers need to take control of the situation so that the benefits of
collaborationa high quality product, delivered on time, with very little need for
rework along the waycan be realized.
10% to 20% of PMs now have
contract management as part of their
job responsibilities
45% of IT professionals admit to
being fuzzy about the details of a
projects business objectives
PROJECT MANAGEMENT KNOWLEDGE SERIES
10 Ways Requirements Can Sabotage Your Projects Right From the Start
2012 Blueprint Sofware Systems Inc.
3
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-timea 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.
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.
33% of the tme, project failure is
due to lack of involvement from
senior management
Email makes for an abysmal
collaboraton tool for requirements
8. Requirements definition is text-based versus visual,
which leaves too much room for misinterpretation
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.
PROJECT MANAGEMENT KNOWLEDGE SERIES
10 Ways Requirements Can Sabotage Your Projects Right From the Start
Less than 20% of IT teams
describe the requirements process
as the correct articulation of
a business need
1-866-979-2583
PM@blueprintsys.com
1-866-979-2583 PM@blueprintsys.com
2012 Blueprint Sofware Systems Inc.
4
9. Excessive requirements changes are a major
cause of project failure
Its 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
simulations invites critique, tweaks and changes before development begins, which
protects your development resources and goes a long way toward preventing rework
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
cant 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
every stage of the project.
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.
Contact Blueprint:
Sources:
KPMG Global IT Project Management Survey
A Replicated Survey of IT Software Project Failures, Ottawa University/University of Maryland
PIPC Global Project Management Survey
Standish CHAOS Report
PROJECT MANAGEMENT KNOWLEDGE SERIES
10 Ways Requirements Can Sabotage Your Projects Right From the Start
80% of IT professionals admit they
spend at least half their tme on
rework
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.
Reducing compliance to a one-tme
check and balance at the end of a
project is asking for trouble