Writing Better Requirements: Why Projects Fail

Part 6 of 7 in the Series: How To Become A Project Manager
Write Better Requirements
Write Better Requirements

Why Do We Need Better Requirements?

The following article is a frank, open and surprising discourse on why we need better requirements.

According to Standish or Gartner reports and other case studies, nearly “two-thirds of all IT projects fail” because of poor requirements and other causes.

Why Do Projects Fail?

Consider that a project fails when it overruns the budgeted allocation of resources, time or money or fails to deliver the intended business requirements or value.

Some teams are so deep into this, that throwing more money, people or extending the shipping date is their default solution to scope creep, budget overruns or project failure!

But project failure doesn’t have to become the norm for you.

With this in mind, the following post on “Why We Need Better Requirements” is designed to help business analysts, project managers, web managers or technical leads make a case for preventing project failure by gathering better business requirements.

  1. The True Cost of Fixing Bad Mistakes

    Gathering better requirements helps avoid fixing issues further down in the project when mistakes are guaranteed to be more expensive.

    Consider a product feature that is not developed to the customer’s specifications because of incomplete requirements documentation.

    The incomplete requirement is left to an open or wide interpretation from each member of the development team.

    Depending on when the improperly coded requirements are discovered; (development, software testing or production), the cost of fixing these defects is guaranteed to be much higher than the cost of gathering, validating or documenting the complete or correct requirements at the project’s inception!

  2. The Opportunity Cost of Missing Requirements

    Discovering requirements late results in delays to the project or in shipping products that don’t meet or fall below the customer’s expectations!

    This results in missed market opportunities, unhappy customers or an improper allocation of resources, time or money.

    Why because, it costs more money to retool your product at later stages of the product development cycle than at inception.

    And regardless of what you do, you will be late to market or reduce your customers positive experiences of your product.

  3. The Cost of Working Incorrect Requirements

    Perhaps, you’ve worked on a project where requirements are dispensed as favors because the Requirements Analyst lacks the authority or training to validate requirements properly.

    This is the practice where requirements are imposed on the project team without meeting the business case or scope.

    The cost of such a practice is that the project resources (people, money, time, infrastructure) are high-jacked to satisfy a few egos to the detriment of the organization’s strategic objectives, goals, missions or success!

Making The Case For Good Business Requirements

Note that when it comes to executing projects successfully you will always have the constraints of time, money or resources (people).

And regardless of who you work for, your project cannot be handled as if your organization has an infinite supply of these inputs.

So gathering incorrect, poor or wrong requirements will result in the improper allocation of resources and at the same time increase the risk of project failure.

Armed with this, don’t be a doormat, make a proper case to your management, stakeholders or project advisory team on the need or strategic importance of gathering better business requirements.

Action Plan: How To Gather Better Requirements

I’ve shown you why gathering better requirements matters and explained how you can make a case for sound requirement management practices at your organization.

Here is how you can help your organization adopt a better requirements management practice.

  • Empower your Requirements Analyst

    Hire a capable requirements analyst for your project and then empower the resource to do their job.

    Adding a Requirements or Business Analyst to your team without empowering the resource is a practice in self-deception at best.

    So don’t start down that part, if your organization is not ready to rally behind their Requirements Lead.

  • Lead, Follow or Get Out of the Way!

    Your Requirements or Business Analyst is there to help your project or organization succeed, so don’t make that resource into the enemy!

    Educate your stakeholders, management team or customers on the benefits of following a sound, documented requirements management plan.

    Find a champion who can lead that effort … then follow your chosen leader or get out of the way!

    The Requirements analyst’s job is not to dispense requirements as favors but to be a custodian of the organization or customer’s strategic vision, aspirations or expectations.

By understanding, communicating, leading or championing better requirements practices, you reduce the risk of project failure and help your organization achieve a better Return On Investment (ROI).




2 Responses to "Writing Better Requirements: Why Projects Fail"

  1. Matt   November 29, 2010 at 11:33 pm

    I’m stepping into a Business Analyst role with my company starting the beginning of the year.

    My first project will be creating documentation for all the in-house systems.

    Might I add, this is my first IT position and just graduated with a BS in Business System Analyst.

    Any advice?

    ReplyTweet
    • IT Career Coach   November 29, 2010 at 11:54 pm

      Congratulations on your first job as a Business Systems Analyst. Here is my advice for you:

      #1: Put yourself in the shoes of a technical writer. Your job will be to ask a lot of questions, pay a lot of attention to detail, and write the verst best technical documentation that you can.

      #2: Make a lot of friends because you will be needing their help formally and informally as your tasks and priorities change.

      #3: Pay attention to the needs of the stakeholder and the project leaders and even your project manager. They are the ones to recommend that you keep earning a paycheck with the company.

      #4: Getting a business analyst job is a damn competitive affair, so take your job seriously … no take your job seriously! Be the first one in and the last one out if you can help it.

      #5: Look out for opportunities to lead by serving. As you get your own work done, look out for those tasks that no-one seems to pay attention that or for problems that you can solve especially by going out of your way to do so. You want your employers to feel grateful that they hired you and to see that your are the best investment for their money.

      #6: Don’t forget Pareto’s Law. Spend the majority of your time documenting the most important in-house systems because those will play the biggest part in determining if your project is a success or not.

      #7: Take time to establish your documentation standards. Perhaps your boss or team has a standard for documentation which they want you to follow rigorously or perhaps documenting is weak and you need to come up with better documentation than what they are used to!

      ReplyTweet

Leave a Reply

Your email address will not be published.