Did Your School Project Fail Because You Consulted Too Little or Too Much?

Before we start, this article is about consultation, not consultants

.

Consultation is the process of engaging stakeholders, gathering perspectives, understanding risks, and building support for change. Whether you use external consultants in Hawaiin shirts or not is a separate discussion.

Most school project failures are not caused by technology.

They are often caused by people.

More specifically, they are often caused by getting consultation wrong.

Having worked on dozens of school projects, I have seen both extremes. Some schools involve too few stakeholders and discover critical issues too late. Others involve so many people that decisions become impossible. Meetings multiply, competing priorities emerge, and accountability becomes blurred.

Interestingly, schools that make the first mistake often overcorrect on the next project. After discovering they did not engage enough people, they attempt to involve everyone in every decision.

A school Struggling with How many people to consult.

Unfortunately, that creates a different set of problems.

The challenge is not whether to consult. The challenge is knowing who to consult, when to consult them, and when it is time to stop consulting and make a decision.

So what is the right number?

The answer depends on the stage of the project.

1. Discovery: Go Broad Enough to Understand the Problem

At the start of a project, the goal is not agreement. The goal is understanding.

This is the stage where consultation should be at its broadest. The objective is to understand different perspectives, identify pain points, uncover risks, and establish what success looks like across the organisation.

Parker IT will typically engage with a dozen or more key stakeholders during discovery. Depending on the project, that might include school leadership, teaching staff, administration, enrolments, finance, wellbeing, IT, learning support, boarding, marketing, and other operational areas.

If a broader view is required, surveys can be highly effective. They allow schools to identify patterns and gather feedback from larger groups without requiring hundreds of interviews.

One thing that I find extremely valuable during discovery is how seemingly small observations can reveal much larger issues.

A stressed staff member might reveal that underlying processes are making their work far more difficult than they need to be. Two departments requesting separate interviews can sometimes hint at process challenges, competing priorities, or historical frustrations. The person who has been at the school for twenty years and quietly mentions that they have seen three previous rounds of consultation go nowhere can provide important context about change fatigue and organisational culture.

None of these insights are likely to appear in a project plan or requirements document, yet they often explain why previous initiatives struggled and where the real risks lie.

Sometimes the most valuable information in a discovery interview has nothing to do with technology at all.

2. Design: Bring in the People Who Can Improve the Solution

Once the problem is understood, consultation should become more targeted.

The design phase is where too many cooks can genuinely spoil the broth. The focus should be on the people who can improve the solution, challenge assumptions, and identify practical constraints before they become problems.

Every stakeholder views a project through their own lens.

A teacher may focus on classroom outcomes. An IT manager may focus on supportability, security, and integration. A Business Manager may focus on financial sustainability. An enrolments team may focus on parent experience and growth. School leadership may focus on strategic alignment and organisational impact.

None of these perspectives are wrong. In fact, they are all valuable.

The challenge is that no single stakeholder can see the entire picture.

But this worked at my previous school..

I've seen schools choose a system because a particular stakeholder used it successfully at a previous school. While that experience is valuable, every school is different. The previous school may have had different processes, different integrations, different staffing levels, or even different expectations of what success looked like.

Good design consultation helps ensure decisions are based on the needs of the current school rather than memories of a previous one.

By the end of the design phase, the options should be clearer, the trade offs better understood, and the path to a decision much easier.

3. Decision: Reduce the Room and Clarify Accountability

When it is time to make a decision, the room should become smaller.

One of the most common challenges I see in school projects is uncertainty around decision making. Who is making the decision? Who has the authority to make it? Is the project team making recommendations, or are they expected to make decisions on behalf of the school?

Large projects involve dozens of significant decisions. If every decision needs to be escalated, progress slows dramatically. The project team needs to be empowered, and it needs to be clear which decisions can be made within the project and which need to be escalated.

That is not to say that decisions and their rationale should not be communicated to executives. They absolutely should. Good governance requires visibility and accountability.

However, if decisions cannot be made in a timely fashion, projects begin to stall. Momentum is lost. Stakeholders become frustrated. People disengage from the process. Before long, the sceptics who were quiet at the beginning start questioning whether the project will ever deliver its intended outcomes.

Good consultation informs decisions. Good governance ensures those decisions can actually be made.

4. Delivery: Keep Contributors Close and Stakeholders Informed

Once delivery begins, the focus shifts from deciding what to do to getting it done, (well mostly).

At this stage, the core working group should remain lean. The people closest to the work need quick feedback loops, clear escalation paths, and the ability to resolve issues without constantly reopening decisions that have already been made.

One concern that occasionally arises during delivery is when a decision made earlier in the project changes. Some stakeholders see this as a sign that the project is losing direction.

My view is that it depends on why the decision is changing.

Software evolves constantly. Vendors release new functionality. Schools gain a deeper understanding of their own requirements. Project teams learn more about integrations, processes, and operational realities as implementation progresses.

It is perfectly reasonable to revisit a decision when new information becomes available.

What you want to avoid is indecision driven by the pursuit of certainty. In technology projects, complete certainty rarely exists.

There will always be another product release, another feature, another vendor announcement, or another solution entering the market tomorrow. Waiting for the perfect answer often means never moving forward at all.

While the delivery team needs the freedom to make progress, stakeholders should not be left wondering what is happening. Regular updates, clear communication around decisions, and transparency around risks help maintain confidence in the project. People are generally more accepting of challenges when they understand why they occurred and what is being done to address them.

5. Adoption/Go Live: Widen the Conversation Again

As rollout approaches and the system goes live, the circle should expand once more.

At this stage, people are no longer discussing future possibilities. They are using the system to do real work and real issues are emerging.

The challenge is applying discernment to the feedback you receive. Is a staff member raising a genuine issue? Do they need additional training? Have they been resistant to the change from the beginning? Or did we miss important information during discovery because their concerns were never fully explored?

Resource this stage appropriately. The project team is often trying to resolve issues, encourage adoption, build confidence, and support struggling users all at the same time.

Pilot programs can help, but they are not a perfect substitute for full adoption. Some issues only emerge when hundreds of people begin using a system in ways that nobody anticipated.

In my experience, the biggest problems rarely emerge on day one. Everyone expects day one to be difficult. The real challenges often appear in the days and weeks that follow when people begin relying on the new system to do their jobs.

Adoption is not about achieving a perfect go live. It is about listening carefully, responding appropriately, and helping people gain confidence in the new way of working.