Project Practitioners > Rock Stars as BAs?

Rock Stars as BAs?

By Patti Gilchrist
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:

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

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.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

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.

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 (

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.