In this followup to the Beachcamp series, we show how different knowledge areas from the BABOK come into play in a real life project.

One of the comments we received after publishing the first post in the Beachcamp series was “Could you explain how each section such as Requirements Analysis, Enterprise Analysis and so on works with a real time scenario?”

To answer this question, today I will show how all the presented parts work together within the project lifecycle based on the projects I have carried out. I will describe just the four key phases in a project to keep the story short.

Start-Up

There are two scenarios when a project starts. First, an industry governing body can impose requirements that an organisation needs to comply with. Another scenario is where the existing solution either does not perform well or lacks capabilities required by the business.

In either case, the first task is to identify the actual business need. As the project has not been formally initiated, the business analyst (BA) talks to the concerned stakeholders (Requirements Elicitation) to understand their perception of the need (Enterprise Analysis and Solution Assessment & Validation). During these meetings the BA evaluates and roughly prioritises the requirements (Requirements Analysis).

Once sufficiently detailed information is available, the BA evaluates it to get an idea about the possible solution scope (Enterprise Analysis), the approach to business analysis if the project goes ahead (Bussiness Analysis Planning & Monitoring), and makes estimations of his/her efforts to deliver business analysis artifacts (Business Analysis Planning & Monitoring).

Initiation

After the project has been approved to go ahead, the BA determines the approach to business analysis, plans what business analysis activities will be undertaken, refines the estimation of effort, works on developing a requirements management plan and a communication plan, and specifies how progress will be monitored and reported (Business Analysis Planning & Monitoring).

The BA then conducts formal meetings and workshops (Requirements Elicitation) with the project stakeholders to gather information required to confirm the requirements. At the same time, the BA gathers information about the existing information landscape, business processes and enabling them IT services (Solution Assessment & Validation) and identifies their pain points. The BA identifies the degree of pain, defines gaps in capabilities (Enterprise Analysis) and determines a solution approach (Enterprise Analysis).

During the meetings and workshops the BA evaluates the readiness of the organisation to transition to the target state (Solution Assessment & Validation). The assumptions and constraints are accurately documented (Requirements Analysis) and used within other stages of the project.

The Requirements Management & Communication area comes into play as soon as the first requirements have been confirmed (Requirements Elicitation). The BA establishes requirements traceability from the outset as a tool to perform impact analysis and manage solution scope when changes to requirements occur within the project lifecycle.

The BA specifies and validates the identified requirements (Requirements Analysis), creates requirements packages for communicating requirements (Requirements Analysis) to different segments of the project stakeholders. I often use Use Cases as the requirements package. This approach enables me to present information in a clear way and the requirements are easily understood by both business stakeholders (subject matter experts and business users) and technical stakeholders (software developers and testers).

I recommend reporting on progress on a weekly basis (Business Analysis Planning & Monitoring) to ensure that corrective actions can be taken in a timely manner. This is especially true about the compliance projects with fixed deadlines.

Execution

The approved requirements (Requirements Analysis) enable solution development. This project stage often results in a lot of changes to the requirements, so Business Analysis Planning & Monitoring and Requirements Management & Communication areas are both used to ensure that the planned activities are managed properly, changes are communicated in a timely manner and solution scope is under control.

As design of the solution becomes available, the BA works on assessing how well the solution meets the requirements (Solution Assessment & Validation). The BA refines transition requirements (Solution Assessment & Validation) to ensure that the organisation can move to the target state with minimal disruption to the normal business activity.

When components of the solution undergo testing, the BA works with testers to evaluate their performance (Solution Assessment & Validation). When the solution is ready for testing, the BA participates in integration testing to evaluate the value to be delivered to the business.

Two key aspects are important here. One is to ensure that the business gets what was required (processes and software functionality). Another is that the business gets what was required when the business needs it (solution availability). These two aspects ultimately define the value that the solution delivers to the business.

Closure

The final project stage is to hand over the solution to the business. The BA reports on business analysis deliverables and lessons learned (Business Analysis Planning & Monitoring). As some requirements may be re-used at later stages, the BA stores them in a way enabling re-use and maintenance (Requirements Management & Communication).

The approved business analysis artifacts go into a repository of project documents. The BA informs the project stakeholders where the documents have been stored (Requirements Management & Communication). The BA participates in the post-implementation meeting to confirm the value delivered by solution (Solution Assessment & Validation) and satisfaction of the business objectives (Enterprise Analysis). The BA communicates lessons learned to the project stakeholders (Requirements Management & Communication).

As the final activity on the project, the BA gathers stakeholders’ feedback on his/her performance on the project (Requirements Management & Communication).

Conclusion

As you can see, there is no linear progression through the knowledge areas during the projects. The BA has to draw on different knowledge areas throughout each stage of the project.

Thank you for devoting your valuable time to this series!