Check lists for business analysts when new to a project

Check list for the beginning of a project

• Are the scope and objectives clearly defined?
• Have the problems and opportunities been identified?
• Are all of the stakeholders known?
• Is there a plan?
• What are the deliverables?

It can be difficult to know where to start at the beginning of a project so this section aims to provide a guide as to what to check for and what to do if it is unknown. A business analyst should not start trying to understand the requirements unless they can tick off everything in this section first.

It must be possible to trace requirements back to objectives and opportunities or problems to help control the scope of the project and ensure that all of the requirements trace back to these. If they don’t relate to the scope then it may not be required or if there isn’t a requirement addressing a problem then requirements could be missing.

All stakeholders need to be identified along with a knowledge of their business areas and roles. Permission also needs to be granted to speak with them and it helps if they know they are going to be contacted about the project and have time allocated. There are several techniques that can be applied to ensure all of the stakeholders are identified. It can be very problematic if a new stakeholder is identified late as buy in can then become more difficult than if they were involved earlier. A context diagram or use case model are useful techniques in that they show a picture of stakeholder involvement in a simple diagram. This enables stakeholders to ascertain easily if there is anyone missing and gives a full picture of involvement required.

A plan will help to decide what is achievable and will enable tracking of progress. It will also enable agreement upfront of involvement required and support to ensure that meetings and attendance happen when planned as slippages then need to be impact assessed.

Understanding the deadlines will also determine when workshops need to be in the diary allowing enough time for writing up the deliverables at the end. If attendees cannot then commit to the number of workshops required in the time scales then this needs to be flagged up early to ensure support and is achievable. If it is not then discussions can be had on what can be achieved.

All business analyst involvement should mean clearly defined deliverables. It must be clear as to what these should be.

 

Thoughts? Questions? Please share in the comments.