The Community Blog for Business Analysts

In the BABOK, an entire section is dedicated to stakeholder analysis (version 2.0 section 2.2). The first element of stakeholder analysis as defined in the BABOK is the identification of stakeholders. It stands to reason therefore that if we as business analysts fail at the building block of stakeholder identification, then we are putting the process of stakeholder analysis at risk and also putting the project at risk.

I remember years ago when I was in development before moving to a business analyst role overhearing a project team planning the implementation of database and process changes that weekend that would change how a group of production employees would enter their time per process. The changes were going to streamline the process and eliminate some double-keying of time. It was a great idea except for the fact that a nightly IT process that calculated incentive pay was not considered. The change scheduled to go into production that weekend would have caused the incentive calculations to fail.

You could argue for poor project management. You could argue for poor system documentation. You could argue for lackluster business analysis. But I believe you could also argue that IT was a stakeholder that was never considered because they were “suppliers” and not “customers”.

As business analysts we can fall into the same trap. If the requirements package we produce makes perfect sense to our business stakeholders and no sense to our technology stakeholders then it is not a good requirements package. To save yourself rework, before the first word of a requirements document is written, understand what your business stakeholders and your technology stakeholders need.