Introduction
Preparing a project brief before contacting More Grow Group Fiji helps your organisation explain what it needs, where the work will happen and what a successful outcome should look like.
A request such as “we need medical equipment,” “please upgrade our IT” or “we want solar” provides a starting point, but leaves important questions unanswered. A service provider needs more context to assess the requirement and prepare a useful proposal.
For businesses, healthcare facilities and other organisations in Fiji, site access, existing infrastructure, operational schedules and ongoing support can all influence the proposed work.
A clear brief brings these details together. It does not need to contain a complete technical design. Its purpose is to explain the problem, define priorities and identify questions that need further assessment.
1. Start With the Problem You Need to Solve
Describe the current situation before naming the equipment or solution you want.
For example, “staff cannot reliably access shared files between departments” explains an operational problem more clearly than “install a new server.”
Similarly, a facility requesting biomedical support should explain whether the issue concerns a new service, unreliable equipment, missing records or planned maintenance.
Useful Questions to Answer
- What is happening now?
• Who is affected?
• How frequently does the problem occur?
• What impact does it have on operations?
• What has already been tried?
• Why is the project needed now?
• What would improve if the project succeeds?
Separate observed facts from assumptions. If the cause is unknown, state that an assessment is required.
2. Identify the Organisation and Project Contacts
Provide enough information for the service provider to understand the organisation and communicate with the right people.
Include:
- Organisation name.
• Type of facility or business.
• Project title.
• Main contact person.
• Contact details.
• Site representative.
• Technical contact, where available.
• Person responsible for purchasing approval.
• Person authorised to accept completed work.
One person may hold several roles, but the responsibilities should remain clear.
For projects involving several departments, nominate a coordinator to collect feedback and resolve conflicting instructions.
3. Describe the Site and Access Arrangements
State exactly where the work will take place.
A proposal for one accessible office can differ from a project involving several facilities or additional inter-island transport.
Site Details to Include
- Site address and relevant building or department.
• Number of locations involved.
• Normal operating hours.
• Available access times.
• Visitor and security procedures.
• Delivery and unloading arrangements.
• Parking or loading restrictions.
• Stairs, lifts and equipment access limitations.
• Relevant photographs or existing drawings.
Identify whether site visits require advance booking or coordination with other staff.
Avoid assuming that delivery to the site entrance includes movement to the final installation location.
4. Define the Outcomes You Want
Describe what the completed project should enable your organisation to do.
Outcomes should be specific enough to guide the proposal without prescribing an unverified solution.
Examples include:
| Service area | Example outcome |
| Biomedical | Establish documented maintenance arrangements for an identified equipment list |
| IT | Provide authorised staff with reliable access to shared business systems |
| Solar | Assess a system intended to offset part of the site’s daytime electricity use |
| Combined project | Coordinate equipment, network and power requirements for a new facility |
These are starting points. The provider should help translate the agreed outcomes into an appropriate technical scope.
5. Separate Essential Requirements From Preferences
Not every requested feature has the same importance.
Divide the brief into:
- Essential requirements.
• Preferred features.
• Optional additions.
• Items requiring professional assessment.
For example, completing work outside clinical operating hours may be essential, while a particular equipment colour may be a preference.
This distinction helps suppliers explain trade-offs when budget, availability or site conditions limit the options.
Ask suppliers to identify any essential requirement they cannot meet.
6. Prepare the Biomedical Section Around Intended Use
For biomedical projects, describe the equipment, service requirement and operating context.
Relevant facility staff should confirm clinical requirements, while appropriately qualified technical personnel assess equipment and infrastructure needs.
Information to Include
- Facility type and department.
• Equipment category.
• Intended use.
• Existing manufacturer, model and serial number, where relevant.
• Quantity of equipment.
• Reported faults or service concerns.
• Current maintenance records.
• Manufacturer documentation, if available.
• Accessories and compatibility requirements.
• Training and support expectations.
Clarify whether the request concerns:
- New equipment supply.
• Installation.
• Inspection or fault assessment.
• Preventive maintenance.
• Repair.
• Calibration where applicable.
• Equipment inventory or service planning.
Do not treat these activities as interchangeable. Ask the provider to explain which services are relevant and included in the proposal.
Describe Operational Constraints
Explain when equipment is available for assessment and how downtime will be managed.
State whether the facility needs staged work, coordination with clinical staff or a separately assessed replacement arrangement.
Do not include identifiable patient information in a general project brief.
7. Prepare the IT Section Around Users and Workflows
An IT brief should explain how people work and which systems support their activities.
Avoid listing hardware quantities without describing the business need.
Information to Include
- Number of users and locations.
• Departments and main workflows.
• Existing computers and network equipment.
• Business software currently used.
• Internet connections.
• Shared files and storage arrangements.
• Remote access requirements.
• Existing backup arrangements.
• Known performance or reliability problems.
• Required integrations.
For a software project, describe the process the system should support.
For example:
“Sales staff need to record enquiries, assign follow-up tasks and view the status of each opportunity.”
This gives the provider a clearer basis for discussion than simply requesting “a CRM system.”
Explain Data and Access Requirements
State:
- Which types of data are involved.
• Which staff roles need access.
• Whether existing records need migration.
• Which systems must exchange information.
• What operational disruption is acceptable.
• Who will approve access permissions.
Share passwords, recovery codes and sensitive system credentials only through an agreed secure process, rather than including them in the brief.
8. Prepare the Solar Section Around Electricity Use
A solar project brief should explain the site’s electricity requirements and the outcome being considered.
A requested panel quantity alone does not provide enough information for system assessment.
Useful Information to Provide
- Available electricity bills covering representative periods.
• Operating days and hours.
• Major electrical loads.
• Equipment used during daylight hours.
• Planned changes in electricity demand.
• Existing solar, batteries or generator equipment.
• Available roof or ground areas.
• Known shading or access limitations.
• Whether the property is owned or leased.
Explain whether the priority is:
- Reducing electricity purchased during the day.
• Supplying a site without an existing grid connection.
• Assessing backup for selected loads.
• Expanding an existing system.
• Comparing feasible system options.
Ask the provider to confirm what site, electrical, structural and connection assessments are needed.
State Backup Expectations Explicitly
If backup is required, list the equipment you want assessed and the desired operating period.
Treat this as an assessment requirement. Do not assume that every proposed solar system includes batteries or will supply power during an outage.
The proposal should explain the actual operating arrangement and its limitations.
9. Record Dependencies Between Service Areas
Some projects involve biomedical equipment, IT systems and power infrastructure together.
A new facility may need equipment installed, network access configured and power requirements reviewed before handover.
Dependencies to Identify
- Equipment requiring network connectivity.
• Software requiring compatible devices.
• Installation waiting on building work.
• Electrical preparation required before equipment delivery.
• User accounts needed before training.
• Data migration required before system changeover.
• Site access dependent on another contractor.
Record who is responsible for each dependency.
Ask More Grow Group to confirm which activities it can undertake and which require coordination with other providers.
10. Set a Realistic Timeline
Explain when the outcome is needed and why that date matters.
Distinguish a preferred completion date from a fixed operational deadline.
Milestones May Include
- Initial discussion.
• Site assessment.
• Requirements confirmation.
• Proposal approval.
• Procurement.
• Site preparation.
• Delivery.
• Installation or implementation.
• Testing.
• Training.
• Acceptance and handover.
Ask the provider to identify dependencies and lead-time assumptions.
A proposal should distinguish confirmed commitments from estimates affected by availability, freight, approvals or site readiness.
11. Provide a Budget Basis
Where possible, give an indicative budget range or explain how funding will be approved.
Clarify whether the budget must cover the complete project or only an initial stage.
Costs to Discuss
- Equipment and materials.
• Assessment and design.
• Freight and delivery.
• Site preparation.
• Installation or configuration.
• Data migration, where applicable.
• Testing and acceptance.
• Training.
• Travel and accommodation.
• Software licences or subscriptions.
• Maintenance and support.
• Applicable taxes and other charges.
Request an itemised proposal with exclusions clearly identified.
If the budget is not yet established, ask for separately priced options and the assumptions behind them.
12. Define How Completion Will Be Assessed
Agree on acceptance criteria before work begins.
These criteria should describe the evidence needed to confirm that the agreed scope has been delivered.
Examples include:
- The specified equipment and accessories have arrived.
• Agreed installation and functional checks are documented.
• Authorised users can complete defined workflows.
• Agreed records have been migrated and checked.
• Required training has been delivered.
• System documentation has been handed over.
• Outstanding items have assigned responsibilities.
Technical acceptance criteria should be developed with the appropriate specialists.
Do not rely solely on a general statement such as “everything must work.”
13. Include Training, Documentation and Support
Explain who will operate and maintain the completed solution.
Training Details to Clarify
- Intended participants.
• User and technical training needs.
• Number of sessions.
• Location and delivery method.
• Materials required.
• Arrangements for staff on different shifts.
Handover Documents to Discuss
- Equipment or system inventory.
• Relevant manuals.
• Configuration records.
• Drawings or diagrams where applicable.
• Test and acceptance records.
• Warranty information.
• Maintenance requirements.
• Support contacts and escalation procedures.
Ask what support is included, what costs extra and what happens after the initial warranty or support period.
A Practical Project Brief Checklist
| Brief section | Information to provide |
| Organisation | Name, business type and responsible contacts |
| Problem | Current situation and operational impact |
| Site | Location, access and delivery constraints |
| Outcomes | What the project should enable |
| Priorities | Essential, preferred and optional requirements |
| Existing assets | Relevant equipment, systems and infrastructure |
| Biomedical details | Intended use, equipment identity and service requirement |
| IT details | Users, workflows, software, data and connectivity |
| Solar details | Electricity use, site information and backup objectives |
| Dependencies | Work needed from other teams or contractors |
| Timeline | Required milestones and reasons for deadlines |
| Budget | Available range and required cost coverage |
| Acceptance | Evidence needed to confirm completion |
| Handover | Training, documentation and support expectations |
Mark unknown information as “to be confirmed” rather than filling gaps with assumptions.
A Simple Project Brief Example
The following example illustrates the structure rather than a technical solution.
| Field | Example |
| Organisation | A business operating from two sites in Fiji |
| Problem | Staff use separate records and cannot reliably share current documents |
| Required outcome | Establish controlled shared access for authorised staff |
| Existing environment | Current devices, software and connectivity to be documented |
| Essential requirement | Agree on a changeover process that limits business disruption |
| Assessment needed | Review connectivity, access permissions, backup and migration |
| Timing | Preferred completion before the next operating cycle |
| Budget | Request itemised options with ongoing costs separated |
| Acceptance | Agreed users complete defined tasks and receive handover documentation |
A biomedical or solar brief can use the same structure with service-specific information added.
Common Project Brief Mistakes to Avoid
Common mistakes include:
- Naming a solution without explaining the problem.
• Leaving the project location unclear.
• Combining essential requirements with optional preferences.
• Providing an incomplete equipment or system list.
• Assuming existing infrastructure is suitable.
• Setting deadlines without allowing for dependencies.
• Comparing proposals with different scopes.
• Omitting ongoing costs.
• Leaving acceptance criteria until the project ends.
• Assuming training and support are included.
• Sharing unnecessary sensitive information.
• Accepting verbal changes without updating the agreed scope.
A brief should be updated when important requirements change.
Preparing an Enquiry for More Grow Group Fiji
When approaching More Grow Group Fiji, provide the core brief and relevant supporting information.
Useful attachments may include:
- Equipment lists.
• Existing service records.
• Site photographs.
• Available drawings.
• Current IT inventories.
• Workflow descriptions.
• Electricity bills.
• Previous assessment reports.
Ask More Grow Group to confirm:
- Its understanding of the requirement.
• Further information needed.
• Whether a site assessment is necessary.
• Proposed scope and alternatives.
• Inclusions and exclusions.
• Responsibilities.
• Indicative milestones.
• Itemised costs.
• Acceptance and handover arrangements.
• Ongoing support available for the proposal.
Confirm the services available for the specific project rather than assuming every enquiry has the same delivery arrangements.
Turning a Clear Brief Into a Useful Proposal
A project brief gives biomedical, IT and solar service discussions a practical foundation.
Explain the problem, define the desired outcomes and provide accurate information about the site and existing infrastructure. Identify priorities, budget assumptions and dependencies, then agree on how completion will be assessed.
Preparing these details before contacting More Grow Group Fiji helps both parties identify unanswered questions and develop a proposal around the organisation’s actual requirements.
Leave A Comment