What Your Developers Want to See in an IT Project Brief

Before you start any new IT project, you’ll need a project brief to share with your development team. A thorough brief sets out clear goals and expectations and ensures a smooth analysis — and estimate phase. With the right brief, you’ll communicate your own expectations and get an accurate figure for time and budget.

By contrast, a vague brief can leave key questions unanswered, only complicating development and extending your app’s time to market. You may also not get the features you had in mind in the end. 

So it’s vital you focus on the relevant details your team needs to do good work. A strong project brief gives a clear idea of what the product aims to achieve, key development details and scope. 

But what makes a strong project brief? Here’s what your project manager and your development team like to see. We also made a project brief template that you can download and fill out to make it even easier.

Project Description and Problem Statement

First on the list of important details to include in a project brief is a short functional project description. It also needs to set out clear project goals. You can either write out a description or show screens with a list of features. If you have wireframes already, great! Include them as well.  Business goals of each of the features are very helpful here tool. 

More detailed descriptions are better, but this is the initial stage with a vendor, after all. The specific scope can be in a brief, but not necessarily. We can clarify this later in the analysis phase. Here’s a project brief example to illustrate my point. 

Example: We’d like to build a giftcard, game card and payment card marketplace in several countries in Europe that integrates with a variety of payment providers. The platform is a place for people to buy virtual cards for games, gift cards and other prepaid cards. It often happens that you get a giftcard to a brand you don’t want — you’d rather have the cash. That’s the market we aim to serve.

Once a user buys a card, the code is sent to the email on file, so it’s important that the platform supports many payment methods including PayPal, DotPay, bitcoin and bank transfers. 

Our app would require a large e-commerce platform, especially the back end (API and integration) as well as UI/UX skills. 

If some details are too sensitive to disclose, we’ll also be happy to sign a non-disclosure agreement to discuss any proprietary details. We can sign NDAs either in person or digitally.

This overview section is also the place to let us know whether you want us to build an app from scratch or rewrite some existing code, update technology or add new features.

Additionally, a strong problem statement will help your development team grasp what gap the product fills in the market. No app exists in isolation so getting a sense of what problems the app addresses is central to a successful brief.

Target Audience

For us to get a better sense of the app, it’s a good idea to be specific about who the app is for. Age group, gender, interests, even education and income level helps us visualize the finished product. 

So let us know who your business persona is so that we can come up with the right solutions to your unique challenges. Some of the decisions this kind of information can affect are features such as colors, button placement and app complexity. 

For example, an educational app for children requires a totally different approach than an investing app for adults. Customer-facing payment apps need to be straightforward and easy to use, while logistics apps for internal use can be a bit more specialized. 

Tech Stack and Programming Tools

Next in the brief, indicate a technology stack. It’s important here to be clear about the whole tech stack and not just the main technology. A short note on your choice can be helpful to developers, especially if you want to use a technology that’s out of date. Take a look at our guides on how to choose the right tech stack for both mobile and web if you need some help with it.

We’d like to know if you’re using a technology that’s not supported so we can anticipate dependencies and threats that could arise in development. The more we know, the better we can prepare for the task ahead.  

If you don’t know what technologies to use and want the development team to propose a tech stack, say it in the brief and then ask us to elaborate. This is often a first opportunity to put the project into perspective and get some different ideas about how to pull it off successfully with your development team. If we return to our gift card marketplace platform brief, here’s another project brief example. 

Example: We would like to use a microservices-based architecture. That would entail Java EE, webshop development, microservices architectures, and front-end technologies like html/css less/sass, javascript/typescript, jQuery and Node.js.

If you have another idea about this, we’re open to discuss better solutions. You may also know of some existing components in GitHub that can speed up development.

Apart from a technology stack also add programming tools that are must-haves in the project as well as any testers you’ll need to do quality assurance. Make it clear who you expect to set these tools and the development environment up. If you want your vendor to set everything up, also put it here in the project brief. 

Developing from the ground up, or only a small part?

One crucial detail to address in a project brief is whether you want us to build an app from scratch, or you’re delegating one small part to us to build. It’s common for some clients to only need a front-end team since they already have a back-end team in-house.

Or perhaps you have an iOS app and need one for Android. Building part of an app requires a different approach and brings up different questions. For example, how our team will work with an existing development team needs answering.

Example: We would need a totally new web and mobile app. Both back-end and front-end development from scratch. 

Marking which platform you want your application on is a key question. Web or mobile? Both? iOS or Android or even a cross-platform app are important details to answer here. Web, mobile, or maybe both platforms determine further approach and project organization. 

Platform complexity, of course, can greatly increase or reduce the project estimate. So be sure to make it clear what platforms you expect. Clear requirements allow us to better gauge team expertise and availability, time to market, and budget.

Team Requirements

Project briefs that I see often focus too heavily on creating an application and not on other vital aspects of app development. Testers and project managers are also key team members to consider. 

Regardless of how many developers you need to delegate work to, don’t skimp on testers and project managers. Look at the whole development process and focus on what your development team can do to deliver the best quality product.

You may think that including testers and project managers in a brief will be too expensive. But believe me, without these key people on the team, your project will run over budget and end up being more expensive in the long run. 

It doesn’t matter if you’re only delegating an app’s front-end or back-end development. It’s always good to consider testers’ and PMs’ engagement in the project to ensure quality and that someone is watching your budget and timeline.

Other Requirements

Some projects require some exceptional features compared to ordinary project requirements. This may include exceptional business entries regarding the contract/dedicated NDA agreements or some technical requirements that your vendor needs to know but aren’t obvious at first glance such as:

• Responsive web design and unpopular screen resolutions 
• Industry-specific regulations or dependencies
• Accessibility standards like WCAG
• Non-standard devices your end-users use such as phone brands not available in Europe or the U.S.
• GDPR regulations to handle confidential data

Anything you think is a bit out of the standard is worth mentioning to your vendor to make them aware of as many details as possible.

Brief Summary

As you finalize your project brief, focus on dates and milestones that you expect your development team to meet. Generally, this should include:

• Workshop meetings and dates if needed (further analysis phase)
• A quote deadline
• Planned start date
• Expected product launch date

Conclusion

IT project briefs are the first step in getting a successful app off the ground. Writing a clear project brief will help you get straightforward and accurate proposals from your vendors. This, in turn, means you’ll get a ballpark figure for the go-to-market date as well as the overall project budget. 

More than just a list of features, a brief is also an introduction to your target market and the types of problems you hope to solve with the application. This info gives your development team the insight they need to do their best work.