Many times we hear managers say they need a “rock star” for their project, meaning they want a talented and extraordinary performer, capable of impressing the key stakeholder crowd, by consistently delivering top quality, phenomenal results under stress and in high profile situations.

And as much as companies and projects could benefit from a rock star's creativity, drive and ability to inspire, do we really want rock stars to write our business requirements? What would happen if we had real life rock stars as Business Analysts (BAs) on our technology projects?

Consider legendary rock star Keith Richards' philosophy for writing rock lyrics.

"I look for ambiguity when I'm writing because life is ambiguous."

Although Keith's attitude has ultimately proven to be successful for writing creative and inspired rock lyrics for 6 decades, an ambiguous writing style does not convey well for technical project delivery. In fact, unclear and ambiguous requirements are a common cause of project failure:

• According to Tech Republic, 68% of projects fail due to poor requirements. For full article, see http://www.techrepublic.com/blog/tech-manager/study-68-percent-of-it-projects-fail/661.
• Unclear requirements lead to scope creep refers to uncontrolled changes to the project and represents risk to the project. According to Computer World, changing requirements during development is one of the five reasons cited for software project failure. For full article, see http://www.computerworld.com/s/article/71209/Why_Projects_Fail.
• According to IBM's Best Practices for Software Development Projects, “gathering and agreeing on requirements is fundamental to a successful project.” For full article, see http://www.ibm.com/developerworks/websphere/library/techarticles/0306_perks/perks2.html.
• According to Paul Beavers' Importance of Requirements Management for Agile Development, quality requirements are a requirement for agile development. To be truly agile, projects must have near perfect requirements. Improving requirements will lead to improved quality, ability to manage customer expectations and increased agility. However, if a project has unclear requirements, then the team is cannot determine if the product is releasable. The end result is that the team exits the iteration without adequate acceptance criteria, leading to increased QA cycles which will ultimately impact on-time, on-budget delivery. For full article, see http://every2weeks.wordpress.com/2007/11/21/importance-of-requirements-management-for-agile-development/.

Requirements must be clear and unambiguous, leaving no room for interpretation, and all assumptions must be well documented. Remember, requirements aren't a work of art or rock lyrics, open for interpretation. Requirements are critical components necessary to drive the success of your key initiatives. Thus, it is crucial to craft high-quality, clear requirements.

So how do we achieve high-quality project requirements?

According to the Project Management Institute (PMI) Voices on Project Management article Craft "High-Quality" Requirements, the following guidelines should be followed in order to collect high-quality project requirements and ultimately position your project for success.

• PMI recommends that all requirements should have a use case. Use cases clarity context and purpose.
• PMI offers the following advice on the language of requirements:
  • Avoid ambiguous words; do not leave room for interpretation.
  • Use terms consistently. And consider providing a glossary of terms to further common understanding.
  • Be concrete. Do not use words that are subjective (such as simple, easy, fast).
• PMI recommends having a Requirements Characteristics checklist that is relevant to your project's quality standards.
  
  The article provides the following 10 characteristics to assess the quality of each of your project's requirements:
  • Atomic: Is this one requirement? Or is it several requirements in one?
  • Complete: Is there enough detail to start the work?
  • Traceable: Is this related to a need (i.e., a use-case)?
  • Logical and Clear: Is it understandable? Is it unclear or ambiguous? Could it be misinterpreted?
  • Consistent: Does it relate or link to the project objectives?
  • Measurable: Can it be measured?
  • Compliant: Does it support the existing product features? Does it align to system architecture? Is it acceptable within legal framework?
  • Feasible: Is this realistic and achievable?
  • Necessary: Is this really required? Or is it more of a want than a need?
  • Prioritized: What is the priority? How critical/urgent is it?

For full article, see http://blogs.pmi.org/blog/voices_on_project_management/2012/04/craft-high-quality-requirement.html.

So leave the ambiguous and unclear writing style to the rock stars. Instead focus on writing clear and unambiguous business requirements for your projects, and although you may not be a rock star in real life, your company, customers, and peers may start to think of you as one.

Comments

This reminds me of 2 of my favorite requirements:

1) Fix the problem
2) The solution needs to work

I concur with the above, ensuring that everyone has the same picture in their mind is what is required to create minimum waste.

Patti,
Thanks for reinforcing the need for clarity when describing what a project needs to accomplish. The list of characteristics you mention are all good ways to gauge if you are properly describing the problem and conditions of a potential solution.

One thing I'd like to quibble with, and that's the thought that all requirements should have a use case. I agree that all requirements should have a clear tie to context and purpose, the only problem is that a use case, if you are talking about the requirements artifact of that name, is not always the best means of describing that clarity and purpose. Not all requirements surround an actor/system interaction which the use case is intended to describe.

I'd also like to remind everyone that another excellent source on all things Business Analysis is the International Institute of Business Analysis (iiba.org)