Manage Expectations with a “Terms of Reference” Document

As consulting business analysts and architects, we at Systems Flow are constantly in the trenches with our clients, helping envision & manage the change to their technology and business processes they need to be competitive and succeed.

Although we have formal processes & deliverables we rely on to deliver on our commitments to clients, it’s not always obvious to a project manager, business change sponsor or technical executive what those deliverables are, and how we use them. That’s where a clear, concise Terms of Reference (ToR) document comes in handy.

The ToR is a standard project management artifact, sometimes labeled the “project charter” when the scope of the ToR is the project as a whole. It is also frequently used by consultants to clearly specify terms of an engagement with a client, whether that engagement is itself a project as defined by the client, or just a time-bound piece of work with a specific goal. So, since Systems Flow is typically engaged to work on client projects, the ToR is a natural fit for us.

Key aspects of a useful ToR:

• Extremely brief – a single page “powerpoint” deck forces clarity and economy of words, and is the right size for the sort of “pre-deliverable” deliverable that the ToR is (i.e. a deliverable to describe the scope of your other deliverables)
• A “living” document that can be changed – Like any scope document, the ToR needs to be maintained, and work managed against. Use it as a tool to continually communicate with your stakeholders & sponsors about the expectations you have of each other

Key things to include in a ToR:

• Background & Objectives – summarize (avoid copy/paste) a few bullets about “state of the state”, “why we’re here”, and “what we hope to accomplish”. Always aim this at the Terms of Reference for your engagement on the project/effort. E.g. don’t summarize the business background and objective of an entire project, but focus on the background that led to you being asked to engage, and the objective of your engagement.
• Scope – a few very simple bullets about the scope of the engagement. Bubble it up to the level of what service you’ll be offering – e.g. “Logical System Design”, “Requirements elicitation”, “Technology estimation”.
• Method – Don’t try to boil down your entire process here, but describe in a few bullets the sequence of events that will drive you to the end of your engagement.
• Assumptions & Dependencies – standard project management stuff, but again don’t be “standard”. No one needs to see in your ToR the type of mind-numbing and un-actionable assumptions or dependencies found in most project management artifacts – things such as “We assume the sun will rise, then will set”. Instead higlight things such as “Deliverables will be drafted, reviewed and delivered sequentially, in the order listed, before proceeding to the next”, where you think it’s important to emphasize the sequential dependency of your deliverables to a project manager who will want to assume that they can push you to complete them in parallel.
• Deliverables – the most important things are what tangible assets you are committing to deliver. Systems Flow recommends sticking to formal artifacts – the fewer and more concise the better.
• Cost, Time, Key Roles – If appropriate, include the cost & time to deliver, as well as the named individuals engaged and their roles in the engagement.

Use the ToR even if you’re not a consultant. It helps ground the work you do, sets clear expectations, and covers your rear end!

Email us for a sample and template ToR.

Comments