Planning a Software Project? 7 Things to Put in Your Brief Before Development Starts
Most software projects that go wrong do not fail because of the code. They struggle because nobody wrote down clearly, at the start, what the system was supposed to do, who would use it and what “finished” looks like. A good project brief fixes that. It does not need to be long or technical. It just needs to answer the right questions, so that you and your development team are building the same thing.
Whether you are planning a website, a web application or a mobile app for your organisation in Bhutan, here are seven things to put in your brief before development starts.
1. The problem you are solving
Start with the “why”, not the features. Describe the problem in plain language: paper forms that get lost, customers who cannot find information, staff re-typing the same data into several spreadsheets. When the problem is clear, a developer can often suggest a simpler solution than the one you first imagined.
2. Who will use it
List the different types of users: staff, managers, customers, partners, administrators. For each group, note what they need to do and how comfortable they are with technology. A system used mostly on mobile phones by field staff needs a very different design from one used at office desktops.
3. The must-haves and the nice-to-haves
Write your feature list in two columns. Must-haves are the things the system cannot launch without. Nice-to-haves can wait for a second phase. This one step does more than anything else to keep timelines and budgets realistic, because it lets you launch something useful sooner and improve it based on real feedback.
4. Data, existing systems and integrations
Note what data the system will store, where that data lives today and which existing systems it must talk to, such as accounting software, payment gateways, SMS or email services. Mention any data you already have in spreadsheets that will need to be moved across. Integrations are often the most time-consuming part of a project, so it is better to surface them early.
5. Security, access and privacy
Think about who should see what. Do different users need different permission levels? Does the system hold personal or financial information? How will data be backed up? Writing these expectations down at the start is far easier than adding security after the system is built.
6. Content, language and branding
Decide who will provide text, photos and documents, and whether the system needs to support Dzongkha as well as English. Share your logo, colours and any existing brand guidelines. Missing content is one of the most common reasons websites and apps launch late.
7. Life after launch
A system is never truly “done”. Plan for who will add content, manage users and handle day-to-day questions once it goes live. Ask how updates, security patches, hosting and backups will be handled, and what training your staff will need. Agreeing on this up front avoids surprises a few months later.
Keep it simple and keep it shared
Your brief can be a few pages in a shared document. What matters is that the people who will use the system help write it, and that it is reviewed with your development team before any design or coding begins. Expect it to change a little as you learn more; the point is to start from a shared understanding rather than assumptions.
Talk to eDruk about your project
eDruk Private Limited has been developing software in Bhutan since 2004, including websites, web applications and mobile apps, along with technical consultation to help organisations plan their projects. If you have an idea but are not sure where to start, we can help you shape it into a clear brief and a practical plan.
Email us at edruk@edruk.com.bt, call +975 2 332277, or visit www.edruk.com.bt.