90 Percent

Project management, productivity, change management, and more!


Leave a comment

5 tips to give great project briefs

Briefing your team on the new project is a very important step and one that will give your team a good/bad first  impression on how things are going to go until the closure of the project.

Recently, I wrote about a few examples on how to give a very bad first impression ( and headaches) by giving very bad project briefs, now let’s concentrate on how great ones are given:

1. Think of it as a story

A colleague of mine gave me this great tip and I couldn’t agree more! A story is built so that anyone can jump in and understand what is going on by reading it; the same should apply to your project brief.

Setting

Describe the context of the project so that anyone can understand what they will be working with. In other words, describe  the current situation and summarize why things are as they are.

For example: a website has been build 8 years ago, back when  responsive design did not exist, and no CMS could be afforded. Today technology has evolved and CMS are more affordable with open-source platforms.

Conflict

What is the issue or what causes this project to exist all of a sudden? If we use our website example, then the issue could be that the website is not mobile friendly and the client cannot make any simple modifications without the need for a developer.

This creates the need, and gives birth to the project just like it would with a story.

Plot

Explain what will happen so that the project can be completed. In other words, list deliverables and what’s expected for each. For example: the team will deliver a concept idea for a new contest, than layouts of the contest, and then the team will develop it.

Characters

Talk about all stakeholders (team, client, third-parties, etc.) and everyone does.

2. List clear, measurable objectives

The objective of the project will guide the team towards the right path. If one of the objectives is to “create brand awareness” then the social media campaign they build will differ from a campaign that used to gather emails to send future promotions.

Make sure the objectives are measurable, if they are not, then they will be open to interpretation and you will not be able to assess properly if they are met or not. A good example of measurable would be “Gather 5000 new fans on the Facebook page” versus “Gather new fans…”.

3. Make sure it’s clear who does what

Here you want to make sure to explain what the team will be doing; is it a website? social media campaign? Mobile app? Is it more than one thing?

Within this, list what needs to be done is not implied/guessed; list it clearly.

Keep in mind that third-parties or clients are also stakeholders that have responsibilities within the project and listing their responsibilities is important to the team; both to make them understand the full context and also to know who to talk to during the project.

4. Answer all questions

The team will ask questions when they are briefed, that’s practically inevitable; you have to make sure all questions are answered. If you cannot answer right away, list all questions  so that you can speak to who you have to in order to get the answers as quick as possible.

If you do not answer your team’s questions, how can you expect them to deliver what is needed?

5. Keep it simple to read

Just like every document you create, if it’s too long and hard to read and nobody uses it, then even if all important information is available, the goal of the document will be skipped. Makes sure it’s well formated including proper titles, use lists, you can even highlight key information, and keep sentences as short as possible.

In conclusion

How a project starts gives a good idea of how the project itself will be throughout it’s life-cycle which is why it’s important to give good project briefs so that the team can be confident the project will go well. This will not only make sure they know what they are expected to do, but also it will motivate them to deliver.

 

If you have more tips, don’t hesitate to share below!


Leave a comment

How to give bad project briefs

Briefing the team to start a project is an important step contributing to the project’s success. How the brief is handled can be very indicative of how the project will
go.

However, even if it is very important, some remain unaware of the impact it has on the team to have an unacceptable project brief.

Here are below a few examples of bad project briefs. If you are guilty of anything similar to this, please review how you brief your team, I know you can do better than this. 🙂

1. The “Pass-by” brief

Situation:

  • You happen to pass by the person you need to brief on the project;
  • You stop him in the middle of the corridor and start briefing him on the project right here, right now; and
  • You give him a very high detail description like “It’s a mobile app”.

Result:

  • The brief takes 5-10 minutes;
  • No notes were taken;
  • No next actions were listed nor discussed;
  • The proper team members were not included; and
  • The person being briefed doesn’t necessarily have time for this today and now is stuck with a “surprise” new project he was not aware of.

2. The “Catch it” brief

Situation:

  • You go speak to the person and tell him a project is starting for a client and he should take care of it; and
  • You leave saying you don’t have more information for him…

Result:

  • The person is left completely clueless as to what to do; and
  • He knows he can’t ask questions since you have no more information.

3. The “high…very high level” brief

Situation:

  • You need to have an estimate done for a project;
  • You brief the person who will handle the estimate by informing him that you need an estimate for a “A micro-site”;
  • The person asks for more information; and
  • You answer… “Well it’s a micro-site!”

Result:

  • The person has no idea what to estimate and is frustrated by the lack of information.

4. The “New service” brief

  • You need to have an estimate done for a project;
  • You brief the person who will handle the estimate by informing him that you need to estimate a “Parade Float”; and
  • The person replies by saying “We do web here…” (which is true)

Result:

  • The person has no idea what to estimate; and
  • The person feels confusion around the new “service” we suddenly offer.

5. The “Client approval forward” brief

Situation:

  • You work hard to win a new client, not involving the team in any steps;
  • After much effort to win this new client, he decides to go forward with the project and sends his written approval in a mail;
  • You forward the approval mail to the team asking to start the project;
  • That’s it…

Result:

  • The team has no idea what is going on;
  • They are also discouraged by the “project brief” they just received.

6. The “When can it be done” brief

Situation:

  • You are in a meeting with a client who just agreed to have his websites done by your team;
  • Happy, you fetch the person responsible for production to meet the client;
  • Knowing he is completely clueless of the websites, you ask your colleague: “When can his websites be done?” while the client remains there, smiling, eager to know the answer.

Result:

  • Your colleague is put in a bad position where he is surprised, cannot answer, and must stay professional in front of the client; and
  • Gives a bad impression to client to see how his project started.

7. The “Client wants something else” brief

Situation:

  • Client gives you detailed information of what he needs;
  • You feel the client needs something else than what he his requesting; and
  • You brief the team according to what you think the client needs, and you do not share the original information the client provided to you.

Result:

  • The team is never able to satisfy the client, no matter how hard they try;
  • They are confused by the difference between what the client feedback says and what you say; and
  • Not only frustration build up, but so much time (and money) is wasted because of this.

In conclusion

Project briefs are the first impression of a project to your team, make sure it’s done right. Not only that, can you imagine if the clients knew how bad their project was transferred to the team? They would not feel confident the team could handle it, and they would be right.

Have you ever received a bad project brief? Share your story!