From Vision to Execution: Creating a Technology Roadmap That Works for Your School

Great, thank you.

Hello, welcome.

Good morning, afternoon, or evening to everyone, depending on where in the world you're joining us.

I'm Kelsey Watson with Atlas, and today I am absolutely thrilled to introduce our friends from Knowing Technologies.

Knowing Technologies is one of our, um, phenomenal vendor partners.

They support all the work that we do, and they are here to share some of their thought leadership with you.

So we've got, uh, Tom will, sorry, I just asked you how to pronounce it.

Tom Wildman.

Yeah.

The founder of Knowing Technologies.

He's gonna talk about creating a technology roadmap.

Something that I think we all can use.

And with Tom is Jim Chetty.

He's gonna be moderating the chat, so throw any questions in the chat as we go.

But without further ado, Tom, I'm gonna kick it off to you.

Yeah, great.

Thank you so much.

Thanks for setting this up and for making this so easy to do.

And good morning or afternoon, everybody, depending where you're from.

So, yes, I am Tom Wildman, the founder and CEO of, uh, knowing Technologies.

We've been supporting independent schools for of what, over 15 years now.

And, um, predominantly the work we do for them is, uh, helping their technology departments.

I mean, their technology programs come integrated with instructional and strategic objectives of the school.

We do that through a variety of ways, and one of the many ways that we do that is to build for our client schools technology roadmaps.

And the, the subject of today is how you can create a technology roadmap that works for your school.

So you will probably take a slightly different approach to it, uh, than we would, and I'm gonna talk about this, uh, as though I was advising you, uh, to create a, a roadmap for your school, and rather not telling you how we create roadmaps for our schools, which is a little bit different.

So first, let's talk about what a technology roadmap is.

I put one definition there.

It's really kind of, it's a, um, it, it's a when and how document.

It's a forward-looking, uh, plan that takes the organization's specific goals, the findings and the technology, um, risks that, uh, the schools have their set from the organization rules and kind of puts them together into a, into a time sequence plan.

So I'll show you a couple of examples, and it will, it will clarify really what it, what it looks like.

But it should answer a few questions, um, that I, I have on the screen here.

One is, you know, where are we today? Another is what are we trying to improve? And then the key thing with a, with a technology roadmap is, and what sequence are we doing? Are we doing that work? So, uh, I thought it was important for me to also say it is not a list of projects or a shopping list.

Uh, it's not like a technical architecture, a diagram.

It's not a help desk back log.

It's really a plan.

It's a forward looking plan that uses data and objectives, uh, to sequence actions.

So, uh, with that, we'll move on to what you may get out of a, of a, uh, of a, a technology roadmap.

So if you, if you do this right, uh, what's gonna happen is you'll, you'll have a significantly lower surprise spending and I, I'm not sure how many you had to, uh, put your tail between your legs and go talk to the CFO about an emergency purchase that was not really planned, something broke.

Now you need to spend some money.

Those are the kinds of things that tell leadership that you're not well organized or you're not ahead of the technology.

And so a technology roadmap actually conveys that you've got strong budget discipline, and that you're kind of tied to, you know, like ROI, uh, tracking.

It also shows, uh, that another benefit that you'll get out of a, out of a roadmap is, uh, a reduced ticket load.

Because you're taking this, uh, significant amount of reactive work.

You know, responding to tickets is essential, but it really isn't overly valuable to the school.

What's highly valuable is to find out why you have so many tickets and come up with proactive plans to reduce that number.

So we, we kind of call that operational noise tickets.

Uh, so coming up with a plan that reduces operational noise is another benefit of a roadmap.

Also, a benefit is that faculty has significantly more trust in what technology is delivering.

There's like a, maybe a clear training calendar for them, or the systems that you've installed in their classrooms are, um, are stable and they get replaced with predictability.

And there are fewer disruptions of technology systems, both classroom and services, uh, that faculty experience.

Another thing that you'll find is that when you have a technology roadmap, the board has more confidence that the money that they're allocating for technology is being wisely spent.

They see predictability, um, they see evidence-based security improvements.

Um, they see clarity in, in, in capital planning.

So, um, so boards have significantly more confidence in technology organizations that do, uh, technology roadmaps.

I just put this another example, that you have stronger advancement in admissions performance.

And, and the reason is that often part of the roadmap roadmaps are, uh, systems integrations.

And that could be SIS with admissions, SIS, uh, with, with advancement.

So just, I use those two departments of examples, but obviously they're looking for stronger performance.

