You have a product, website, tool, or campaign that needs building. You need to find an agency or freelancer. Now what?

As an agency, we’ve seen our fair share of RFPs and Project Briefs from prospective clients. The variation between briefs is extensive: the information they reveal about the project and what they include has been different every. single. time. we’ve received one. Over the past 10+ years, I’ve seen and worked with everything from dozens-of-pages long RFPs to a couple sentences in an email.

While this isn’t the most engaging topic you’ll ever read about, it’s vital to hiring the right partner to build your project. The quality of a brief makes a huge difference in how any agency, studio, or freelancer will approach their recommended solution, estimate costs, compile their proposal, and present the pitch. The better the brief, the better you — 🎉 the client 🎉 — will be able to ensure that your expectations are met and that you build a successful relationship.

I’m not here to walk you through every possible element of building an RFP or how to find a good partner; those are larger topics covered extensively elsewhere. Instead, what you’ll find below is a checklist of seven vital elements to consider while creating a project brief. Each element has resulted in improving the ultimate outcome of projects I’ve been involved with over the years. Save it. Bookmark it. Put it in Pocket (do people still do that?). Reference it next time you have a brief to write.

Additionally, you’ll find a (free) template you can use for your own project briefs at the end of this article.

Key dates, especially the deadline

Do you have an upcoming presentation? Is there a drop-dead date where this project will no longer be relevant if not ready by then? Do you have a budget that expires at the end of the quarter?

This seems like it would be an obvious one, but it’s surprising how frequently this is left out because there is a soft timeline, certain dates aren’t yet confirmed, or simply because it’s overlooked.

Sometimes a project doesn’t have a hard deadline and that’s okay! Sometimes important dates aren’t yet finalized, and that’s also okay!

Even if you’re working with soft or unconfirmed dates, still include loose dates. It can be as simple as:

• Executive Presentation: October 2019
• Company Retreat: November 2019
• Conference, Booth: December 2019
• Launch: Q4 2019

While these aren’t hard dates, it does provide some goalposts to keep in mind as the project progresses; times when the team may be distracted, unavailable, or need to demonstrate progress on the project.

Even better, include any notes about what may be happening during or needed for those key dates. Including this information allows the partner to plan for and mitigate bottlenecks if and when your team is out, as well as helping you look your best 😎 when you need to present progress internally or publicly. An example:

• Executive Presentation: October 2019 Presenting to the company board. Will want to show a complete walkthrough of the app.
• Company Retreat: November 2019 Team will be unavailable for 3–4 days.
• Conference, Booth: December 2019 ~1,500 visitors for an industry conference; we’ll want to be able to demonstrate the product and it’s value to potential customers.
• Launch: Q4 2019

Key stakeholders

Who will be participating in this project and what are their roles?

In any project, there will often be several folks invested in the outcome and success of the project. While putting together a project brief, the potential partner may not know who these folks are, so including a reference of who will have some say in the project is extremely valuable.

Specifically, knowing each stakeholder’s job title and role within the project will allow the partner to understand who they should keep in mind at each phase of the project and how that might impact the timeline.

If, let’s say, a stakeholder is building the conference booth (from the example above), the partner may want to include them in the beta and plan to schedule training time in advance of the event. If you have a VP that is providing feedback during the design phases, the partner may want to be sure they’re available for a regularly-scheduled check-in time.

The best way to present this information is in a simple table, like this:

Goals, not features

Talk about the goal of the project, not just what you want it to do.

At the heart of every project is a purpose: the goal that you, or your team, is ultimately trying to achieve. Goals may include decreasing customer churn, increasing internal team efficiency, improving mobile user experience, or any array of many other possibilities.

By providing this insight, your potential partners may identify a goal you had not considered or an approach you didn’t even know was possible. Ultimately, there may be better, cheaper, faster, or even more valuable ways to solve for these newfound goals. You’re looking to find a partner with expertise; take advantage of what they can offer!

Context, context, context

How does this project fit into the organization’s needs, marketing goals, etc? What are the initiating factors?

In addition to providing insight into the goals of the project, an often overlooked aspect of a brief is the context. Why are you pursuing this project now and how does it fit into the larger [quarterly, yearly, short-term, long-term] goals that you, your team, or your company are trying to achieve?

This doesn’t mean you need to reveal long-term strategy or closely-held plans, but the more context you can provide, the better. A good partner will be able to empathize with the level of urgency or stress, or provide the right information over the course of the project to feed into the larger strategy.

Success factors

What will make this project a success?

This is definitely an “optional” element, as not all projects have clear measures of success (note: if yours doesn’t, it’s worth looking more closely at why), but aligning with your partner at the outset of the project on what success looks like will benefit the entire project and all teams involved.

Often, success factors can be an extension of the project goals: are you trying to decrease churn by 15%? Increase onsite time by at least 10%? Improve app usage on iOS by 25% while decreasing the crash rate by 5%? Any of these qualify as measures of success.

As a note here, payment typically should not be contingent on success being met unless your partner works under model or applies a “Fees at Risk” model. The reason here being that the work is still being done and, often, factors of success may be out of the hands of the partner; payment contingency implies that the partner is solely responsible for success.

Target audience

Who will be using the product, seeing the end results, or interacting with the experience? Who do we need to impress?

Often, there are two audiences you’re going to be working for throughout the course of a project.

The first is the most important: the ‘end user’; the individuals that will be seeing/using/touching/feeling/experiencing the output of this project. It’s a good idea to have a picture in your mind — and in the brief — of who this person is, how old they are, and their “backstory.” While a good partner will help you round out the details, consider the high-level details that will go into a user persona.

The second audience is either an internal audience of your peers or superiors, or an audience of industry peers. Who within the organization or industry do you want to help or impress? While this may not factor into the product itself, a good partner will help you identify the obstacles this audience may present and wants to make you look good too — it’s not just about doing the project well.

Technology requirements and limitations

Existing infrastructure we need to work within? Someone we should talk to before suggesting any technical solutions?

All too often, we hear questions like the following after putting together a proposal:

“We were hoping to see a solution that uses X.”



“Our systems use Y internally; will the technology in your proposal support that?”

These questions often mean we’ll lose a project because we didn’t take into consideration the tools or technology limitations you or your organization has in place — even if we were fully capable — simply because they weren’t mentioned upfront.

If you want all partners presenting their best solutions that also work with existing infrastructure, start on an even playing field by including any technology limitations or requirements you or your organization have at the outset. When this information isn’t included, don’t be surprised to receive proposals that don’t align with your organization’s needs. This may mean coordinating with your IT or internal technology teams before distributing the brief, so take into consideration any extra time necessary.

Above are just seven elements that you should consider when writing a project brief as part of an RFP or reaching out to a potential vendor for a software-based project. It is by no means a completely comprehensive list of elements.

However, we have also compiled these recommendations into a template document that you can use for your next project brief! The template includes sections for all of the above, nicely formatted and readily readable, as well as sections for additional information you may want to include. As a Google Doc, it’s print and PDF-ready, easily copied and used, or modified for your own needs.

You can get the Project Brief Template here: