How to write a Project Brief that truly works for everyone

How to write a Project Brief that truly works for everyone

Running a mobile software agency is not an easy-peasy thing. Quite often I come across clients approaching us with questions like:

I want to create a copy of Uber with a slightly different social network idea and higher focus on users’ interaction. Any idea how much it may cost?


My idea is similar to Instagram but with major focus on fashion and sharing how you look like with others. I’d like to know how long it may take to create it and how much it costs.

Obviously, these are extreme cases of project briefs that really do not tell a lot and are virtually impossible to estimate but I quite often encounter a situation when huge effort is spent both on Client’s and our side to really determine what the project is about and, more importantly, why are the major reasons behind its existence.

That is why I’d share the characteristics of what we perceive to be a truly informative brief that is easy to work with both from Client’s and developer’s perspective. Here it is in five steps:


Step one: basic project information


It is important that you immediately put the developer in the proper context and provide valuable logistics data.

  • What is the desired start date and release date?
  • Which platforms / systems do you want to support (in the mobile software it mostly is: iOS, Android, WP)?
  • Do you have any internal resources (backend developers, designers, testers, etc.) available in-house or do you want to have the end-to-end solution?
  • Do you want to work in a Fixed Price mode (project is well specified, relatively short and easy to implement and you do not expect much changes in scope) or Time and Materials (project is not fully specified, it requires Agile approach, you expect potential changes in scope)

Answering such questions already helps to determine whether the company you’re trying to choose is capable of doing the job and has enough resources in the set time to make it happen.


Step two: project business value / strategic goals


You need to specify the value proposition you have for the users that, ideally, should be represented in each quantifiable element of your system (i.e. app screen).

You can do that by answering the following questions:

  • What is your product’s right to exist?
  • What kind of remedy / solution does it provide to users’ identified pain / need?
  • Who would care most if your product vanished overnight?
  • Who could replace your product the easiest and fastest way?

Thinking in values is one of the key success factors of each project and product. You need to make the developer aware of the fundamentals of your business model and the key rationale behind your product’s existence. It brings two immediate benefits for you:

  • You give the developer the whole picture of your product, not just the technical scope. Now they can truly play an active part in the process and provide proper technical advice basing on complete project characteristics
  • Approaching the developer with your brief may be one of the first chances for you to get out of the building with your idea. Good development agencies should be capable of challenging your concept and advising you of reaching Minimal Viable Product (MVP) in an optimal way

Watching how developer responds to this part of the brief is usually a great indicator helping you choose the best company to do the job. Some companies may skip this part and concentrate on the technical scope only, some may point to the similar projects they did in the past, the best ones should ask some clarifying questions to make sure they understand and like your business concept and work on the technical scope only once this part make both parties feel like they are on the same page.


Step three: target group and personas


The best way to determine the target group is to think in personas. Persona represents the archetype of different kind of users that constitute the target group.

Here is how you can describe personas:

John Smith, aged… , who is (occupation, social status, any other differentiating factor)

– Problem: He would like to learn to cook but is tired of looking for the best book with recipes

– Solution: He opens the app and is being given personalized info about the best cooking techniques and recipes and he becomes part of a larger community of likeminded people

– Result: He is able to learn to bake much faster, his motivation increases as he shares his progress with other people

Mary Brown, aged… (different problems, different solutions, different outcome).

Understanding who will actually use your product greately helps your developer make appropriate decisions during the course of development. It is far easier to choose appropriate architecture for the project and make other strategic technical decisions once your developer is able to put themselves in your users’ shoes.


Step four: functional scope / user stories


You need to describe the functionalities you want to provide for users in your product. The best way is to form a set of user stories. User story is explaining a piece of functionality to be delivered in a form of a sentence with the following structure:

As a [role], I want to [goal], plus an accompanying detailed description and/or business value


As a user, I want to search for my customers by their first and last names.

Defining the project scope in user stores really helps most developers a lot. Good companies can easily make the most of it and provide appropriate estimate or at least ask the right clarifying questions. User stories are Agile-friendly so if you opt for this way of development the project will be immediately easier to set-up.


Step five: prioritization of functionalities


You need to point out which functions are nice to have and which are must have. To be absolutely sure that your product brings the most value in a set time, you need to work on the most important things first.

You can also use MoSCoW matrix to help you prioritize in much more meaningful way.

MoSCoW stands for:

M – Must

S – Should

C – Could

W – Won’t / Would

With the help of the following pointers, it is easy to categorize the requirements in any of these four categories.

Must – These functionalities that MUST be developed to consider the successful delivery of a project.

All requirements listed as a MUST will have the highest priority and will be done before starting the next set of items, labeled as ‘Should’.

Should – These are also highly important tasks that will be delivered only if it can be done. Not including the Should items in delivery may hinder the project but will not stop it altogether.

Could – These are requirements which will be developed only if time and resources permit. Including the Could items in the delivery is not mandatory at all, but is suggested if the company can afford it and the Must and Should items are already there.

Won’t / Would – These are functionalities which will not be implemented in the current release and may be considered in the next release. These items are not necessarily low-priority items, but merely ones, which are not to be implemented in the current context.

Setting the priorities helps your developer understand your immediate and long-term goals and provide appropriate solution that, ideally, should contribute to product’s present and future well-being.


Naturally, a truly informative brief can and should include more information. However, working with the steps above should make it easier for you to get a truly realistic quote and choose the appropriate developer. What is equally important, it can also help to challenge your project idea in an unbiased way.