• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

Business Analysts Are Not Fortune-Tellers

They didn’t know the product development manager would quit one week into the project due to a disagreement over the correct pronunciation of agile.

They did not know that top management was working on a secret merger, so the scalability requirements have doubled.

They did not know that the business process analyst would elope and go for a honeymoon in Antarctica.

They did not know that all of the reviewers of the hardware and software requirements would be delayed two weeks because of a new high-priority project involving online sales of tea cozies.

They did not realize that the requirements training, product manager training, and business analyst training they had planned would fail because the trainers had accents that couldn’t be understood.

They did not know that the functional requirements would include workarounds that allow the CEO’s nephew Bill to use the system even though he refuses to use a mouse due to fear of carpal tunnel syndrome.

They did not know that the software development life cycle would be halted completely for a week because the system architect got attacked by killer bees before he was able to delegate responsibilities to his team.

They did not realize that agile requirements management meant ten different things to ten of their stakeholders.

They did not anticipate that procurement would reject their vendors for requirements consulting and project management consulting because the purchasing rep got a bonus if all their vendors for the quarter were from the preferred list.

They did not know that one approver refuses to sign anything that uses the company-standard BRD template, use case template, and SRS template because his templates lost the annual “design a new template” competition and he’s been bitter ever since.

They did not know that the requirement management tool that they were using comes up with an unexpected error message that the vendor refuses to fix whenever they attempt requirements traceability.

They didn’t know that the System Requirement Specification could not be posted to the company intranet because the intranet does not accept any documents created with any word processor released after 1987.

So please don’t ask them why these things were not in the original project plan and then tell them to plan better next time.  Also, don’t punish them for changing the plan.  When any (or all) of the above occur, the business analyst should be praised for adjusting the plan accordingly.  If you don’t want the plan to change, hire only fortune-tellers in your organization, not business analysts.

 

2 Responses to Business Analysts Are Not Fortune-Tellers

  1. Christy Nicholson August 31, 2011 at 8:49 am #

    This rocks! What a great way to start the day.

    I’ve heard a lot of excuses from analysts about unknowns that could have been resolved with the right questions during elicitation or analysis – but yeah, with the curve balls you just have to say, “ok, now where?”

  2. leighton August 31, 2011 at 11:15 am #

    Christy, nice to “see” you again! I’ll share your props with Jeremy, it’ll make his day. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *