briefDev.jpg


brief.jpg



A brief is a clear description of both the desirable outcomes sought and the constraints to be met by a successful technological solution. A brief commences with a conceptual statement of the need, issues or opportunity being addressed, but also contains the detailed specifications against which the success or otherwise of the solution can be tested. Ideally, the brief is fully researched and defined in advance of development of the technological solution, but often, as the development work precedes the knowledge and understanding of the technologist improves sufficiently that refinements (usually improvements) are made to the brief and its specifications.

In some instances where the scope of the development work to be carried out can be reasonably predicted the brief may also consider the work environment and any resource constraints within it.

Thus, the elements of a brief are:
  1. a broadly-based conceptual statement identifying the need, issues or opportunity (including relevant technical, social, cultural, political, environmental, economic and value-driven aspects) which the technological solution will address;
  2. specification of the performance(s) required from the technological solution including both attributes regarded as essential, and those regarded as non-essential but desirable (performance might be expressed as a combination of technical, economic, environmental and social outcomes, but each specification must be stated in measurable form);
  3. specification of constraints to be met by the technological solution including both those regarded as compulsory, and those regarded as non-essential, but desirable (constraints might be expressed as a combination of technical, economic, environmental, cultural and social limitations, but each constraint must be stated in a measurable form);
  4. statement of resources (such as time, expertise, materials and finance) that are available to the technologist during development of the technological solution.

In preparation of the brief the following steps are usually required:
  1. identification of and consultation with stakeholders (those potentially affected, whether directly or indirectly, and whether positively or negatively - by one or more of the problems to be solved, or by some aspect of the desired solution itself, or by the development process). Synthesis of statements expressing stakeholder values, beliefs, ethics, social position, concerns, and needs, but also stating the opportunities that may be present in relation to the issue(s) to be resolved;
  2. identification of all legal, regulatory, social, cultural, political, environmental and economic aspects that must be considered including legislation, standards, codes of practice, codes of ethics, global and future trends and the culture of technological innovation;
  3. identification of surrounding systems with which the technological solution must interface and the knowledge bases associated with these.

In performing these steps, the technologist has identified the key factors and their implications for their work in providing a successful technological solution to the brief.
A brief is a guiding document
  1. It has a conceptual statement, that explains what is to be done and why it should be done
  2. It has attributes that lead to specifications that describe the physical and functional needs of an outcome that addresses the issue (and the practices that need to be followed when developing it)
  3. A brief is based on findings from your exploration of the issue, analysis of the context and the need/opportunity driving the project
  4. A brief takes into account physical and social environment where the technological outcome will be placed
  5. It must state what or whom the outcome is for
  6. An initial brief must give sufficient scope for a wide variety of possible design outcomes to be explored.
  7. A brief is not a one-off exercise, for it is developed and refined/modified through undertaking technological practice when developing an outcome.
  8. Modifications are often when attributes become confirmed specification