The future success of Project Managers (PM) and the Project Management Office (PMO)s comes down to one thing—identifying 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 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…

10 Ways Requirements Can Sabotage Your Projects Right From the Start

© 2012 Blueprint Software Systems Inc. 1

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

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

2. ‘Over-build’ expands project scope unnecessarily, and can always be traced back to requirementsOn 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

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

© 2012 Blueprint Software Systems Inc. 2

3. Approaching requirements in the same old way won’t work in agile environmentsWhile 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 requirementsGood 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 processTrue 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.

10% to 20% of PMs now have contract management as part of their job responsibilities4

45% of IT professionals admit to being “fuzzy” about the details of a project’s business objectives5

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

© 2012 Blueprint Software 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-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”.

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 time, project failure is due to lack of involvement from senior management6

Email makes for an abysmal collaboration tool for requirements

8. Requirements definition is text-based versus visual, which leaves too much room for misinterpretationRequirements 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 SERIES10 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 need7

1-866-979-2583PM@blueprintsys.com

1-866-979-2583 PM@blueprintsys.com

© 2012 Blueprint Software Systems Inc. 4

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 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 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 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:1, 2) Oxford University 4) Gartner Research 6) A Replicated Survey of IT Software Project Failures, Ottawa University/University of Maryland3, 5, 7, 8) Doomed From the Start? Geneca Survey

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

80% of IT professionals admit they spend at least half their time on rework8

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-time check and balance at the end of a project is asking for trouble