Building Blocks of a Project Plan

In almost all business analyst job listing, we find the following tasks listed:

• Work closely with the development team to create the final product.
• Act as a liaison between the business team and developers.

While there are a number of tasks a business analyst has to do, these two are critical to any project and take up most of the time of the BA. However, there are other tasks that will require adequate time and should be included in a project plan.

Related Article: Planning is Not a Solo Activity

A project plan forms the crux of any project. Without it, a project has many loose ends and can go on for a long time. A well thought out project plan helps to track every module of development. The plan should include time frames for each module and should also include buffer time for aspects such as change requests, UAT window, etc. A business analyst should devise time frames by keeping the following modules in mind:

1. Communicating the requirements to the development team.

A development team is the creator of an application / product. But unless a developer understands all the aspects of a project, the final product may have some shortfalls. This is where a business analyst comes into the picture.

In one of my recent projects, a developer was asked to integrate a certain insurance plan on an existing web platform. Although he had worked on such assignments before, this product was different. He was handed some documentation, and the development commenced. A few hours into the development, he realized that there was more information than expected and hence he didn’t know how to place all the modules together.

Developers are technical people. It may not always be the case that they are completely familiar with the purpose of a product. Business analysts are well versed with the requirements and understand a product fairly well. With a project plan, a business analyst should include the time that’ll be required by the development team to study and understand the relevant development documents.

2. Ensure that testers have good product knowledge

Before a project goes live, it should be screened thoroughly by the testing team. Good test cases can be created if this team also has good product knowledge.

For instance, let’s say the team has to test a mobile application which lets a user compare different financial products. The testers may miss out on some aspects if they don’t know the nitty gritty of the product. They may not be completely aware of the products available on the application and may not be able to compare the products as required. Time should be devoted to this knowledge transition exercise.

3. Change requests

No project begins with a foolproof blueprint. A well-executed project is the one which can smoothly accommodate change requests. Here’s where some buffer needs to be added to a project timeline.

In one of my recent projects, we were ready to launch a product when a stakeholder placed some last minute requests. However, this did not impact our go-live date as we had made a provision of 5 extra days to our project timeline and that was sufficient to include these changes.

4. Complete testing window

Testing can be categorized into functional testing, user acceptance testing, quality testing, etc. Based on the requirement of the project, each testing phase should be given adequate time support.

5. Final sign off from all stakeholders

Although this final leg may seem like a cakewalk, there can be times when a project gets delayed due to unavailability of one or more stakeholders. It becomes important to ensure that all the stakeholders are present on the sign off day.

Finally, once a business analyst prepares the project timeline, the timeline should be shared with all the stakeholders, and there should be consensus on that timeline. This helps the business analyst be effective at tracking of any project.