When a business analyst meets their project objectives, there’s no magic or luck involved!
Research shows that the ability to eliminate misunderstanding between project stakeholders is highly dependent on the way a project is launched.
So I’m giving you 7 areas that MUST be observed before a project is even kicked off.
It’s in the form of a BOSCARD template, and even though writing one makes you think hard, this document could be the pinnacle of project success.
It’s an agreement between stakeholders, made at the very beginning of a project.
For YOU to agree the aim and boundaries of the project, the criteria for success and, where required, the responsibilities of all the stakeholders.
It is re-referenced right through the project – YES – right to the end.
So once done, keep it in a handy location
Sky rocket your salary to £500 per day as an EXPERT Business Analyst. Find out how by downloading my E-book here!
FREE BONUS SECTION: Here's An EXACT copy of my Terms of Reference when I undertook a process improvement project. Within a Finance department processing thousands of invoices every week – Download it here
I’ve created a Terms of Reference for every process improvement project I’ve ever conducted,
And then personally had it agreed with the highest level project stakeholders.
Why? Because I know that over a 3 month period anyone can ‘change their mind’. Especially managers.
So by having this agreement available, it’s sooo easy to refer back to and PROVE the agreement. Especially with the project Sponsor.
The best thing?
More often than not, it can help prove that YOU are RIGHT.
The BOSCARD terms of reference is such a proven technique that is even a focused module of the ISEB Business Analysis Diploma Business Analysis Essentials.
If you are or want to be a contractor, after all that’s where you’ll earn the most money, this document will be the difference between success (life) and failure (death).
BOSCARD actually stands for Background, Objectives, Scope, Assumptions, Roles, and Deliverables
But I’ve created the BOSCARD plus(+) because there’s some other useful info to include in a ToR, so here goes…
· Approach (optional for added clarity)
I’ll keep this blunt so we can get into the action.
More often than not, the Project Manager will write a terms of reference
If they haven’t done it, don’t think as a Business Analyst you can’t write one
And if you’re a consulting contractor working as a Business Analyst
You’d better get your pen out, because it’s all down to you.
So a manager or business owner has requested you start (or even join) a project.
No-one really knows EXACTLY what they want you to do. But they have a vague idea
So YOU need to ask the questions. You can’t rely on anyone else at this point.
Your questions should be in the form of BOSCARD.
TIP: Remembering BOSCARD will help you get exactly what you need out of a kick-off meeting so you can get your teeth into the ToR immediately
What are the reasons for creating the project?
Who are the key business function who will benefit from the project result?
What is one key opportunity for change that the project relies on?
Opportunities could be DIRECT or INDIRECT but will have a positive impact on the business if the project is successful.
Describe the specific project objectives and link each of them with the SMART framework for project objectives –
S = Specific – objectives must be clearly defined.
M = Measurable – measuring criteria for objectives must be fully understood.
A = Achievable – objectives must be possible to achieve.
R = Relevant – to provide a willingness to involvement make them relevant to the people involved.
T = Timely – an objective must be bound with a time frame. e.g. within 2 months
List the benefits that the project is going to deliver. Where possible, these must be quantifiable benefits and are often related to the SMART framework
This section is KEY and needs to be agreed so to avoiding scope creep later in the project.
What business areas ARE included and impacted?
Which tasks ARE included?
Is there anything else you need to include?
What business areas will NOT be included, but may be included by assumption.
Which tasks will NOT be included, but may be included by assumption?
Is there anything else that could be assumed to be included but you know it isn’t?
Identify ANYTHING that could delay you reaching your ultimate goal – the constraints
A great example s lack of resource
Identify ANYTHING that could cause the project to fail – the risks
Include a quick assessment of the significance of each risk and how to address them.
Document in a table format
Constraints and risks MUST be added to the project plan (when done) and addressed throughout the project.
Get your assumptions wrong and the project WILL be delayed!
Or worse still – FAIL!
Specify all factors that are, considered to be true, without validation.
Validate your assumptions throughout the project.
Not recognizing the project’s dependencies WILL mean you fail to obtain the right resource or assets for reaching your goal
So ask yourself this…
What do we need?
Who do we need involved?
Where do we need to work?
What other projects need to be completed FIRST?
Tip: ALWAYS actively work to remove constraints and assumptions
My view is this…
When people don’t know what their roles are in a project, they can react in different ways – BAD!
Some people might be REALLY enthusiastic and try to do everything
Some might become demotivated because there’s no leadership
Defining the roles of the project stakeholders will make sure everyone can work together in conjunction with each other.
Provide the roles of the management team who will govern the project.
Provide details of team member (or Subject Expert) requirements and how much of their time will be taken up by project work.
What are you actually delivering?
This is the absolutely key
The bottom line:
If you get this wrong there will be disagreements at the end of the project
AND some upset stakeholders
So be absolutely sure to complete this section.
Define the key deliverables that the project is required to produce in order to achieve the stated objectives.
Deliverables must be tangible, e.g. Documents, Presentations or even development of a system functionality
This is a bonus section.
But it gives the stakeholders a great insight into your key activities
It also helps you determine the length of the project
SO even if you don’t include it in your ToR
DO have a think about it and let your stakeholders know.
Provide details of the work that will be completed by the project team so to meet the required deliverables. This will include key steps and high level tasks for each of those steps that you will undertake in order to complete the project.
When you’re happy with your ToR
Don’t just sit on it
And don’t delay this
Make sure you send it to your key stakeholders
Give them a date for when you want them to read it by
Follow up with a phone call if you don’t hear anything.
This is the whole reason for creating your terms of reference
Make sure you get agreement on what you’ve written
You DON’T need to get an actual signature
But you DO need to try and get an email
Although DON’T let this delay the start project
Use your influencing skills to emphasise the importance of agreement
Step 5: Refer back to the Terms of Reference (ToR)
I told you this at the start, so I probably don’t need to say it again
But doing this will help you stay on track
So keep referring back to your terms of reference document
And roll through your project with confidence and strategy!