Write a scoping brief for an internal business project

Start with the working problem rather than a chosen solution

A scoping brief explains the work you are preparing. It can remain concise while preventing misunderstandings that consume the team’s attention. For a Moroccan SME improving its organisation, begin with an observable difficulty: enquiries are scattered, documents are hard to retrieve or a routine task depends entirely on the owner remembering what should happen. Describe the current situation before discussing a tool.

Explain who is involved and include a recent example. Avoid opening with the name of a software product or a solution already treated as final. If you want a tracking sheet, first explain what it should make visible. The brief should leave room to consider different ways of meeting the need rather than requiring everyone to defend an early guess.

Describe a result that can be recognised in daily work

Explain what should change in the way people work. A useful result might be that every customer enquiry has an identifiable owner and a visible next action. A broad phrase such as improve communication provides little guidance. Describe what colleagues should be able to find, understand or do more easily when the project has achieved its intended result.

Add an example of the desired experience. When a customer calls, a team member should be able to find the status of the request without asking several colleagues. This makes the outcome discussable before software is selected. Check with the team that the proposed change addresses the difficulty they experience and does not simply move the same problem into another part of the business.

Record boundaries and questions that remain open

State what the project includes and what sits outside it. Improving document organisation does not necessarily involve redesigning every company process. Identify the activities and teams concerned, as well as arrangements you want to retain. Clear boundaries help prevent unrelated requests from gradually becoming part of the project merely because people are already discussing how work could improve.

Separate settled decisions from questions that need investigation. You might have chosen to retain existing tools while leaving the naming convention open. Mention practical constraints such as team availability, folders that are difficult to move or an unavailable contact. An uncertainty that is written down becomes something to investigate. An uncertainty left unspoken can interrupt work after people have already made incompatible assumptions.

Use the brief to establish a shared working agreement

Read the brief with the people who perform the affected tasks. Ask what remains unclear and what they would need before starting. Identify expected contributions: who supplies examples, who tests the proposed approach and who can confirm that the operational result is useful. The purpose is to organise collaboration rather than create a document so extensive that nobody refers to it.

Keep a dated version and record changes agreed during discussions. When the scope changes, consider its effect on the intended outcome before editing the brief. You can then use it to discuss support with Felexia and compare proposals against an understandable need. As the chosen approach becomes more precise, the original working problem should remain the reference for judging whether the project is helping.

Continue reading

• Explore Felexia management advisory
• Discuss your business organisation with Felexia