Why putting time and effort into a good project briefing document can pay dividends in your search for a Software Engineering partner and what you need to include to make it powerful.
AVAMAE have been working with start-ups for over ten years. There’s nothing our Project Acquisition team love more than talking to new leads and hearing about their exciting new ideas for custom app and software development. We’re well versed in asking the right questions and getting to heart of what you need and how we can help.
But there is one thing that makes these discussions easier and clearer, helps avoid confusion and mis-understanding and allows us to delve deeper, quicker, and that’s a good project brief.
Not only will creating a project brief focus your mind on what is important, and no doubt facilitate important discussion between those on your team, but it also means that you have one document that you can provide to multiple agencies, both saving you time and ensuring clarity of message.
As a custom software developer, working on a huge variety of custom software projects across multiple sectors, we’re often asked what kind of information we need, and how that information is best delivered, to enable us to come up with an accurate proposal and quote for a new piece of work. So in this blog, we will take you through everything we believe you need to include in your project brief to make it effective.
A project brief doesn’t need to be long or full of granular detail, in fact clear, well laid out, concise and to the point is more helpful. Even though the document needn’t be long, you do need to take time to really think about what you are saying and consult with others around you. First of all, consider including all, or most of, the following summary information, which will provide a compelling overview and allow the reader to really understand what you are trying to do:
The Elevator Pitch – Try and summarise in a concise way what your idea is, explain what problem you are trying to solve or gap you have spotted that you are looking to fill.
Company or Founder Summary – Who are the people or company behind the idea and what is your current positioning? Maybe you’re a start-up with a brand new idea, or perhaps you’re already a player in the market looking to launch an additional product.
Competitors and Market Summary – Think about what kind of market you are launching into and who the other key players are. You might want to mention competitors with similar products and any points of distinction between you.
Target Audience – Next, think about the target audience. This might be a specific demographic, or a wider audience. Is it a B2B product or B2C, and what about location, are you targeting UK based users, or is the audience an international one?
Platform – Do you know what kind of platform is right for your product? Do you want to create a native mobile app, or maybe a web app will work better for your needs. We’ll be able to offer advice on this, but if you have a clear idea, write it down.
Budget and Timeline – These aren’t essential and maybe you don’t want to share this information, but this can be a key indicator when talking to a custom software developer of whether you might be a good fit for each other.
You also need to think about, and make clear, whether you want to launch as an MVP. We always recommend that our clients start out by developing a lean product and talk more about why this is important in our earlier blog on Minimum Viable Product Development here.
Once you’ve thought about all that, it’s time to turn your attention to your expected users. It’s really helpful to break functionality down by user type. For example, your product might be a SaaS property management platform that you sell to clients, who in turn add their customers, who can then login to see personalised information. In this case, your users are going to be the Property Management companies as clients, their tenants as customers and your own company as administrators. So you need to think about three distinct user types.
Ideally by this point you would have done some initial idea validation and hopefully built user or potential customer personas based on your research findings. If you haven’t, feel free to get in touch with us to learn more about this, but if you have, you can draw on these to think about the different user types and all the key things they should be able to do in their role. It’s important that once you have a list of functionality requirements, you think about them in terms of what is essential (MVP), what would be nice to have and what would be dream functionality. List it out, by user type and ideally in bulleted lists, and make it clear which category each requirement falls into.
Try not to get too sucked into finer detail at this stage, think about summarising functionality at an appropriate level. For example, you might want to specify that clients should be able to invoice their customers through the platform, but you don’t need to go into detail of everything that this might entail, such as being able to search for customers, view their records and payment history, receive invoice notification reminders, create and check invoices and send them out.
Don’t forget to think about the administrative functions of the platform. Even if you’re hoping to make your SaaS product fully self-service, you will still need a level of administrative control. Do you want to have oversight of clients and their customers and be able to manage their accounts? Do you want to be able to export payment reports and access data about the number of sign-ups and users over time?
Next you might want to think about if there are any integrations that are key to your project. Of course, we’re here to help and advise on this sort of thing, and things like payment gateways are a standard addition to many projects, but is there some specific data you’re going to need, such as live or historical data related to a particular product or commodity, and if so, do you know where you are going to get it from?
It’s not essential, but if you have any images you want to include, from wireframes, to example screenshots and hand drawn sketches, add those too, as it can be a great help to see what it is you’re visualising.
If you’ve thought about and covered everything above, then the chances are you’ve put together a really strong project briefing document, that is going to act as a great resource, not only for any one that you are looking to partner with, but also for your internal teams.
Understandably, you might be unsure about sharing the private details of your idea externally, which is why we always suggest signing an NDA before we talk details. Make sure that anyone else you are talking to is happy to do the same.
At AVAMAE, when you come to us with an idea, we always have a deep discovery meeting with you before presenting you with any quotes or proposals. Having an effective project brief to hand when we do this gives us a great starting point and allows us to really delve into your idea and your strategy and suggest solutions, rather than spend time on teasing out the basics.
If you want us to go ahead and come up with a costed proposal for you, then a good project briefing document, along with our conversations with you, enable us to do that effectively.
If you’ve got a project that you want to talk to us about, or if you need any more advice on what to include in your project brief, call us on +44 (0) 20 3855 0690 or fill out our website form here and we’ll get back to you.