And when their systems are integrated with SIS to think kind of through the, through the, that integration as a data holistic, um, approach, then they're clear that when records get updated and they ask SSIS for example, they are accurate, and then in a time new way, the same, uh, the same records get updated in the, in the donor databases.

So that kind of accuracy and effectiveness is a strong signal that technology are being, uh, led by somebody or some people who think strategically and organizationally.

And then finally, um, there is, uh, there's the opportunity to, to retain IT staff more because they're, they're, they're less chaotic.

They're not running around doing yesterday's work by fixing yesterday's problems.

They, they kind of have a clear direction, and they all are involved in participating in the action plan, which gives them a point of pride, a point of a sense of accomplishment, and kind of an opportunity to see themselves growing career wise with the organization.

And then lastly, I put here, uh, that when you do, uh, a technology roadmap, and I've, I have yet to meet a technology leader that has been asked to do a roadmap, almost always to leaders say that they need to do a roadmap.

They recognize the imperative to doing roadmap, and then they, when they do deliver one, they have significantly more credibility with leadership.

It's like, okay, leadership, uh, sees I believe that this technology department is self running.

Okay.

Uh, so then another, uh, I guess the counterside of that is what happens when you don't do a technology roadmap? Well, uh, there's emergency firewall replacements, emergency server refreshes, cyber incident.

So the cost of responding to cyber incidents, um, and often those kinds of things.

Well, first, they convey a lack of confidence in your ability to plan and, and to control what's happening.

It also kind of shows that, um, that the cost, uh, that they are spending money on remediating things that could have been more effectively spent on modernizing, um, and protecting.

Um, another, another, uh, risk of not planning is tool sprawl or vendor sprawl sprawl of things that you think, Hey, hey, here's an idea.

Let's buy this system.

Let's add that, uh, or let's get an LMS and implement it without considering how to integrate with the SAS without having clear data management processes.

Um, we also see a risk in, uh, insecurity that if you don't have a technology roadmap, you don't think through framework based, um, uh, security vulnerabilities, and you, you present a more vulnerable posture, uh, to, to would be attackers.

Um, another, another risk is that, uh, leaders begin to see that tech is somewhat chaotic.

Faculty see instability.

They see systems failing.

The board sees high risk that isn't being managed head of school sees it, technology is becoming a distraction.

And everybody's kind of getting this, you know, fairly negative vibe about what's happening in tech, what's happening in technology.

And then finally, the counter to staff retention is staff burnout.

They're spending way too much time responding to tickets.

Their, their complaint about constantly being interrupted.

Their strategic work is never, is never, uh, completed because, uh, they can't allocate the time to do it.

And then you kind of have a higher risk of turnover.

Um, and from a to a school leader, we would always say, you know, replacing a good, uh, technology director is significantly more expensive than building a roadmap.

So those are some of the risks of not, uh, not planning by roadmap.

Okay.

Um, so what are the aspects of, uh, strong roadmaps? Uh, I'm not gonna read all these to you, but I wanna call out that first one is risk posture scoring.

And, um, in, in, in scoring or in determining what your, what your cyber risk is, use some framework.

And two that we use are CIS and NIST, or NIST light.

Um, strong roadmaps have phased initiatives, and I'll talk specifically about how to phase that.

Uh, and then they have clear separation of costs in opex, uh, opex, and, and CapEx.

Um, so those are some aspects you can all read, and I'm not gonna read those to you, but, uh, there are definitely things that need to be in a roadmap in order for it to be valuable.

Um, so the fra the strategic framing of doing a roadmap, uh, is kind of what, what creates friction in the school.

Friction is created by technology when risks aren't managed, um, when spending is done with abandon or wildly or reactively, uh, and when leadership starts to lose confidence in their systems or in, or in the staff.

And, and if you able to deliver a roadmap that is meaningful, that all of those drifts begin to just dissolve.

And we see that technology is actually aligned strategically with the organization connected to the strategic objectives of the organization.

And, and that, uh, the roadmap is the supporting document that says, when and how are those connections going to reap the benefits that I talked about a few slides ago? So, um, kind of before we get into what a roadmap looks like, uh, a little cautionary tale a word of what, what, um, causes roadmaps to fail.

Uh, what I see a lot is that when a roadmap looks more like an un unaligned wishlist, in other words, without saying which strategic goal, uh, is being met, here's the shopping list we're going to implement, you know, Blackbaud beginning in March, we're gonna implement, um, uh, uh, Ravenna in the summer.

We're gonna make this special API tie in between the two, you know, sometime in the spring, it's kind of like a list of stuff we're gonna do, but in no particular sequence into support, no particular strategic purpose.

