Enterprise Development Grant Project Planning: Turn an Idea into Deliverable Work

Describe the capability gap before proposing the solution

A capability is something the business can do consistently. Examples include evaluating customer profitability, designing a reliable service process or prioritising innovation opportunities. Name the missing capability in operational terms. This helps management distinguish a lasting improvement from a one-off output that may look impressive but does little to change how the company works.

Use evidence from the current operation. Review recent decisions, exceptions, errors and delays. Interview the people closest to the work and compare their accounts with available records. If managers disagree about the problem, resolve that disagreement before buying an external solution. A consultant cannot create a useful plan around several incompatible definitions of success.

For an illustrative engineering business, the issue could be inconsistent assessment of custom orders. Sales focuses on revenue while operations struggles with complexity and capacity. The required capability is a repeatable way to evaluate commercial and delivery fit before accepting work. That problem statement directs attention towards decision criteria, data and governance. It also creates a better foundation for selecting the appropriate current activity than a broad request for business transformation.

Set boundaries that make the project manageable

State what is included, what is excluded and what must already exist. A clear boundary protects the project from absorbing every unresolved business issue. If the work concerns job profitability, it may depend on usable time and material records. It does not necessarily include replacing the entire finance system or redesigning the company's sales strategy.

Break the work into a small number of coherent stages. Each should end in an output that the next stage can use. A diagnostic stage might establish the causes of poor visibility; a design stage might define the method; a pilot might test it; a handover might establish ownership. Avoid a schedule made entirely of workshops without explaining what those workshops will produce.

For an existing EDG project, align the boundary with the approved scope and deliverables. For new work, map it to the relevant EDGE activity and its current conditions. Do not assume that an earlier EDG project category automatically determines supportability today. Preserve the business logic while checking the funding boundary independently, especially when a proposal combines consultancy with software or operational implementation.

Specify deliverables that the business can accept or reject

A deliverable should be concrete enough to review. Instead of promising a business framework, describe its contents, intended users and decisions it supports. If the output is a pricing framework, specify the cost inputs, approval thresholds, exception process and test scenarios. If it is a process design, identify the starting event, end point, roles and handoffs.

Agree how acceptance will work before delivery begins. Who reviews the output? What evidence will show it is complete? How are comments consolidated? How many revisions are included? A single accountable reviewer prevents a vendor from receiving contradictory instructions from several managers while still allowing the people affected by the work to contribute.

Use realistic examples in acceptance testing. A process that works only for the easiest transaction may fail during peak workload or an unusual customer request. Select a small set of normal and difficult cases, then examine how the proposed method handles them. This produces more useful evidence than approving a report because it is lengthy, polished or filled with familiar business terminology.

Build a schedule around the decisions that control progress

List dependencies before assigning dates. Customer research cannot begin without agreement on the target group. A costing model cannot be tested without usable records. A pilot cannot run until staff understand the new method. These dependencies determine the project sequence more reliably than copying a standard consultant timeline.

Add the company's busy periods, management availability and decision meetings. A project may have enough calendar time but too little staff attention. Give internal contributions an owner and a realistic allowance. If finance needs to prepare a new data extract, place that task in the plan instead of assuming the information will appear when requested.

Use milestone reviews to make decisions, not merely to hear updates. At each review, confirm what has been learned, whether the next stage remains justified and which issues must be resolved. Keep a small contingency for foreseeable rework. For grant-supported delivery, ensure the schedule fits the applicable qualifying period and claim obligations. The company should understand those constraints before agreeing to an ambitious scope or relying on a later extension.

Separate outputs, adoption and business results

Three types of measure answer different questions. Output measures show whether the promised work was completed. Adoption measures show whether people use the result. Business measures show whether performance improves. A completed manual proves delivery of a document; it does not establish that staff follow the process or that customers receive better service.

Choose a small number of measures for each relevant layer. For an illustrative quotation project, the output might be an approved costing tool and decision guide. Adoption might be the proportion of relevant quotations using the new method. Business results might include fewer pricing exceptions, faster review or improved margin visibility. Define the measures and data sources before implementation.

Establish a baseline over a representative period and note limitations. If workload is seasonal, compare like periods or explain the difference. If customer mix changes, avoid attributing all revenue or margin movement to the project. Honest measurement helps management learn what worked. It also produces a more credible account than selecting only favourable numbers after the project is complete.

Assign ownership and address predictable delivery risks

Appoint a business sponsor with authority to resolve trade-offs, a project owner who coordinates work and functional owners who will maintain the result. The external provider contributes expertise; it does not take over the company's responsibility for decisions. Write down who supplies data, reviews outputs and signs off milestones.

Identify risks specific to the proposed work. These might include poor historical data, a key employee's limited availability, dependence on a supplier or disagreement about operating policy. For each, record an early warning and a practical response. A risk register is useful only if it changes what the team does. Avoid filling it with generic statements that nobody monitors.

Discuss knowledge transfer explicitly. Ask the provider to explain the method, walk staff through working examples and supply the agreed editable materials where appropriate. Assign a maintenance owner before handover. A framework that only the consultant understands leaves the business dependent after the project ends. The lasting capability should be visible in the team's decisions and routine work, not just in a final presentation.

Use a project charter to test readiness before commitment

Bring the plan into a short charter containing the problem, scope, deliverables, measures, budget, schedule and owners. Add the main assumptions and unresolved questions. This document should be understandable to the people who will implement the work, rather than written only for a grant application or board pack.

Hold a readiness discussion with management, operations and finance. Ask whether the problem is important enough, whether the proposed work is proportionate and whether the business can supply the required attention and cash. Confirm how the project relates to other initiatives. If two teams are changing the same process, settle the sequence before either starts.

For ongoing EDG work, compare the charter with the actual approval and resolve differences through the appropriate process. For a new project, use it to prepare the current EDGE activity assessment before delivery begins. The charter then becomes a stable reference during implementation. When a new request arises, the team can judge whether it advances the agreed outcome or should belong to a later project.

Frequently asked questions