Tips for a Great Project Brief

Strategy Paper

One of the most important points is that you need to be clear about what you plan to achieve. A strategy paper is neither a comprehensive document, nor the outcome of a business requirement analysis. It aims to outline your strategy, not the requirements. When writing a strategy paper, you should focus on measurable achievements: what will you try to achieve with the new system? When do you want to achieve it? Try to prioritise these points and think about an MVP (minimal viable product). What achievements are required as a minimum to classify the product build as “successful”? What can be delivered in later stages, and which features are simply “nice to have”, but not mandatory? Keep the strategy paper short, and involve all those in your organisation who have a stake in the outcomes in the creation, review and approval of the document. Do not make the mistake of mixing up this strategy paper with a business requirements document. The strategy paper is about the strategy, not the requirements. It lists what you try to achieve in the mid and long term; it does not list what is required to achieve this, and neither does it provide answers as to how the problem should, or will, be solved.

A technical specification is a must-have before development commences. That said, designing a solution that meets your requirements should be the responsibility of the developer — and this includes specifying the technical solution.

Our advice when you plan your project with a development agency is this: if their project plan does not contain a proper technical specification phase, find someone else! The development of software without a clear specification is like building a house without a construction plan.

These days, you don’t build one monolithic beast of a solution that does everything. Systems are highly optimised for a specific purpose. You can easily have one system that powers your public website, another system that stores and manages your product data in a central place, and a third system that generates reports. They all communicate with each other and share data; this is called system integration. We often build solutions for clients which smoothly integrate into their business workflow. Our custom-developed systems access product data from one system, use single sign-on (SSO) to authenticate users, and push data to a customer relationship management system (CRM) for reporting.

In most cases, it is beneficial to identify which existing components need to be replaced, and which systems should remain in place – perhaps because they fulfil their purpose and they provide a suitable interface to exchange data. This also applies to new systems (or newly custom developed solutions). Without a modern and secure method to integrate with other systems, they can cause problems in the long run. We often see this with proprietary software: if vendors of closed systems do not offer interfaces that allow developers to integrate with their software, users are locked-in and are unable to exchange data between applications. This is in contrast to open-source software, where developers can review the source code of the software, customise and extend it as required, and even suggest changes to the original developers.

The questions you should ask when you’re planning your next project include:

• What systems and solutions already exist in your environment?

• Which of these systems provide data that needs to be “consumed” by the new application?

• Which systems require data that is generated?

If developers face the task of integrating with existing systems, they require details about the interfaces of these systems (e.g. the type and technology used for the interfaces). For example, what formats can be used to exchange data, and how are the endpoints secured (the authentication method, etc.)? This brings us neatly to the next section.

Any existing documents, outcomes of a requirements analysis, technical specifications etc., help developers understand your situation, your IT environment and the systems that are already in place.

If the new software aims to replace an existing system, manuals for the application are essential to understand its purpose, and how users are currently operating the system. If you aim for an integration with other systems, a technical specification that describes the interfaces (also called API — application program interface) is crucial. If you don’t have these documents on file, contact their vendor or the service provider who set up the system for you.

Desktop and web-based systems feature a UI (user interface). In most cases, you want the visual appearance of these interfaces to reflect your corporate identity and brand. Sometimes this is less important if your end-users are internal staff and are only very limited, but as soon as the system is publicly accessible and accessed by your clients and partners, its appearance should use specific colours, font types, images and your company logo, to name just a few elements. Your organisation may have a style guide and/or a brand guide, documenting the requirements for the visual appearance in detail.

Once built, tested and approved, the new system needs to be deployed somewhere, whether the application will be hosted by your own IT department (this is called internally hosted) or by an external entity. The latter has some benefits: the agency who built the site usually knows the framework inside-out, as well as the exact requirements and best setup for the hosting environment.

They can set up an infrastructure which is tailored to your needs, scalable, highly available, and often integrated with their deployment workflows, which makes maintenance updates straightforward.

However, under certain circumstances you’ll want to host the new system yourself. In this case, you should make sure that your IT staff have the knowledge and resources to maintain the software (e.g. monitoring and deploying security updates as required), and can meet its requirements. Alternatively, you can turn it around, and define the hosting environment as a requirement that the software must meet. However, this approach may limit the number of potential solutions.

Further preparations, or issues which you can clarify before engaging with a digital agency, include the domain name and TLS certificate. A domain name is, of course, a must-have if you plan to build a website or web application. Do you need to register a new domain? Who takes care of purchasing a TLS certificate that provides HTTPS for the system, and what type of certificate is required?