Frame a specific uncertainty that learners can examine with approved evidence and realistic support. Leave more than one reasonable conclusion possible, identify the context and boundaries, and avoid embedding the preferred solution in the question. Test whether different findings would genuinely change the recommendation before accepting the brief.
Separate the problem from the proposed answer
Employers often introduce a project by proposing a solution: build a dashboard, introduce an app or redesign a process. That proposal may be sensible, but it can hide the uncertainty learners should investigate. Ask what observation led to the idea, which consequence matters and what remains unknown. The resulting question may concern missing information, unclear instructions or an inconsistent decision rather than the need for a particular technology.
A question that asks learners to prove a solution is necessary discourages honest investigation. Replace it with wording that permits alternatives. Instead of asking why an app will improve booking, ask where users encounter difficulty in an approved booking journey and what kinds of change deserve further testing. Learners may still recommend an app, but they should be able to explain why the evidence favours it over a simpler intervention.
Set boundaries that make evidence possible
Name the process, audience or material within scope. A question about every customer experience across an organisation is unlikely to fit a short learner activity. A question about clarity in three approved onboarding documents may be manageable. Confirm that relevant evidence can be accessed without unapproved contact, sensitive information or tools outside the permitted environment. Narrowing the question should improve the quality of investigation rather than merely reduce the number of pages expected.
Check the level of the claim the question invites. Asking what caused a decline may require evidence and methods the project does not offer. Asking which patterns appear in an approved sample may be a more defensible starting point. Discuss the distinction with the academic lead so learners are not assessed against causal claims they cannot substantiate. The question, method and expected conclusion should fit each other.
Test the question before launch and during delivery
Ask the mentor to imagine two different findings and explain how each would affect the recommendation. If every possible finding leads to the same mandated solution, the project may be an implementation exercise rather than an investigation. That can be a legitimate activity when described accurately, but it needs appropriate learning outcomes and scope. Do not present the answer as open while penalising learners for reaching an unwelcome conclusion.
Give learners an early opportunity to restate the question and propose a method. They may notice an ambiguous term or an evidence gap that staff missed. Resolve the issue before substantial work begins. If new information later changes the question, document the reason and obtain the required scope approval rather than allowing a series of small informal reinterpretations.
Carry the final question into the handover. Explain how it changed, what was examined and what remains outside the evidence. A clear answer may include an unresolved issue or a recommendation for further work. Treat that boundary as part of rigorous enquiry instead of assuming a useful project must end with certainty.
Illustrative case: questioning the dashboard request
Fictional Hazel Engineering asks a college team to demonstrate why its service department needs a new dashboard. The tutor asks what decision is currently difficult. The manager explains that colleagues disagree about which repair requests are awaiting parts. An approved sample suggests that status terms are used inconsistently. The revised question asks which ambiguities in the status definitions could affect interpretation of the sample.
Learners compare definitions, classify examples and identify cases that need clarification by the process owner. They do not build a production dashboard or claim to resolve the whole service problem. Their recommendation proposes testing clearer definitions before choosing an interface. The fictional case shows how an open question can produce a different, defensible next step rather than forcing evidence to support the original solution.
A checklist for your next step
- Identify the uncertainty behind the proposed solution.
- Define context, boundaries and accessible evidence.
- Check whether alternative findings could change the recommendation.
- Review the learner interpretation and record approved question changes.
Common questions
Is an implementation project always unsuitable?
No. It can support learning when its purpose, constraints and outcomes are clear. Describe it honestly rather than pretending the solution remains an open research question.
Can a question change after work starts?
Yes, when evidence or feasibility justifies it. Review the effect on scope and assessment, then record the approved revision and its reason.
Further reading
These primary resources provide related background. They do not validate the illustrative example or endorse AcadNexus.
AI-assisted drafting and automated technical checks. Examples are illustrative; no independent expert review or real-world outcome validation is claimed. Read our editorial policy.