So, um, so roadmaps should not look like a wishlist, and they should not look like a bullet list of things that you're trying to get done.

Those are just talking points, but they don't really convey structure, organization or control of the process of delivering on the strategic objectives.

Uh, finally, uh, roadmaps fail when you've just come up with unrealistic timelines or timelines that, you know, sort of diverge from what, what they were expected, uh, to deliver, uh, or, uh, are carried out far too to long in the future for any benefit to be realized.

So, avoid these two traps, uh, to support your roadmap being highly valuable.

So let's take a look at a couple of roadmap formats.

By the way, you'll see as I talk, there are many, I'm gonna say axes that we look at in, uh, in, in roadmaps.

And one of them is the, is a time axis.

And so here, what you can see is that, uh, for this school, this is, this is one of ours, um, that, that we deliver.

And yours don't have to look like this.

The tool, the presentation is far less important than the content.

But this is a timeline view, a timeline view of a roadmap that shows, you know, down in those rows specific projects or initiatives that are being taken.

And then as you move forward in this two year, roughly two year timeframe, you can see what the staging of those, of those, uh, of those initiatives is going to be.

So this doesn't necessarily convey, uh, de dependency, uh, but I'm sure that when this plan was created, um, how those were linked together or why what the sequencing was, uh, was very clear.

And we would certainly, when we presented this with a customer to off why those are being sequenced that way.

Um, by the way, uh, I'm not suggesting that you copy this format, it's just one that we use.

I, I, I think I'll show you a significantly simpler, simpler format shortly.

So here's another one of the axes I was talking about.

This axis is cost.

Um, it is also an essential part of the roadmap.

Um, CFOs don't care about that.

Uh, CFOs care significantly about this.

And so, uh, for this school, this shows what all of those initiatives are going to cost and about when those, those budgets, those, uh, expenses are going to hit now far more valuable, uh, to A CFO is this than when those things are gonna get initiated or how, uh, uh, how you've chosen the sequence of these actions.

So this kind of a grid is particularly informative.

And by the way, this is a highly detailed grid.

I'll show you an example of a much more simple grid that could be just as effective shortly.

Alright? Uh, so let's get into actually how to create a roadmap.

Uh, obviously in a one hour webinar, we won't have a whole lot of time to go into, uh, into a lot of detail, but I'm gonna kind of approach this as if, uh, as if you were a CTO, uh, in a school.

And so I kind of broke this down into, into six, uh, into six steps.

And, and I'll talk about them in detail in, in subsequent slides, six subsequent subsequent slides.

But the first, the first step is to anchor what you're trying to do to institutional priorities.

So you might think about this as like, pull out the school strategic plan or understand what the, the leadership zeitgeist is saying about the things that are important to accomplish.

And have that as your baseline.

The next step is, is to conduct, uh, assessments of all of the, uh, systems and services and devices that you're responsible for that would represent a technology plan.

And just get a clear assessment of where you stand with them at this day, what's happening today with them, where are, and then the next step is to identify, uh, the concentrations of risk given those, um, the assessments that you just, that you've just done.

What are the things that are causing, uh, the biggest risks to the, to the schools continuing operations? Typically, those are things like firewalls, access points are old, wiring is failing, those kinds of things.

Um, and then you can, once you take the, what the school is trying to do and what you've assessed and what is the highest risk, you've really got the essentials there of being able to say, okay, I'll piece all this together into, into initiatives or projects, uh, that begin to, uh, remediate that risk.

And at some point align to the, to the, in, to the institutional priorities.

And I start to lay out what I showed you earlier as a, you know, as a timeline, kind of this, this sequence.

Once you've got that sequence built together, you're ready, you put together, you're ready for, for the fifth step, which is to cost all of those things out.

And, and you can see how that sequence of, of, of priorities, actually, each one of those sequences steps in a sequence is an initiative or a project.

And they have a known cost that you can see about when are we going to have to spend that money.

Uh, and then finally, you know, you're not creating, uh, A PDF that you fling over the wall to the CFO.

You, you actually kind of have a living document that has a living process and a need to be cared for and fed.

So, um, you wanna keep that, you wanna keep the document alive, you wanna keep the output alive, and you wanna keep it relevant and updated by, say, quarterly reviews or some frequent reviews, uh, of, of that document with a governance or like, typically the leadership team.

It's rare, uh, but it happens that technology directors are meeting with the board, but, you know, strange things happen in independent schools.

Alright, so those are kind of the, the, the high level steps.

Let's talk a little bit about the details.

Um, the step one is understand what these school's institutional priorities are.

And here are some examples, and this is not the list, but these are examples of the kinds of things you may wanna understand.

What is most important to your school? What is most important to, to the board? What do, what are the, what is the school, um, measuring success criteria with or, or by.

And then, uh, and then have a clear understanding of how you sequence, uh, those priorities and how they're going to feed the plan.

So you're gonna ask questions like, you know, what initiatives require? What have these initiatives that the school is considering require technology enablement? Obviously something like, you know, plant maintenance or plant management does not, that's less relevant.

And then you also ask, where is technology in those items currently? Uh, a constraint on success.

Um, so what, you know, if, if you think about, um, if you think about asking these questions, which you may never have asked before, kind of, you can see that this reframes technology, the technology with a capital t, the department more as like institutional infrastructure, less like a departmental expense.

You're kind of, sometimes I call this moving technology into the value chain, where you're actually integrated with what the school is trying to accomplish.

Well, step one here is when you find out what those things are.

Step two is to conduct assessments.

And this really to understand, you know, what, what is the, what's the infrastructure, health, the average device age, the wireless density, wireless technology standards switching condition, uh, how frequently do you back up? How frequently do you, do you fail to restore metrics? Um, and then with, uh, another assessment is in security.

Like, are you using a, a framework like CIS or NIST to assess your security posture? Um, if so, some metrics from that.

Like, uh, how well covered is your m is your multifactor authentication program, uh, how, how, uh, well covered are your endpoint, uh, protection or, or endpoint protection detection systems.

How often do you conduct vulnerability scans? Um, I also suggest you, you assess, um, uh, platform sprawl, number of SaaS tools, the integration of the SaaS tools and the maturity of that integration, duplicate entry workflows, uh, from those SaaS tools.

Also, um, uh, onsite servers, like, that's another platform that probably should be considered for, uh, reduction if not complete elimination.

Um, again, by independent schools.

Uh, not Finally, another assessment category is operational load.

Like, you know, the tickets per month, the FTE spent on tickets, that staff capacity that you have for those tickets versus demands.

And so those things you put together, and you kind of have a pretty good sense of what your current state is, what your, what the other key feed is into your roadmap.

Um, here is sort of a, this is on step three, a way that you take that, those assessment and start to kind of categorize, um, uh, categorize what each of those assessed issues is presenting in terms of risk and what the severity of the actualization of that risk would cause to the, to the, uh, of what the impact would be to the organization and the severity of that, of that impact.

So you can kind of list these out for you.

This doesn't make the roadmap, but just kind of for you, it starts to tell you what's bubbling up to the top as the sequence of issues that you have to address, uh, to, to minimize the operational risk of technology, of the technology program.

Uh, the key, so step four is to now start to build a sequence, um, of how you're going to meet all of those problems by how they, uh, how they depend upon one each other.

And so, you know, the key here is that stability always precedes optimization.

And stability means all these things that you've identified as risks or, or key system impacting, um, uh, or it's, say, institutional impacting failures would be, uh, address those things first.

It, it really, it really doesn't seem particularly credible if A CTO were to say, all right, well, we're gonna, we're gonna, uh, create, we're gonna start our, our roadmap by creating, um, uh, a really nice, uh, data dashboard that shows application data versus admission data versus, you know, uh, grading success.

Or can I kind again, kind of give these this grand presentation view of our data? It's really doesn't show that that's a credible approach if the network still has, has, uh, instability or stability risks at it.

So you don't wanna erode credibility by getting the sequence wrong.

So this does not necessarily have to be the order you choose, but it's an example of a correct order that if you deviate from it, you're kind of, you know, you're on your own there.

But, uh, this approach makes sense.

So attack the infrastructure first, security, then, uh, consolidating platform cloud, that includes clarification, then doing some fancy systems integration work, maybe even integration elimination, uh, maybe even system elimination.

And then you can start working on strategic enablement, en enablement, like going back to what the school is trying to accomplish and coming up with initiatives to meet those.

Is, there we go.

Uh, fifth step is to attach financial forecasting.

I'm not gonna belabor this.

This obviously just means for each one of those initiatives that you have on your plan, what is the cost? And the cost is considered in three categories broadly, the, the cap, the capital expenditure costs, uh, the operating cost that's required, uh, you know, subscription things and things are not, um, uh, capitalizable.

And then, uh, lifecycle cadence issues like, uh, uh, laptop replacement programs, for example.

And, um, you know, again, from a, from a trust standpoint, uh, leadership really trusts, um, your plan, your roadmap when you know, when, when, as a result of the roadmap, one, you got no surprise capital requests anymore.

