2.01: A Boomer Made Me Learn SharePoint

Our ODA team stencil on the War Room we built in our mud hut in the village. Author’s photo. Afghanistan, 2011.

His name was Dan and he was a retired SF warrant. There is a very good chance I never would have gotten up to speed on SharePoint without him. When we met, Dan was in his 50s and on his second career working in our lessons learned section in the basement of 1st Special Forces Group. I’d just left my detachment and was thrust onto a staff for the first time in my military career.

As the new AS3 at the Group headquarters, Dan was quick to pull me under his wing and offer some mentorship.¹ While his actual job was in capturing the latest lessons from the force, somehow he’d become our unit’s subject matter expert on SharePoint. In fact no one knew more about how to use it across for the entire headquarters, surpassing our actual Knowledge Management representative.² As a self-proclaimed data nerd and a young cocky captain, the idea that a military retiree knew more about computers kind of stuck in my craw.

I started by asking Dan a lot of questions, for which he showed an unflinching patience. Whatever he didn’t know he was happy to help me tinker with until we both figured it out. Google and YouTube became regular tutors, ones I still rely on today.

SharePoint was the first time I really stepped into using networked data.³ Excel was an old friend by now, and my earlier foray into Access had helped me as an XO back in 2006. But SharePoint allowed me to see what could be done when a bunch of different people were interfacing with data at the same time, instead of one-at-a-time in serial.

That’s not to say that it’s perfect. SharePoint is not as user friendly as a lot of other systems, and at least in the Army, the default permissions are set to simply ‘No’. If Dan hadn’t been on hand to give me design rights, I probably would have given up at that first three-foot-wall.⁴ Instead, I set out to solve a problem that had annoyed me since I was a brand-new team leader: the Mission Planning Guide (hereafter MPG).

The MPG was ostensibly a one stop shop document that showed you everything you needed to plan anything from a Joint Combined Exchange Training to an off-Post Training event. Except the MPG existed in dozens of versions across dozens more places on the various hard drives that made up the three special forces battalions in our group. There were easily 50 different copies of the guide, and probably no more than five agreed with each other. Every time a new file version or template was rolled out, copies would spread like a slow-moving infection from team hard-drive to team hard-drive. But old versions lingered, and at times merged with the newest updates. The result was a lot of kicked back paperwork in a process that already took up to 120 days to process in most cases.

After Dan showed me what SharePoint could do, I immediately saw the MPG as a great first project to take on. Instead of squirreled away on hard drives, we could create a single stop for the latest version of every single document format as well as an inline how-to guide. As we implemented changes the updates would go into those templates on the portal. As long as a team always started from that base, they’d always be confident they’re paperwork was current.

Just that single change, making a single, central repository for documents, would see an immediate improvement in staffing time. I’d learned over my time in detachment command that not having a single point of reference costs you three times as much time. There’s cost in doing it the wrong way, the time it takes to identify that and to notify people they did it wrong, and the time it takes to do it all over again. I’d also learned that if you tried to keep the same data in more than one place, they will never agree with one another. Just the simple act of making a single point of reference would see as much as a 400% improvement in efficiency.

It was Dan who prompted me to take my plans a step further. I’d started out just building a reference portal for all the existing templates. The work was impactful, but minimal effort. In fact, the only real innovation I’d added was an excel spreadsheet that helped teams track their suspenses. Most packets required as many as 50 different timelines for various paperwork. Ammo requests, training schedules, risk assessments, they all had some sort of D-date associated with them. If the team input four dates into the top of the spreadsheet, it would enable them to print out a single 8.5” x 11” page that they could hang on their door which would tell them when every single sub-step was due. It was a nice feature, and even got me my first compliment from a team sergeant in my new job. But it wasn’t exactly novel.

Dan asked me, since we were making a single site for every team to come get the templates they needed, why couldn’t we make that same site be the spot teams submitted them? The idea sounded genius to me, but it was also revolutionary. Not exactly in the ‘this will change the world’ sort of way, but definitely in a ‘the landed estate is going to fight you for trying to change this’ way.

The existing process was to print all those 90 plus pages of paper out and mount them in these complicated document folders with tabs and three-hole punches. Once properly organized, the binders were given a tracking coversheet stapled to them where two dozen various staff officers to initial off when they had reviewed the packet. The packets weren’t reviewed in a meeting, or digitally, but instead by methodically walked around from desk to desk in the headquarters. Very often (always) packets would be lost, so we had a large green paper notebook log that ostensibly would be updated to track the status of each one. Assuming the notebooks were kept updated (they weren’t).

This was why the packets often had to be submitted up to 120 days out. Just so they could get lost or wait in a paperwork inbox until they were a big enough priority. As the AS3, stewarding these packets was a big part of the job, and I learned quickly who were the most likely candidates for lost packets (the lawyers office was my first stop). Everything worked in serial. The tools were driving the process, not vice versa. It was slow, but worst of all, we lost a lot of paperwork, requiring teams to redo and restaff it all. It should surprise no one to hear that everyone hated the current process. But it might also surprise you to hear that everyone also really didn’t like the young captain trying to change it.

What followed was about three months of experimenting, testing, and learning. I learned a lot about how to use SharePoint lists and document libraries. But I also learned my first key lesson in innovation: the importance of allies.

1. Assistant Operations Officer. Army staff sections are known by their numbers. 1 is personnel, 2 is intelligence, 3 is operations, 4 is logistics, 6 is signal. There are more, but it all gets complicated pretty fast. These are the main ones.

2. I’ll write more on KM later in 3.5.

3. Sharepoint is a web-based collaboration platform that integrates with other Microsoft apps. Most Army units have it available to them, though some have migrated to MS Teams (which is really just SharePoint with a better Ux).

4. A three-foot-wall is a metaphor for problems people should be able to solve themselves but won’t. You can see over the wall, and with almost no effort can just lean your way over it, but nope. It’s just too hard.