“We want to implement AI.” Here is how to turn that into a project

“We want to implement AI in customer service.”

It sounds like a direction. The delivery team still needs to know what should change, for whom, and how success will be assessed.

Does the organization want faster replies? Better access to information? More consistent answers? Less time spent documenting interactions?

Each objective could produce a different project.

A useful project brief turns the ambition into decisions the team can act on. Start with six questions.

1. What problem are we trying to solve?

Describe the current problem using evidence from the work.

For example: support agents spend time searching across several knowledge sources before they can answer routine product questions.

Establish what you know and what still needs investigation. Look at search time, delayed responses, repeated questions, or feedback from agents.

Keep the proposed solution open until you understand the problem. Outdated content, unclear ownership, or fragmented processes may need attention alongside any AI capability.

2. Which workflow will change?

Identify the starting point, end point, users, and systems involved.

For a support assistant, the workflow might begin when an agent receives a product question and end when a reviewed response is sent to the customer.

Map where information is retrieved, where an answer is drafted, and who checks it. Include the route for questions the assistant cannot handle.

This makes the implementation work visible.

3. What is inside the initial scope?

Set boundaries around the first release.

An initial scope might include one support team, a defined product range, approved knowledge sources, and staff review before any answer is sent.

Document exclusions too. For example, the first release might exclude account changes, payment disputes, and direct automated responses to customers.

Clear boundaries help the team estimate work and assess proposed changes. They also make evaluation more meaningful because everyone understands what the initiative is expected to handle.

4. Who owns the outcome and the decisions?

Name the business sponsor, workflow owner, delivery lead, and relevant technical and risk specialists.

Specify who decides whether the capability is ready to use, who resolves scope questions, and who can pause the rollout.

A responsibility list becomes useful when it tells the team where a decision belongs and how to obtain it.

5. What evidence will justify continuing?

Agree on the intended benefit and the conditions that must remain acceptable.

For the support example, evaluate the total time required to produce a checked response alongside accuracy, escalation handling, and access controls.

Record the current baseline. Define how the pilot will be assessed and which findings would lead to expansion, revision, or stopping.

Treat the pilot as a decision-making exercise with a clear end point.

6. What does the project depend on?

Identify the people, information, approvals, and system changes required.

For example, the assistant may depend on current product documentation, appropriate source permissions, access to test users, and someone responsible for correcting outdated content.

Assign owners and dates to critical dependencies before committing to a launch schedule.

Your next step

Bring these six answers into a short project brief. Mark assumptions clearly and give unresolved questions an owner.

If important answers are missing, make discovery the first defined phase, with its own deliverables and decision date.

Ciniji Group provides fractional delivery leadership to help organizations define, coordinate, and deliver AI initiatives.