Learning SharePoint in a Day: Building a System in a Week

Every week in the leadership meeting, I was asked the same question: "Do we have the vehicles to cover this week's training events?"

Every week, I gave the same answer: "I'll send a follow-up email once I get the information."

I hated that answer. My vehicle coordinator was constantly managing crises, and I had no visibility into our fleet status. We were operating blind, one breakdown away from cancelled training.

After the second week of "I don't know," I decided to stop waiting for someone else to solve the problem. The contractor we paid to build SharePoint solutions said it would take a month. I asked for the permissions and built it myself in less than a day.

Then I learned automation, built a forecasting system, and turned crisis management into predictive planning. The contractor was shocked. He should have been, I also controlled his contract.

The Problem: One Person, Fifty-Plus Variables, Constant Crisis

When I took over the Operations Department at the EOD Training and Evaluation Unit in June 2023, I inherited responsibility for managing the command's vehicle and boat fleet. This wasn't a small operation. We had:

• 50+ vehicles of three different types

• 4 operational boats

• 2 jet skis

• 2 forklifts

The fleet supported a command of 130-145 people conducting continuous training operations. Teams needed vehicles for tactical EOD training, boats for maritime operations, and specialized equipment for various scenarios. Availability directly impacted our ability to execute the training mission.

We had one person coordinating this entire fleet, and he was a rock star. But there was only one of him, and he was always fighting fires. He might have one or two temporary assistants at any given time, but he was the single point of knowledge and control for a complex, dynamic system.

The complexity came from the three different vehicle types, each with completely different administrative requirements:

Rental vehicles: Actual rental cars under 1-3 month contracts, requested as needed based on funding availability. The number fluctuated constantly.

CESE vehicles (Navy dispatch system): Typically Light Service Support Vehicles, modified F-150s with Navy-specific modification kits, painted to military standards. These came through the official Navy vehicle dispatch system.

GSA vehicles: Leased through the General Services Administration with their own contract terms and service requirements.

Each type had different service schedules, different payment processes, and different administrative burdens. Tracking maintenance, availability, and allocation across these three systems made the coordinator's job extraordinarily complex, especially without steady support.

The Weekly Embarrassment

The breaking point came during leadership meetings. Every week, the Commanding Officer or Executive Officer would ask about vehicle availability for upcoming training. It was a reasonable question. Training schedules were planned weeks in advance, and vehicle support was a critical enabler.

And every week, I couldn't answer. My vehicle coordinator was handling whatever crisis had emerged that day, a breakdown, a service issue, a scheduling conflict. He had the information somewhere, but it wasn't organized in a way that allowed quick answers to planning questions.

After the second week of sending follow-up emails instead of providing immediate answers, I called him into my office with the complete list of our vehicles and boats. He didn't directly manage the boats, but I had him get that information too.

I created an Excel spreadsheet. We listed every vehicle, sorted by type. For each one, I documented:

• Who it was checked out to

• When the next scheduled service was due

• How long that service would take

• When it was due to be checked back in

It took a few hours, but suddenly I had a snapshot of the entire fleet on one page. It was better than nothing, but it was still static. The moment someone checked out a vehicle or a service date changed, the spreadsheet was outdated.

The Contractor's Timeline vs. Reality

We had a contractor whose job was to create SharePoint pages on our command portal. I took the spreadsheet to him and explained what I needed: a dynamic system where we could track vehicles in real time, see availability at a glance, and forecast support for upcoming training.

He told me it would take about a month to build because of his other work commitments.

A month was unacceptable. I couldn't give the Commanding Officer useful answers for another four weeks while we paid someone to eventually build a solution I needed immediately.

I asked for the permissions to build the SharePoint page myself. I told him once I had the basic structure operational, I'd come back to him for help with analytics and automation.

The next day, I had the SharePoint page built.

Learning on the Fly: From Static List to Predictive System

I had never built anything in SharePoint before June 2023. My only exposure was seeing it used for Crisis Response Force reporting years earlier. I learned through YouTube videos, trial and error, and sheer necessity.

The initial build was simple: I recreated my Excel spreadsheet in SharePoint with metadata for each vehicle. But SharePoint's power comes from what you can do with that metadata once it's structured correctly.

I learned how to write conditional formatting rules to color-code vehicles based on their status:

• Green: Available and current on service

• Yellow: Service due within two weeks

• Red: Overdue for service or unavailable

I created a dashboard view that showed fleet status at a glance. I synced it with the training calendar so we could see vehicle allocation against upcoming events.

