Your Dashboard Won't Build Itself —

And in Higher Ed, That's Especially True

Author: Anna Kourouniotis (2026) | Note: a more generic version of this blog was written by the author and is hosted on their Substack.

Picture this. Someone at your institution needs a report on enrolment trends, financial aid disbursements, or student retention. You're the person who can build it. The deadline is two weeks out. You open your system — PeopleSoft, Oracle Analytics, whatever your stack looks like — and think: I've got time. I'll work it out as I go. Two weeks later, you're still chasing down data access from IT, your stakeholder has changed the scope twice, and you're submitting something incomplete at 11:47 PM. If you've worked in higher education for more than a semester, that scenario probably feels familiar. And it's not because people in higher ed are disorganized or don't care. It's because reporting and dashboard work in our sector comes with a very specific set of complications — and most of us were never taught to treat it as a project.

The Higher Ed Version of This Problem

In a corporate environment, 'just a dashboard' might be complicated enough. In higher education, it comes with extra layers that most guides to data work completely overlook. Your data lives across multiple systems — Campus Solutions, your SIS, financial systems, HR — and getting them to talk to each other cleanly is rarely straightforward. Your stakeholders might be a Dean, a Registrar, a Vice-Chancellor's office, and a faculty committee, each with a different definition of the same metric. And unlike in industry, your timelines are often governed not by business urgency but by academic calendars, committee cycles, and shared governance processes that move at their own speed. Add to that the reality that many reporting teams in higher ed are small, wear multiple hats, and frequently absorb requests without the bandwidth to push back. The result is a culture where deadlines are treated as aspirational, scope grows silently, and the person building the dashboard ends up carrying the risk alone.

This is where a bit of structured thinking — borrowed from project management — changes everything.

What 'Project Management Thinking' Actually Looks Like Here

Before anyone closes this tab — no, this isn't about Gantt charts or PRINCE2 certification. Nobody's asking you to become a project manager. It's about one core habit: breaking the work into defined phases with clear checkpoints before you write a single line of code or pull a single query. Specifically, it matters for three reasons.

1.    It surfaces problems early. Data access issues, unclear requirements, scope changes mid-build — all of these are vastly easier to resolve on Day 2 than Day 12. In a Campus Solutions environment, finding out a key field isn't populated in your SIS until the night before delivery is a very specific kind of bad time.

2.    It gives you something to communicate. When a Dean's assistant emails asking for an update, 'it's coming along' is not an answer that builds trust. A milestone plan gives you a real, confident response.

3.    It protects your scope. When a new request lands mid-build — and in higher ed, it will — a milestone plan lets you respond with 'yes, and here's what that means for the timeline' rather than silently absorbing work that will quietly push you past your deadline.

A Practical Framework: The Dashboard Milestone Map

Here's a five-phase approach that works for most reporting and dashboard builds in a higher ed context. The example below assumes a two-week window, but the structure scales with your timeline.

A few notes specific to our context.

• The data audit phase (Days 3–4) is the one most people skip — and it's the one that causes the most delays in a PeopleSoft or Campus Solutions environment. Before you build anything, confirm that the data exists, that it's clean, and that you actually have access to pull it. These are three separate questions, and the answers are not always yes.
• The buffer day is not a reward for finishing early. It's where quality lives. If everything has gone smoothly, use it to polish. If something slipped — and in higher ed, something usually does — use it to recover quietly rather than apologetically.
• Treat each milestone as a conversation prompt, not just a checkbox. At every phase transition, ask: do I know something now that my stakeholder or my team needs to know? If yes, say it now. The PCM community knows this instinctively: early, proactive communication is the hallmark of a well-managed project, not a sign of weakness.

The Habit That Saves You: Estimate Before You Build

Before you begin any build, take fifteen minutes to list every sub-task. Not the broad phases — the actual work. 'Run query to check enrolment data completeness.' 'Confirm financial aid codes with the FA office.' 'Build year-on-year comparison logic.' 'Draft layout for stakeholder review.' 'Get sign-off on v1.' Estimate the time for each. Then add 20–30% as a buffer. If the total doesn't fit before your deadline, you've just discovered something important — before the build started, not after it failed. This is especially valuable in a higher ed environment where ad hoc requests are constant and no one has a realistic sense of how long reporting work actually takes. Making the work visible — even just to yourself — is how you start having honest conversations about capacity and timelines.

A Note for the PCM Community Specifically

If you're reading this from a project or change management lens, you'll recognize all of the above. But it's worth naming something directly: the analysts and reporting staff doing this work are often not set up to succeed by the systems around them. Think about this: Are requirements stable when they arrive? Is there enough lead time to plan before building begins? Is there a low-friction way to flag scope changes without it feeling like an escalation or a complaint?

In higher education especially — where the culture of collegiality can make pushback feel uncomfortable — analysts often absorb scope quietly and carry the risk alone. The milestone framework works best when the environment supports it. As PCM practitioners, you're well-placed to help create that environment: normalizing early communication, building buffer into project plans from the start, and treating analytical deliverables with the same rigor as any other project output. 

Good project management is a two-way street. The analyst needs to plan and communicate. The project manager or sponsor needs to protect the conditions that make that possible.

A Note on Time, Culture, and Higher Ed

One thing I've learned from working across different sectors and cultures is that not everyone has the same relationship with deadlines — and higher education has a very particular version of this. Earlier in my career, I worked in solution development for a global 4PL company where RFP deadlines were absolute. 5:00 PM Thursday meant 5:00 PM Thursday. The company was German-founded, and that culture treats timelines as close to a moral commitment. Precision and reliability weren't just professional norms — they were structural expectations.

Moving into higher education required genuine recalibration. Timelines here often move at the pace of committees, academic calendars, and shared governance. What felt like urgency to me wasn't always read the same way by colleagues. And I came to understand that this isn't dysfunction — it's a different, often quite deliberate, relationship with time. But it does mean you have to be more explicit about shared expectations, rather than assuming everyone in the room defines 'on time' the same way.

This, incidentally, is exactly what the milestone framework does beyond just personal organization. It creates a shared reference point — a common language around expectations, accountability, and timing that works regardless of whether your team skews toward German punctuality or a more relational, flexible approach. The milestone plan becomes neutral ground.

Bringing It Together for Our Community

The shift being described here is not large. It doesn't require new tools, new platforms, or new training programs. It's three habits:

1. Plan before you build. Map the phases, estimate the tasks, identify your data dependencies. Fifteen minutes at the start saves hours at the end.
2. Use milestones as checkpoints. At each phase, ask: am I building the right thing? Do I know something that changes the plan? Does anyone need to hear from me?
3. Communicate early and proactively. A heads-up on Day 5 is manageable. Silence until Day 13 is a problem — in any sector, and especially in ours.

Reporting and dashboard work in higher education is consequential. It informs enrolment decisions, financial planning, student success initiatives, and institutional strategy. Treating the build process with the same care you bring to the analysis itself isn't overhead. It's professionalism. And it's exactly the kind of practice the Connected Campus and PCM communities are well placed to champion.