Yet, if any of the points above are missing, then it is hard to conceive a set of artefacts that enable a traceable transition from any high level “statement” (e.g. business needs) down to a lower level of detail (e.g. test cases). Not knowing exactly what we are aiming to solve, often leads us to misguided decisions about what needs to be done, and the inevitable trail of objectionable side effects (e.g. waste of time, money and enthusiasm to name a few).
Verbal or written clues to look for:
- “We have everything in place so let’s start building - we can address the details later.”
- “We need more doers than thinkers. Let’s skip all that academic exercise and start delivering real work.”
- Isn’t it that obvious?!
- “Problem statement? This project doesn’t have a problem, everything is under control!”
Missing Why #2 – Why this approach?
This does not need to be preceded by #1, as sometimes when a project starts, it is “mandated” to adapt current “best practices”. Often pragmatism is quoted in those circumstances to avoid tasks, deemed to be superfluous, being undertaken by the project. Your experience tells you that you know a way that would work better in these circumstances, so you are left wondering “why” this approach was chosen.
Verbal or written clues to look for:
- “We cannot miss the gate date we’re scheduled for…”
- “Agile means we get this done faster”.
- “We can capture it all in the use cases”.
- “This plan is too lightweight”.
- “Don’t worry, the builders know exactly what to do with that”.
- “Our delivery method is pretty generic, so we only use what we need”.
- “This is paralysis by analysis, we don’t have to overcook it”.
Consider “acting” out of the box, not just “thinking” outside of it.
Understanding “why this project?” is paramount, and the rationale should be cemented in the business case, sprint zero, or similar funding stage. These pre-project phases can be stressful due to multiple negotiations, studies, plans, meetings and the final agreement on project sponsorship.
Often there is a "agree to agree" take on issues that are difficult to reach consensus on. It is not uncommon that key stakeholders assume arbitrary commitments to keep the ball rolling. This usually results in high levels of anxiety with the pressure to release a tangible project outcome as soon as possible.
In this critical moment, it is vital that the Business Analyst or their team take a deep breath and assess what is on the table, what is missing, and start drafting the business analysis plan.
Some possible steps:
- Verify whether the available information is sufficient to allow a robust and consistent business analysis plan. If not, then the gaps and uncertainties should be mapped and addressed in a “project initiation plan”.
- Produce a clear set of problem, or opportunity statements, affected parties and desired outcomes.
- Disclose a tactical plan, along with some options, that address the issues previously exposed.
- Provide a review that clearly shows how any estimate could be impacted by the lack of capital information and how the “project initiation plan” can mitigate these risks and even leverage the expected outcomes of the project.
- Demonstrate what the benefits are, when attempting to influence key stakeholders to approve unexpected preliminary work in the early days of the project.
- Be sensitive to the audience and make no assumptions about them having the same answers to any “whys”. Prepare, elicit, confirm, validate, and verify.
Though, setting the line that balances theory of “best practice” from the actual project approach is always risky and some people consider this an expensive misplaced academic exercise. But this can be mitigated by not ever losing sight of which artefacts need to be produced in the business analysis space.
The set of artefacts, and how they are framed up, should make evident how to translate the business needs into a feasible solution design and a relevant testing plan, in a traceable fashion. In the end: The BAs must support and influence the overall project WBS and the subsequent project plan.
The BABOK presents us a robust framework for business analysis, and those BAs who spent some time digesting its arid, but very logical content, sooner or later realise that its theory makes a lot of sense, thus it is an excellent base for any project approach.
Note: no framework, as sound as they can be, can perform the magic in transforming poor inputs in great outcomes....ooh should we refer back to missing why number 1?
There is very good material out there that cover the essential set of information that must be available when a business analysis plan is about to be compiled, yet I listed below some I consider key:
- SMART objectives associated to the relevant business needs
- Thorough stakeholder analysis
- Current scope and how its changes will be managed (scope management)
- Centralised source for project’s assumptions, constraints, risks, issues and dependencies
- Performance metrics (current and expected) of the capabilities impacted by the project
- Access to the documentation that was used to define the business needs listed in the business case
- Business analysis artefact framework (organisational process assets) that will define the expected deliverables and their templates/standards. Ideally paired with the project work breakdown structure.
- Business analysis plan template
- Requirements management methodology
In conclusion, for a project to be deemed successful, it must convert the efforts of the allocated resources to something that ultimately adds value to the business. Part of that is filling in the answers to the missing “whys”, and adopting a pragmatic approach to deliver really good “BA stuff”!
Don't forget to leave your comments below.