You don't ever have to go with your tail between your legs and say, this broke, or I forgot to renew, or, I didn't know about this.

When you stop having those, uh, surprise requests, significant trust, uh, increases occur.

Uh, another thing that they like to see is that your financial plan, your, particularly like your lifecycle cadence and maybe even the, the roadmap, that there's a fairly good smoothing that occurs after, you know, three to five years.

You know, at the beginning, you may replace all of the faculty laptops in one year, and then it's ess for four years or whatever the life is, and then you do it again.

So coming up with a way to smooth those expenses is always preferred to supporting these, these high peaks and value values on, uh, capital expenses.

And that's because, uh, the money that comes into the school is significantly smooth.

Uh, so then the, another thing to consider with, um, with trust increasing with your financial forecasting is that your device refresh cycles are predictable.

Uh, I do see many institutions where there's a negotiation every year about, about renewing devices that have long since exceeded their usable lifetime.

So that needs to go away.

You put a roadmap in front of the, in front of the leadership team to show that, that your device cycles are planned, your device refresh cycles are planned, and then it's, it's a significant trust of building experience for them.

So, uh, step six is to, uh, to follow all that up.

Once you've put that plan together, follow up, uh, the, the review of that plans, uh, at some cadence that makes sense.

And it might be like, um, you're reviewing, you're reviewing the, the, uh, the finance with, uh, you're reviewing the financial aspects with the CFO every quarter.

Uh, maybe half every half year, you're reviewing the risk reduction with head of school, um, maybe e once a year, you, you produce a board update that either the head of school can bring to the board or that, um, or that, uh, you are presenting to the board directly, and there's some kind of, um, there's some kind of calibration that you do like to, to, uh, to, to take your show how your roadmap has specifically started meeting the objectives of that you laid, that you lay the hell ahead of time, right? Are you lowering costs? Do you have more time for proactive work in, in your IT staff? Show me the, the, how you're reducing risk as this, uh, as the roadmap is, uh, is executed.

So those are the kinds of things that signal maturity and really convey that your roadmap makes sense and, uh, you are driving rather than being driven.

Um, so now all, uh, so that's, that's sort of how you, how you build a roadmap.

Now, uh, uh, I'll give you some idea of how, how you present it, you know, um, and, and I, I, I suggest is like, you know, six to 10 slides, I'll give you examples of them.

Uh, I, I think it's a mistake to put together a 40 page heavy document in front of leadership because they're not gonna read it, they won't understand it, and you're gonna be tempted to put in techno jargon and you'll, you'll lose credibility and you'll lose their interest.

So typically come up with like six to 10 slides, you know, maybe, maybe eight to 12 pages max in the presentation.

I mean, PowerPoint slides, uh, always a very effective way, uh, to do that.

And let's, let's talk about what those slides are.

So first, the executive summary.

So this sort of, this, uh, slide tells you, um, what are the objectives of the, of the roadmap? And I gave an example here of objectives, um, that are highly, are well responded to when you present 'em to leadership team.

But you might also include here things from the strategic plan or other objectives that drove that informed or drove the sequencing of your plan.

Uh, next is a summary of your current state snapshot.

This, uh, current state, uh, snapshot.

This is how you can summarize the assessment that you made of all your systems, processes, uh, people, devices, and sort of what's the, what's the overall health.

And summarizing them in key findings is, uh, is always very effective.

Rather than saying, um, the firewall, for example, is running, you know, we've, we, we lost our subscription to updates and it hasn't been updated in, in six months, is that we're not getting current, uh, current, um, uh, antivirus, uh, uh, uh, measurements.

So anyway, those are the kinds of things that you don't wanna put in this snapshot.

It's really kind of summary and sort of outcome or effects that, uh, can be understood by your audience.

Uh, the third slide I suggest just kind of having a three-tiered risk overview.

Like, alright, this is sort of where we are right now, and, uh, what are the things that are high risk? What are the moderate risk, and what are the things that are, that are still in the low risk area? And ideally, as you're doing the, i I mentioned a couple slides ago that you do, you know, say a semi-annual calibration in those calibrations, it's good to kind of show like six months ago, this was our risk, uh, uh, overview.

Today, our risk overview is this.

So you kind of show, what was it last time we met? What does it look like now? It just shows the effectiveness of your plan, and it, it is easy to digest and it's comforting.

Slide four, uh, is your, uh, I said three year roadmap timeline.

This is a mu simpler view from that longer Gantt like, uh, table that I showed you.

It's, it doesn't have to be, uh, something that has a significant eyer on it, but this shows how you're sequencing, uh, items in your roadmap over time.

