• How to Deliver the Perfect Tech Project Brief

History is littered with technology project failures. Take Phoenix, a Canadian payroll system introduced in 2011 that was supposed to keep cash flowing for federal employees but could now cost taxpayers up to $2.2bn to fix. Or the UK Post Office's Horizon IT system, which miscalculated accounting so badly that UK postal workers were wrongly accused of stealing money and sent to jail.

Technology projects like these become so large, complex, and poorly managed that nothing can save them. The chances are that your tech project is smaller and easier to steer, especially if you set it up properly from the beginning with a solid project brief. By specifying expectations at the outset, you stand a better chance of keeping suppliers on track and holding them accountable if things go off the rails.

Many IT support supplier briefs begin with a request for proposal (RFP). This invites the vendor to suggest a solution to a broad business challenge. At this stage, you're looking at business outcomes rather than specifying the exact system that you want. This leaves room for the vendor to come up with creative approaches to solving your problem.

Once you've scoped the project and decided on an approach, you can brief the technology provider. There are many different templates for project briefs, but here are some possible sections and things to consider:

Key requirements

This is your high-level vision for the project. Beyond a simple description of what you want, outline what you expect it to achieve, such as cutting your response time to customer queries or saving support costs.

When writing this, ensure that you review your existing solution and suppliers to figure out what needs improvement. Use your gripes about your current system to guide what you're hoping for from the new project. People dealing directly with the existing system or service can provide some insight into what isn't working.

Stakeholders

List who's involved in this project, along with their roles and responsibilities. This should serve as a reference document later during the project management phase. Every part of the project should have an owner.

This is the time to clearly divide responsibilities between in-house staff and the vendor or service provider. Get this right now to avoid critical tasks falling through the cracks later.

Statement of work

This section lists the detailed components for the service or product involved. What exactly will the company deliver? Detail is critical here so that there are no misunderstandings or assumptions about what will be delivered.

Timelines

Break down your project into critical phases such as requirements gathering, design, prototypes, project testing, and go-live dates.

To write this section, you must understand the development and deployment methodology. Will this be an agile project, delivered iteratively in two-week sprints, or a more traditional waterfall-style affair?

Include firm start and end dates for each phase of the project, and assign people from the stakeholders section to each one. What must they deliver for the project to be a success? Protect yourself by including contingencies or penalties for late delivery.

A well-written timeline and statement of work can be the basis for an effective project management Gannt chart.

Critical success factors

Here's where you list your success criteria. What would make a successful project? The more specific this section can be, the better. Create quantifiable metrics linked to your goals. Examples could include cost and time savings, but the exact metrics will depend on the nature of the project.

Ongoing contract management

This is a piece of a mature project brief that companies often overlook, yet it's crucial to the plot. Defining the parameters of the working relationship will help suppliers know if the contract is something they can support to your standards during the ongoing servicing phase.

When compiling this section, consider elements like maintaining service reliability and quality through a service level agreement (SLA). What are the baseline metrics, such as system uptime rates or average service response times? What responsibility does the service provider have to report on these and other aspects of the service? How will things escalate when problems occur? What penalties will the supplier incur?

Now is the time to specify cost management principles. Under what circumstances can a provider charge more for a service?

Don't forget to include procedures for managing the relationship here. Avoid falling into a 'fire and forget' relationship where you stop talking to contractors. Build in provisions for regular meetings where you evaluate contract performance and look for ways to enhance it.

Every extra minute you spend articulating these things now could save you days of troubleshooting further down the line.