Document Management Rapid JAD

Getting It Right


by Erik Jul

When specifying requirements for a new system, large or small, how much do we have to get right?

Isn’t “All of it” the right answer?

Not always, and maybe never.

Concepts such as “minimally viable product” (which carries the moniker MVP as if it were some sort of champion), “iterative solution scoping,” and “progressive elaboration” decry the notion of completeness and possibly even that of correctness.

Of course, no one wants to deliver, or attempt to use, a system that does not work or is ill-suited to the task. So “getting it right” must matter to some degree: the system must work as specified.

But how much of what the user needs or wants has been identified and correctly specified in functional and other requirements? And of that, how much was correctly implemented?

Relying upon a Six Sigma approach (a methodology driving toward six standard deviations between the mean and the nearest specification limit) may reduce defects, but may still fall short of identifying a customer’s true problem and its best solution.

Lean, Lean Six Sigma, Agile, and the Three Amigos Scrum Alliance. These, plus approaches already forgotten or yet to be proposed, try to help us “get it right.”

In successive waves of innovation and reinvention, practitioners attempt to narrow the gap between what’s needed, what’s specified, what’s delivered, and what solves the customer’s problem.

Along that path, from problem to solution (scope, time, and cost notwithstanding), the professional solutions team—sponsor, business owner, project manager, business analyst, QA /tester, solution architect, developer, trainer, change management lead—all focus on “getting it right.”

Common software development and project management practices such as change requests, expectation management, phased releases, bug fixes, cumulative updates, and new versions testify that “getting it right” remains a noble goal seldom reached and maybe never reasonably expected.  For now, these are our best tools for getting it right, eventually.

To increase the likelihood of getting more right now rather than eventually, try these Rapid JAD principles: Capture Now, Document Once, Visible to All, and Revise Quickly.

Simple. Proven. Effective.

How much do you want to get right?


Document Management

Do Requirements Matter?


Software Requirements by The Requirement Company

Project Approval

You go to the company president requesting $500,000 for a project and they say, “Sure. No problem and please do not bother me with details such as why you need it.”

Blind approval as described above is not likely to happen. There may or may not be a formal cost benefit analysis completed. It is after a project is approved that more information about the project is detailed in the requirements.

Skip the Requirement Phase

What about skipping the requirements phase? Requirements can take a lot of time to put together, thus adding cost. Why not be Agile and get rid of this initial requirements phase of the project and jump right into coding. Shape the system as it is being developed. This will reduce time and cost.

Do Requirements Matter?

What is the purpose of requirements? There are two major reasons to have requirements:

  1. Define the business needs
  2. Identify what is to be built (A.K.A. project scope)

Can someone just start coding the new system when the business need has not been defined?  How will they know what is to be built? If the project is small, then yes they can. Someone from the business can verbally communicate what needs built and a developer can build it. How does this work on a large project?

The larger the project, the more difficult and more risk the project will take on when skipping the initial requirements phase. A project might achieve savings early on by skipping the requirements phase, but that savings is now going to be spent in excess of the early savings, due to loss of potential revenue and developing features which were missed or need changed.

How Much Do Requirements Matter

According to PMI’s Pulse of the Profession In-Depth Report

  • The #2 most cited reason projects fail is due to poor requirements management
  • Inaccurate requirements gathering remained a primary cause of project failure (37 percent) in 2014
  • For projects which do not fail, 4% of project budget is wasted due to poor requirements

According to IAG ‘s 2009 Business Analysis Benchmark Report

  • 74 percent of companies reported having a low level of requirements management maturity
  • These companies achieved their business objectives 54 percent of the time, while taking 35 percent longer to deliver their results.

If you are going Agile and thinking of going lite on requirements, perhaps the statistics above are worth noting. You may want to invest more time in quality requirements. For additional information on Requirements visit Requirements Engineering Magazine