And you might even use some of the, you might even use a color coding program to show, um, you know, how our, uh, which of these items are for risk, which of these items are for modernization, or which ones are strategic enablement, the things that are aligned closely with what the school is trying to accomplish.

Uh, the fifth, uh, slide in your presentation, in your recommended presentation, uh, approach is showing the financial forecast I showed you at the, uh, like 10 or 12 slides ago, a fairly detailed one.

This might be just as effective because it, it's easy to digest.

It shows control as long as you can support it with like, backed up numbers if asked, this might be the better thing to, to put into the, to put into the roadmap than that, uh, 40 by 50, uh, grid, uh, month by month project by project expense chart.

Um, I mean, as I'm looking at this, I, I also think it might be helpful to show, uh, remember I talked about smoothing earlier.

It might be also helpful to show, like, how is, how are you approaching, how are you achieving, uh, expenditure smoothing, like a year on year smoothing? And, and you might, you might show that by year 2028, there's, in this one, there's very little variance in opex, but you might show that by 2028, that you've got, uh, only a 5% year on your variance and operating expenses that you're requesting for your, for your roadmap.

Whereas in 2026, that number may be more like 25 even higher.

So if, if there's something to, to brag about here, it would be smoothing.

And then finally, uh, I think I have six slides in this.

Yeah.

Uh, so finally, uh, what are the outcomes that the roadmap will bring? Um, you know, sometimes when we do sales calls, we, we start with, well, we're, when we're pitching our, our technology services to schools, we often talk about outcomes first.

Like this.

Like, we do these services.

And rather than tell you exactly how we do them or what's included in the services, let's talk about what you get out of it and what you get out of it.

Are these things.

Similarly, when you're presenting your roadmap, you're sort of selling, um, like a maturity in your thinking and alignment in your approach and stewardship of your expenses.

You're kind of selling that you're in control of those things to leadership.

And so here are some sample call outs of what outcomes you might be able to present.

By way, not literally, this is just in my example.

So, uh, you might be able to present outcomes that look like this.

By the time, um, by the, uh, time we hit the third year of this plan, we'll have a 40% reduction in major incidents.

We'll have complete alignment with insurance compliance.

And we all know that those, those requirements are getting a little tougher every year, and the costs are going out significantly.

If you are loose, um, you have now predictable device replacement.

Your, the, the ticket count volatility has gone down.

I, I don't care much for only relative or comparative words here.

So I don't know if I would say reduce ticket volatility as much as, um, lower ticket volatility by 50%, or, uh, increase, uh, support time available for projects by a hundred percent or metrics like that.

Uh, and then another idea here, because I brought up advancement and admissions as, uh, really data hungry and responsive customers, you might say there's some increased visibility or improved visibility and data, uh, that is being enjoyed by, by other departments in this case, advancement or admissions.

So kind of near in the end here.

So by the way, um, if, uh, I'd asked Jim that if you have any questions to, to interrupt, um, but we'll, or about, uh, six slides away, brought seven slides away, uh, from the end, and you'll be able to ask questions at that time.

So you take this approach, what does it look like to the leadership that you're presenting the roadmap to, well, to the head of school, it looks like you got your stuff together, like the department is now stable and you're focused on things that are meaningful to the school.

The CFO sees, alright, costs are under control and there's some foresight, uh, of, of the spending going forward, uh, that they may not have had in the past to a board of director.

It shows, alright, well there's some fiduciary diligence being enjoyed, uh, now by the school because of the work that you're doing.

'cause of the outcomes that, that we're seeing, uh, to faculty.

They see, they see fewer disruptions, they see, uh, more reliable systems in the classroom.

They see a replacement cycle for technology.

And they, they know, they don't see technology as a distraction.

They see technology as, as, uh, an allon as a partner in what the school is actually trying to do, which is educate students.

So, um, you know, when you, when you present a roadmap, avoid those things in the blue box, um, it's, no one's gonna care.

And it shows a, a lack of focus.

So I, I don't know why I picked those things, but, uh, well, because I've seen them.

So, uh, avoid those in roadmaps.

Like kind of keep it simple, keep it tight, uh, and keep it oriented to, uh, to the school's objectives and to outcomes that will be enjoyed.

Um, so I kind of have this in here as, alright, an effective roadmap actually gives maturity signals.

Uh, I'm not gonna read 'em 'cause I talked about 'em already, but here are some examples of maturity, some signals that a good roadmap shows, and it, a good roadmap shows that, um, uh, that your i, your it thinking, your plan, your execution is in fact strategic and it's, it's no longer, uh, reactive or it's significantly less reactive.

