WARNING: Don’t read this article if you’re just trying to pass an exam, because I extend the standard BOSCARD technique far beyond the textbook. I’m giving you the real-world view, from 23 years experience as an IT professional, as to how this techique can be made most useful.
Table of Contents
- PART 1: Terms of Reference
- PART 2: The standard BOSCARD technique
- PART 3: Introducing Super-BOSCARD
- PART 4: The elements of Super-BOSCARD – Just read this if you’re in a hurry!
- PART 5: Running a meeting, interview, call, or workshop to build a Terms of Reference using Super-BOSCARD
- PART 6: Questions to ask during a Terms of Reference meeting
- PART 7: Presenting your Terms of Reference
- Conclusion on using Super-BOSCARD to write your Terms of Reference
- FAQ – Frequently Asked Questions on Super-BOSCARD
- Useful references on BOSCARD
When you’re doing a piece of work, do you ever feel like you’re floundering around without a clear sense of direction or purpose? That you’re not sure what you’re supposed to be doing, or why you’re doing it? That your boss hasn’t told you what’s going on? That the various people you’re working with don’t agree on what’s supposed to happen?
If so, the way to fix it is simple: you need a good Terms of Reference.
PART 1: Terms of Reference
What is a Terms of Reference?
It simply tells you, for a piece of work, what you’re trying to do, and why you’re trying to do it. It can form an agreement between the stakeholders as to the Who, What, Why, When, and How of the work.
Over time, people can “forget” or change their mind over what they were asking for. The Terms of Reference lets you go back and see what you originally agreed, and then update it where necessary.
If you ever find yourself thinking, “What the heck am I trying to do here?”, then you need to take a step back and create a Terms of Reference.
Why use a Terms of Reference?
The TOR can give you a clear understanding of the work. Clarity is essential, to avoid wasted effort and wasted time. It lets you find out what is really needed and required. It also lets you communicate the work with the other people involved, and lets you know when you have finished.
Without a good TOR you’ll often be going around in circles, never really knowing where you’re supposed to be going.
Who should write the Terms of Reference?
It doesn’t matter too much who actually writes the Terms of Reference. It’s more important that it gets agreement between the senior stakeholders who will be involved in your project, to make sure everyone is happy with the final understanding.
A Terms of Reference can be written by a Project Manager, a Business Analyst, a Product Owner, or anyone with a vested interest in the work being set.
In theory, a Project Manager or some kind of Product Owner or senior stakeholder should write the Terms of Reference. In practice, I’ve found that it’s often the Business Analyst that will write the Terms of Reference, and then present it for discussion and approval.
The Terms of Reference can be quite detailed, so to be written well it needs a person who can see both the big picture and the detail.
If your manager gives you a piece of work that you don’t fully understand, you can create your own Terms of Reference—it can be small and concise—to help you clarify the work before you start.
How big does a piece of work need to be before you need a Terms of Reference?
Anything that’s going to take a day or more, or that isn’t completely clear, could often benefit from a good Terms of Reference. It’s much easier to do the work when you’re clear on exactly what the work should be!
If the work is quite small, your Terms of Reference could just be a few key bullet points. If the work is a much larger project, you might end up with two or three pages to cover a full Terms of Reference.
How important is a Terms of Reference?
A good Terms of Reference is absolutely VITAL! Without it, you won’t agree on the work you’re doing, and you’ll probably end up wasting a lot of time, and producing work that doesn’t meet requirements, because you don’t know what the requirements actually are!
Without a Terms of Reference, you literally don’t know what you’re doing! There will be the huge tendency to jump towards a solution before you really understand what you’re solving.
Isn’t this planning in advance? I’m terrified of being accused of “doing waterfall”!
Don’t think of it as planning in advance, consider it thinking in advance. I’m arguing this is NOT waterfall. Agile is useful when things are changing, but not everything changes all the time!
You need to distinguish between fundamental, earth-shattering change, and smaller changes you can live with. An airline will still be flying planes in five years time; an online clothing retailer will still be selling clothes in five years time. Often, change comes as a big step change, then only very small incremental and continuous improvements.
The much bigger peril is that you “fail to plan, plan to fail!” Without a decent understanding of what you’re trying to do, your agile techniques won’t work, because you have nothing to aim for. You and your team will just end up confused, and you’ll waste a lot of time.
So step away from the JIRA, and set your epics and stories aside for a moment, and consider the big picture.
Summary: What is a Terms of Reference?
- Lets you clarify and understand a piece of work before you start it.
- Reveals areas where you are not yet clear, where you need to ask questions.
- Tells you what the work needs to achieve to be successful.
- Gives everyone on the team a clear understanding of your goals.
- Lets you communicate and agree the shape of the work with senior people.
PART 2: The standard BOSCARD technique
One of the classic tools to create a Terms of Reference is called BOSCARD. It usually stands for Background, Objectives, Scope, Constraints, Assumptions, Risks, Deliverables.
It’s really just an acronym to get you thinking through the most important things you need to consider.
There’s also a similar, shorter form called OSCAR, which removes the Background and Deliverables, although I don’t recommend that you do this, because I’ve found in practice that both of those sections are important.
Where is most of the value in BOSCARD?
Most of the time, especially for smaller pieces of work, I’ve found that most of the value comes from the BOS-D, rather than the CAR. In other words, Background, Objectives, Scope, and Deliverables gives you most of the power of BOSCARD. The CAR section—Constraints, Assumptions, Risks—is more useful on larger projects.
It’s best to tackle the BOS before the CARD, because the information in the CARD section largely comes out of what you discover when producing the BOS.
PART 3: Introducing Super-BOSCARD
What’s better than BOSCARD?
Although BOSCARD is a useful starting point, I’ve found that in practice it misses out a lot of key information that you often need to know. BOSCARD itself only does half a job. In this article I’ll show you a fuller and richer tool
Introducing Super-BOSCARD
To overcome some of the real-world problems I was having with BOSCARD, leaving me with an incomplete Terms of Reference, I decided to beef it up! So I created Super-BOSCARD. It’s still basically BOSCARD, but with a few more things that it’s useful to consider.
Of course, with great power comes great responsibility. Don’t feel that you need to include every heading within your Terms of Reference. There’s nothing worse than reading a document that just repeats the same irrelevant things over and over again because it’s been written to conform to a template.
So use your judgement. Super-BOSCARD is only there to help you produce a Terms of Reference. The Gods of Computer Science won’t come down on you like a ton of bricks if you leave some things out if they’re not relevant!
So pick and choose, to create something that’s right for you. Don’t create something too long and unwieldy. Feel free to combine categories, or ignore categories—whatever gets you the best end result.
As a general rule, the larger the piece of work, and the longer it will take, the more of these headings you should use, and the longer and more detailed your Terms of Reference should be.
See these headings as a starting point for discussion. Often, the discussion that you generate will be as useful as the conclusions that you eventually reach.
PART 4: The elements of Super-BOSCARD – Just read this if you’re in a hurry!
Super-BOSCARD is made up of four parts: three sets of things to consider, and a set of filters to use afterwards to validate that your Terms of Reference is suitable.
The four parts of Super-BOSCARD are:
- The current world: where are we now?
- The perfect world: where would we like to be?
- The imperfect world: what might hold us back?
- Filters: is our Terms of Reference likely to be correct?
I’ve presented these items in the approximate order you will usually consider them.
The current world
This is a part that many people miss, but it’s important to set the scene, to understand how the work came to be requested. People will try to rush you here, and not define the problem accurately—you must resist this! They all want to skip straight to solutions, but this is a huge mistake.
| Background | What brought you to where you are now? |
| Problem (Opportunity / Needs) | What specific problems do you need to solve, and who is experiencing these problems? If the word “Problem” would be politically unacceptable, perhaps because it implies that somebody hasn’t done their job properly, you could use the word Opportunity or Needs instead of Problem. |
The perfect world
This is the exciting part, for what we’re going to do!
| Vision | What’s the opportunity? What’s the big picture of the future state the work is trying to achieve. As Einstein said, “If you can’t explain it simply, you don’t understand it well enough.” |
| Objectives | How do you know you’ve met the vision? You could use SMART goals, OKR (currently fashionable), or just write some simple clear statements of what you need to achieve. |
| Benefits | What are the business benefits of the work? Increasing revenue? Cutting costs? Saving time? Can we quantify these benefits with figures? (Sometimes you can capture the benefits within the Objectives, if you are using a technique like OKR.) |
| Scope | What will you do, and what will you not do? |
| Enterprise Context | How does your work fit into the wider goals of the whole organisation? |
| Reasons | Why are you doing this work? |
| Deliverables | What will this work actually produce? |
| Stakeholders, Roles and Responsibilities | Who is involved, and what will they do? (This doesn’t need to be a full RACI or RASCI yet.) |
| Governance | Who will approve and sign-off on the work? How will it be governed? |
| Approach | How will you tackle the work, as your high-level approach? Not essential, but it’s good to get general agreement before you start, especially if there are some quite different routes you could take. Make sure you don’t get bogged down in detail if you choose to discuss the approach. |
The imperfect world
This is the boring part, with all the difficulties we might face.
| Constraints | What existing problems do we have to live with? |
| Assumptions | What do we assume is true, which we will validate and question later? |
| Risks | What could go wrong, and how could we deal with it? |
| Dependencies | Which other people, systems, departments, projects, and organisations, are we relying on? |
| Financial | What’s the budget, and do we have enough money? |
| Timescales | How long do we have? Are there dates we need to hit for legal or regulatory reasons? Can we break this down into milestones? |
| Legal and Regulatory | Are there any legal or regulatory hurdles to clear, or things that would stand in our way? |
| Ethics | Is our work fully above board? Are we causing any harm? |
Filters and Checks
This makes sure you’re on the right trajectory. These aren’t usually headings to write down; they’re checks you can do on your work when you’ve got a good first draft. It’s a validation of your Terms of Reference.
| Consistency | Does anything in this Terms of Reference contradict itself? |
| Alignment | Does your work match to the strategy of the company, your department, and your manager? |
| Simplicity | Are you using a sledgehammer to crack a walnut? Are you making things harder than they need to be? Could you get the same results with less work? |
| Sanity Check | If you showed your Terms of Reference to an intelligent friend, would it make sense? Or have you gone crazy? |
| Agreement | Does everyone who needs to agree with what you’re doing actually agree? Do you need formal sign-off or approval? |
PART 5: Running a meeting, interview, call, or workshop to build a Terms of Reference using Super-BOSCARD
You need to make sure that the senior people with an interest in your work are able to give you their views on what you need to do. They will help you to build a holistic Terms of Reference that sees things from all the appropriate angles.
Sometimes this is easy, and other times it’s a bit like getting blood from a stone! Quite often you find that people only have a vague notion of the work, and when you try to actually pin them down on details they become very waffly and evasive, and lack any real clarity. That’s actually a good sign, because it tells you that something is wrong, and it really makes the case for why you need the Terms of Reference.
Set a formal agenda before the meeting
I recommend setting a formal agenda for your meeting or call, and publishing it in advance (put it in the meeting invitation). Some people might then start to prepare some more structured thoughts in advance, if they know they’re going to be grilled!
I usually start with a 1 hour meeting. These days, if you go for anything longer than an hour it’s very difficult to actually schedule a time when everyone can attend. Also, people will switch off after an hour or so, and lose concentration. Once the hour is up, you can go away and start to write up what you’ve got so far, make sense of it, and the gaps and further questions will become more obvious. You can then have another meeting to clarify those areas.
Meeting agenda for a Terms of Reference meeting
You can remove any agenda items that you don’t think are relevant for your particular piece of work. Copy and paste this into your meeting invitation:
The purpose of this meeting is to understand exactly what this piece of work involves, and exactly why we are doing it.
Here is the agenda for our 1 hour meeting. Time is quite tight, so please be on time!
- Welcome and Introduction (5 minutes)
- The Current World (10 minutes)
- Background to where we are now
- Problems we need to solve – we need to understand this thoroughly
- The Perfect World – where we want to get to (25 minutes)
- Vision
- Objectives
- Scope: in scope and out of scope
- Enterprise context for where this work sits in the wider company
- Reasons for doing this work
- Deliverables
- Stakeholders, Roles, and Responsibilities
- Approach (if time): the high level way we will tackle the work
- The Imperfect World – things that could hold us back (15 minutes)
- Constraints
- Assumptions
- Risks
- Dependencies on other people, systems, departments, projects, and organisations
- Financials and budgets
- Timescales
- Legal and regulatory
- Any ethical concerns?
- Wrap up, actions, and next steps (5 minutes)
PART 6: Questions to ask during a Terms of Reference meeting
Here are some questions that you can ask, for each heading, to get the discussion started.
You don’t need to ask all of these questions, but they will give you a good starting point. Pick and choose the most appropriate questions for your situation. Don’t ask every single question, or you’ll be there for hours!
Background
- Tell me why you decided to start this piece of work?
- Where did the idea for this work come from?
Problem / Opportunity / Needs
- What sort of problems have you found that led you to kick off this piece of work?
- Who is experiencing these problems?
- Can you put on a figure on how much time or cost these problems are causing us?
- How much more revenue could we make if we could fix these problems?
- Who is asking you to fix these problems?
- Has anyone tried to solve these problems before? How did it go?
Vision
- What the vision for how things will look when this work is completed?
- What’s the big picture for how you want this work to turn out?
- What do you want to have achieved when we’re done with this work?
- If you could wave a magic wand, what would thinks be like when we’re done?
- Where would you like this work to be in 12 months time?
Objectives
- Can we make a bullet-point list of the high-level objectives for this work?
- What are the 3-5 main big things you’d like this work to accomplish?
- Which of these objectives are the most important?
- Can we prioritise these objectives?
Benefits
- What are the benefits of doing this work?
- Are we aiming to make more money, or cut costs, or save time?
- Can we assign benefits to each of the objectives we identified?
- Can we put numbers on any of these benefits?
Scope
- Which parts of the business do you think will be affected by this work?
- Which areas do you think we’ll need to look at?
- Which systems do you think this work will affect?
- Are there any specific areas we should take out of scope and not look at?
- Is there anything we can take out of scope for now, to reduce the amount of work we need to do?
Enterprise Context
- Where does this work fit into the bigger picture for the company as a whole?
- Which strategies are we aligning with when we do this work?
- Is there anyone else here working on something similar?
Reasons
- Why is it important that we reach these objectives?
- What are the big reasons that you want to do this work?
- Can we list a reason for each of the objectives we identified?
Deliverables
- What would you like this work to actually deliver?
- What format should the deliverables take, e.g. Word documents, software?
- Who will use the deliverables, and what will they do with them?
Stakeholders, Roles and Responsibilities
- Who will we be working with on this?
- Who are the senior people involved?
- Who will we be working with day-to-day?
- Who is the overall decision maker?
- Are there any specific stakeholders we need to identify now?
- Who will accept the deliverables when we’re finished?
Governance
- Who needs to approve or sign off on things, and what will they want to see from us?
- How will we govern the work to keep it on track?
- Do we need a Steering Committee or Project Board?
- Do we need regular status updates?
Approach
- What general approach do you think we should take with this work?
- How do you think we should start?
- What are the first steps we need to take?
- How do you think we should break this work down?
- Where do you think we should start with this work?
- What do you think will be the main workstreams involved?
- What project management methodology do you want to use?
Constraints
- Are there any problems you can see we’re going to face?
- Is there anything that’s going to stand in our way?
- Are there any constraints or things we’re going to have to work around.
Assumptions
- What are we assuming here when we do this piece of work?
- Is there anything we’re assuming in our definition of the problems that might not be true, or that we need to check and validate?
Risks
- How risky do you think this piece of work is?
- What risks are we facing here?
- What could go wrong with this work?
- Is there anything that could happen that would send us off-track?
- Have you thought about how we could handle these risks?
Dependencies
- Who else are we depending on to get this work done?
- Are we going to need time from any other team or department to be able to do this work?
- Do we have any people, systems, departments, projects, and organisations, that we’re depending on to be able to do this work?
Financial
- What’s the budget for this work?
- When does the budget start and end?
- Does anyone need to sign off on the financials?
Timescales
- When does the work need to be completed by?
- Do we have any hard deadlines that we absolutely have to meet?
- Can we break the work down into phased deliveries?
Legal and Regulatory
- Are there any laws or regulations that we’ll specifically need to be aware of?
- Who can we check the legal position with?
- Who will sign off on the legal and regulatory side of things?
- Does this work comply with the company’s internal policies?
Ethics
- Are there any ethical concerns about this work?
- Would we be causing anyone any harm by this work?
- Does this work inadvertently discriminate against anyone?
- Would we be comfortable if this work became public knowledge?
PART 7: Presenting your Terms of Reference
It’s perfectly acceptable, and often desirable, to create a Terms of Reference for pieces of work you’re doing on your own.
However, once you’ve done your analysis you’ll often need to present it to other people, to communicate what you’re doing and to seek senior approval.
The options for your presentation are usually:
| Directly in an email | Good if the Terms of Reference is short, and the piece of work is quite small. |
| PowerPoint slides | A good middle ground when you don’t want to be too formal. People seem to like PowerPoint because they think it gives them an excuse to be vague and woolly, and not have to think too hard! But you’re going to lull them into a false sense of security, then whammy them with the good stuff! Careful you don’t get bogged down in making it look pretty, rather than spending your time on the actual analysis. |
| Word document | Many people seem to think that a Word doc is too formal, or they might actually have to think and concentrate! But if you’re doing a larger piece of work, a Word document is usually easier to annotate, add reviewer comments, and print out for easy reference. |
| Wiki page | Good when you need to share your Terms of Reference with other people, and it might need to change. The wiki is useful for keeping a history of changes, and who made them. |
Conclusion on using Super-BOSCARD to write your Terms of Reference
Having a great Terms of Reference is vital if you want to do great work. It builds agreement and clarity on the big picture for what you’re trying to achieve.
Using Super-BOSCARD makes it easy to build a comprehensive and bullet-proof Terms of Reference.
Give it a try on your next project, and let me know in the comments below how it works for you!
FAQ – Frequently Asked Questions on Super-BOSCARD
What is Super-BOSCARD? Super-BOSCARD, created by Ian Howlett, is an evolved version of the traditional BOSCARD framework, developed for crafting a detailed Terms of Reference. It includes additional elements beyond the standard Background, Objectives, Scope, Constraints, Assumptions, Risks, and Deliverables. This method is particularly useful for achieving deeper insight and clearer guidelines in project management.
Who should use Super-BOSCARD? Professionals like Project Managers, Business Analysts, Product Owners, or anyone involved in project planning and execution can benefit from Super-BOSCARD. It’s designed to offer a structured approach for defining project parameters, making it applicable across various roles and industries.
How does Super-BOSCARD differ from standard BOSCARD? Super-BOSCARD expands upon the original BOSCARD framework by introducing more comprehensive elements for project analysis. This includes a more nuanced exploration of the project’s context, objectives, and potential challenges, giving a more robust foundation for project planning.
Why is a Terms of Reference important? A well-defined Terms of Reference is essential as it establishes a clear, shared understanding of the project’s goals, scope, and responsibilities. It acts as a guiding document that helps in aligning stakeholders’ expectations, preventing misunderstandings, and ensuring efficient use of resources.
Can Super-BOSCARD be adapted for different project sizes? Yes, Super-BOSCARD is versatile and can be tailored to suit both small and large projects. Its framework is designed to be scalable, allowing you to include more detail for complex projects or simplify it for smaller tasks. Make sure to tailor it to your needs, so you’re only including sections that are relevant to you.
What are the key components of Super-BOSCARD? The key components of Super-BOSCARD include an assessment of the current situation, a vision of the ideal outcome, identification of potential barriers, and filters to ensure the Terms of Reference is relevant and accurate. These elements provide a comprehensive view of the project.
How does Super-BOSCARD aid in project clarity? Super-BOSCARD aids in project clarity by thoroughly addressing the various aspects of a project, from its inception to completion. It encourages a holistic view, ensuring that all potential issues and objectives are considered and agreed upon.
Is Super-BOSCARD suitable for Agile environments? Yes. Super-BOSCARD can be effectively integrated into Agile methodologies. It offers a structured approach to define project goals and scope, which complements Agile’s flexibility and adaptability, facilitating more focused and effective project management. I have found that Agile projects are especially prone to drifting off-track, so using Super-BOSCARD to develop a good Terms of Reference is particularly important if you’re using Agile.
How should I present a Terms of Reference using Super-BOSCARD? When presenting a Terms of Reference developed through Super-BOSCARD, you can choose from several formats such as email, PowerPoint presentations, Word documents, or a wiki page. They’re all fine. The choice depends on the project’s complexity, audience, and the need for collaborative editing or updates. These days, PowerPoint seems to be a good choice most of the time, so it would be my go-to option.
Are there specific questions to guide a Terms of Reference meeting? The Super-BOSCARD framework includes a set of guiding questions for each element of the Terms of Reference. These questions are designed to stimulate discussion and ensure that all critical aspects of the project are covered, aiding in the creation of a comprehensive and effective document.
Useful references on BOSCARD
References you might find useful:
BOSCARD article at Project Smart.
Wikipedia article on Terms of Reference.
O’Reilly publishing: introduction to OKRs (37 page free PDF)
Pingback: The Business Analyst’s Role in Ensuring Quality, and Why It Matters - Ian Howlett's Blog