Business Analysis

Business Analysis is at the very core of what I do. It is a term with varied meanings and often misunderstood – if understood at all! It is also an essential part of delivering an IT (or any kind) project that aligns to business objectives.

The business analysis I provide here the process of requirements engineering. This consists of:

Requirements Elicitation – the process of finding out and documenting what your business requirements are that have initiated the need for the project. This can take many forms of simply asking questions of you, your team/employees and other interested stakeholders who will be affected by the change. These can go from very high level “We need to sell more stuff” down to very detailed “on clicking this button the next page that loads must show me x,y and z information”

Requirements Analysis – the process of analysing all collected requirements and filtering out duplicates and addressing conflicts (stakeholder 1 wants it in blue whereas stakeholder 2 wants it in red), categorising and prioritising requirements to differentiate your “must haves” from your “nice to haves”  – your minimum viable product from your bells & whistles (which can always be added later)

Requirements Validation – the process of agreeing with you and other decision makers what your requirements are and base-lining them as a defined project scope. These will then be signed off and any changes down the line will need to be formally agreed depending on how your organisation approaches change. Typically this will be a change request approved by a change control board. This is important because it controls “scope creep” which is one of the most common causes of project failure due to uncontrolled spend and time-sinks.

Requirements Management – the process of managing the delivery of the project against agreed requirements, typically through agreed testing and (measurable) acceptance criteria that is established in previous phases of elicitation and analysis. This stage also includes the management of changes to the base-lined requirements (actually we don’t want it to be blue – can we make it red after all?)

The requirements engineering process encompasses much of the business analysis activity which also includes stakeholder analysis (finding out who in the organisation I need to speak to to get requirements from), process mapping (drawing boxes with arrows that point to other boxes) the as-is and to-be scenarios and generally assisting with the project including some project planning and management.

Essentially the outcome of business analysis is a very well defined and detailed project scope that is made up of your unique requirements that are prioritised, categorised and base-lined with measurable acceptance criteria and controlled change.