All right? So when you're putting together your roadmap, uh, I put this together as how, you know, how long would it take, uh, to put the roadmap together.

So I, I just have this 60 day, uh, this 60 day plan here.

And so this sort of follows, uh, this follows the, uh, steps that I talked about earlier, uh, days one through 15 discovery, then tech, the next 15 days technical assessments, then combining sequencing of financial modeling, the following, following 15 days and the last 15 days you're spending with polishing, uh, and leadership, uh, leadership reviews.

So, um, I, I, I have some meat to talk about what, what you actually do in the, in those sections, but just given time, I'll, I'll, I'll put that off for the for now.

Um, so once you have your roadmap, uh, I may have already talked about this, but, uh, not in these terms.

So once you have your roadmap, avoid these things that are gonna sink it, um, leadership will disengage and discredit you if they can't interpret, uh, the significance of the, of the plan.

So leadership thinks in terms of like risk and mission support and financial predictability and operational stability.

But if the roadmap looks like an IT operations manual, it's less relevant.

So instead of saying something like, replace the FortiGate for Fortinet FG 100 firewall cluster, uh, instead say, modernize security perimeter to reduce allergen cybersecurity risks.

So make sure that it's in terms of risk, mission, financial predictability, strategic alignment, stability.

Another mistake is, um, asking for too much.

So, uh, if the, if the roadmap includes everything that the tech director or CTO wishes they could fix, then it, it kind of reads that the le that the plan, it reads the leadership that the plan is not realistic or it's financially reckless.

So, um, it kind of signals like you're not, you're not either able to, or you've ignored the mandate to prioritize.

So instead, what works is that approach I gave you before, like, you know, start with stabilization, uh, then go to standardization, optimization integration.

So, you know, kind of work on a discipline of, of, uh, of sequencing that, um, that, that shows that you've got this broken down appropriately.

And, and by dependency, um, don't ignore, uh, the cost.

You what syncs a roadmap is, uh, is a, is a list of things to do without financial framing.

That is essential.

Your CFO is a primary even gate gatekeeping recipient of the roadmap and essential for it being valuable to the organization.

Um, don't flag everything as urgent.

'cause it's not, if everything is urgent, say it with me, nothing is.

Uh, and uh, another thing here is, um, years of advice here.

Don't surprise leadership with it.

Don't say don't start creed.

I suggest that you not create a roadmap.

Be very proud about it.

And say, go walk into the head of school's office, say, Hey, you know what, uh, I've built this technology roadmap and now let me review it with you.

You have to get a little bit of buy-in, let people know that you're doing it, what they're gonna get out of it.

Maybe even show them rough copies or, um, or early reads along the way and get some feedback into it.

That's a good way to get invited in to present the roadmap for the roadmap to actually be a valuable document of record.

Um, oh, I wish I would've rephrased this.

So the six signals that, the six signals that indicate, uh, uh, that this is a document of high trust, uh, i, I put here that it's connected to the school mission number one, that's so important.

It's calm, it's measured, it's rational, that you've prioritized well, that it's got good financial predictability.

It's focused on risk reduction and that you've got it.

You, you take it seriously by, by integrating it into some, some cadence of governance and, and review.

Um, I think when a roadmap has these elements, it communicates that, um, you understand how the institution operates and that you prioritize responsibly.

Like it's, it's, it is a really good document, uh, if it communicates clearly and, and manages technology effectively.

So it's not, it is, it seems almost like, I shouldn't have to say it, but it's not really as common.

What's common is to kind of create documents that show technical wizardry and technical mastery and kind of, uh, not be really connected to risk or mission.

And please do be connected to risk and mission.

Well, uh, that's it.

So, um, if you have any questions, type 'em into the chat and, uh, and I enjoyed, um, presenting that to you all.

Wishing to get some, see your faces, but I can't.

So, Jim, if you have any questions that came in, uh, you wanna arm? Yeah, I think one of the questions Tom would be about, um, you know, different independent schools have different technology departments and structures.

If a school doesn't have a CTO, uh, what are you typically seeing for creators of this roadmap? Okay, a few things come to mind.

Uh, right.

Uh, a lot of independent schools don't have, don't have a CTO.

Um, and, uh, I did put, uh, I did put the, you know, the plan kind of and couched it in terms of it.

If A CTO were writing a roadmap, these are the steps, uh, accurately.

It's take the CTO out, these are kind of the steps, uh, to write a technology roadmap.

So my advice would be, um, start by getting buy-in or an understanding of the receptivity of having a plan.

Sometimes heads of schools, um, they don't really want to be bothered by technology planning.