Before this system, I couldn't plan for the current week. After building it, I could forecast vehicle support, maintenance windows, and float capacity for the next year.

Then I learned automation. I set up rules to automatically notify the people who had vehicles checked out about upcoming service and check-in dates: 14 days before, 7 days before, and 1 day before they were due.

Suddenly, I didn't need my vehicle coordinator to track down people and remind them about deadlines. The system did it automatically. He could focus on actual coordination and problem-solving instead of administrative follow-up.

More importantly, nobody needed me to tell them if we had vehicles or boats available. Anyone with access to the portal could see the dashboard and know immediately what was available, what was in need of service, and who they were allocated to.

The Forecast That Changed Planning

The real power of the system became clear during resource planning. Three months before high-tempo training periods, we could now see exactly what our vehicle capacity would look like. If we were going to be short, we had time to request additional rental vehicles or GSA leases.

We could also identify maintenance windows strategically. Instead of vehicles breaking down during critical training periods, we could schedule preventive maintenance during slower periods when the impact would be minimal.

A specific example: We had two training teams going through underwater training modules simultaneously, which meant four different EOD teams needed boats. Two teams from Guam were using the training unit's operational boats, leaving only two boats for instructors.

One of the boats went down. We didn't have a float boat on standby, so we scrambled to get access to another boat and managed to keep training on schedule. But it was a crisis response, not a planned solution.

Had I been able to see the scheduling conflict in advance through the system, we could have arranged to have a backup boat on standby before the breakdown happened. Four months later, the same situation occurred, but this time we were ready. No crisis, no scrambling, just execution according to plan.

The Contractor's Reaction

When I showed the completed system in the next leadership meeting, people were shocked that I had built it with no prior experience in less than a week. I just called it work.

The contractor's reaction was more complex. He was surprised, certainly. But he was also uncomfortable. He was being paid specifically to build SharePoint solutions, and I had just demonstrated that his timeline and his expertise weren't as essential as he believed.

What he didn't know at the time was that I also controlled his contract. His comfort with the status quo, confident in his job security, willing to make people wait a month for urgent solutions, became a problem I needed to address.

I started looking for someone better. Eventually, that search concluded successfully, though that's a different story.

The Broader Impact: Self-Reliance Over Dependency

The vehicle and boat tracking system did exactly what it was designed to do: provide real-time visibility, enable predictive planning, and automate administrative follow-up. But it also demonstrated something more important about organizational effectiveness.

Waiting for someone else to solve your problem is often slower than learning to solve it yourself. The contractor had the technical expertise, but I had the operational urgency and the authority to prioritize the work immediately.

By learning SharePoint and automation on the fly, I didn't just build one system. I built the capability to create solutions for other problems as they emerged. The vehicle tracker was the first of several systems I would build over the next two years, each one adding to the command's operational visibility and efficiency.

More fundamentally, the experience reinforced a principle I've carried throughout my career: don't let someone else's timeline dictate your ability to execute. If the solution is achievable and the need is urgent, find a way to make it happen yourself.

What This Means For Your Organization

Most organizations face a version of this gap: operational needs that IT can eventually address, leaders who are waiting for IT, and a slowly widening window of inefficiency in between.

The lesson isn't that every leader should learn to code or build SharePoint environments. The lesson is that the leadership decision, "I'll learn enough to build this myself," is available to you more often than you think, and the cost of learning has dropped dramatically.

Modern no-code and low-code tools (SharePoint, Airtable, Make.com, Power Automate) have collapsed the skill threshold for building operational visibility systems. A manager who spends two days learning the tool and two days building the system is often faster and more cost-effective than a six-week IT project with competing priorities.

More importantly: leaders who build their own tools understand the data differently. They know what the system can and can't track. They catch errors before they become decisions. They maintain the system because they understand it.

If you're waiting for an IT solution to give you operational visibility, ask yourself: is that a technical problem or a prioritization decision?

The Takeaway: Learn the Tools, Don't Wait for Experts

I wasn't a SharePoint expert when I started. I'm still not a developer or IT professional. But I learned enough to build functional solutions that solved real operational problems.

The barrier to building digital solutions is lower than most people think. The tools exist. The tutorials are available. What's often missing is the willingness to try, fail, iterate, and learn in real time.

In my next role, I'm looking for organizations where this kind of initiative is valued: identifying problems, learning the tools needed to solve them, and building solutions without waiting for permission or perfect expertise. The future belongs to leaders who can translate operational needs into digital systems, not leaders who wait for IT departments to eventually get around to their requests.