They, they want to think more about technology as a, um, as a necessary service that has to do with laptops and wireless.

Uh, so I think it would be difficult to come up with a roadmap at that time.

But what would be helpful is to start having conversations with leaderships about the school's, uh, the school's initiatives or the school's, um, primary objective, like is it, uh, is it attendance? I not attendance? Is it, is it admissions? Is it, is it, uh, that there's, that you, you, you've got a back, a backlog of students or that you've got slots open? Uh, is it that systems are unstable? So have conversations first about what the pains are around technology and keep those conversations with leadership away from, uh, defensive postures.

Um, the yeah, buts or discussions about firewalls or wireless standards.

Try to understand what the organization is trying to accomplish.

And my advice to you as let's say you're an IT director would be show that you're interested in the organization's, uh, objectives in their strategic planning and what they're trying to accomplish.

And then at some point in those conversations say, aha, I have an idea.

I have an idea where we can get more of these things that I have.

I have an idea, uh, ahead of school for us to be able to achieve these things.

Are you interested? And then you can start to build a roadmap.

And then Tom, there was another question around, um, how transparent does the technology roadmap need to be viewable strictly to the head of school and business officers, or even more broadly, across the leadership team, um, for example, development enrollment or division directors? Uh, I mean, I, this is probably a cultural question, but my, my initial thinking is that if it's the leadership team, this is a document to them, again, is trying to convey the things that are on the screen right now, uh, and leadership teams should be interested in all of those things.

Uh, if it is the culture of the school that it is not, then the department, then the, the roadmap is probably more targeted to the head of school.

Um, I mean, I've seen all kinds of schools that, you know, would or wouldn't really be receptive to this broadly, but this is not a document to be published, um, uh, more broadly.

Like it's not, it wouldn't be say a, you know, a a technology strategic plan that could be published on the technology website, for example.

And then maybe just like final question Tom would be around where this type of road mapping process, how that, um, supports a school strategic planning process, which is obviously more, more broad, not connected strictly to technology.

Um, what, how are you seeing them, um, you know, interacting with one another, engaging with each other? Any any thoughts or feedback on that? Yeah, you know, when I was a tech director, uh, I did spend a lot of time writing a technology strategic plan.

I, and I, if I remember right, I was asked to do that.

Um, and the, and the, you know, the, the technology strategic plan, you know, should kind of like be a document about vision.

It should be a document about, about, um, why and what.

Whereas the roadmap is more about when and how.

Um, so I, in my head, I think, okay, well, at the very top of the stack, there's a school strategic plan below that with respect to technology, there's a technology strategic plan, and then below that is the roadmap.

And below that are the projects that come out of the roadmap.

So, I mean, that's kind of the staff of, of how I think, I don't know that heads of schools always care too much about a technology strategic plan 'cause they have other things to deal with.

But what they care about, uh, is that there is a vision that there is a clear idea of why technology, and that's a really, whether that is published into a strategic plan or at least understood by the department, that's, that's an essential understanding.

It gives everyone in your department clarity on, focuses them on, oh yeah, we're looking this way and here's what we're trying to accomplish and this is what it means to teach and learn with technology and what it means to be a student here.

What they get out of it.

So I think that those things are important.

They don't have to be necessarily in a technology strategic plan and maybe a technology strategic plan shouldn't exist at all.

But one successful thing you could do is somewhere in that slide deck early, like probably slide one, if you don't have a technology strategic plan, then put the strategic objectives in that slide that talk about, um, why technology and what technology, what you're trying to accomplish.

Technology.

So I, I think that's probably a good separation of strategic planning and verbiage.

Uh, and this actual planning document, this document is not a strategic plan, it's an action plan and it better be, right.

Okay.

Uh, anything else, Jim, or wrap up there? I think that's it.

I'm just gonna pass it over to Kelsey.

Yeah, absolutely.

Okay, thanks everybody.

Tom, thank you so much.

This was incredible.

We really appreciate having a solid takeaway.

Um, and we are just grateful for your support and your contributions for, um, everyone in attendance.

Atlas is a 5 0 1 C3 nonprofit, uh, organization.

So we do rely on support of our vendor partners like knowing technologies to be able to do the programming we do.

And speaking of that, you will see Tom and Jim in Columbus, Ohio at our annual conference.

If you're not registered, uh, tomorrow is the deadline for early bird rates.

So I'm gonna drop that link, um, and you can certainly ask more questions of, um, the knowing tech team there.

Um, and with that, I think we can go ahead and wrap it up.

Thank you all so much for being here.

Thanks everybody..