At Skyway, we run our operations side with a simple adage: “Make sure we know how it works so we can fix it if it breaks.” I adopted this concept from a podcast episode by Andy Stanley. The concept is simple enough, but it’s not always easy to implement.
We recently did a major overhaul to our Skyway Community website. As our members know, the Skyway website is the backbone of the content and support management system for our members. We have invested heavily in the design and integration of the website over the last two years, but now it was time to increase the “bandwidth” of the website by upgrade our hosting service and increase our server capacity, storage, and website speed.
Here’s the catch though. We are not website gurus so making this transition smoothly was going to require some help. As we brought in experts in website programming and “URL transition”, we learned that we didn’t know what we didn’t know. Some of the challenges we had on the site (like having to upload our webinars to YouTube instead of directly onto the site because of their size) were problems we had built into our website because we, at the time, did not know what a complex, membership-driven, responsive and robust website took to manage. We thought we could just build the base layer and keep stacking on content. As you can guess, that is not the case. It rarely is.
We then spent a few months executing a plan to rebuild the website with a much larger “foundation” that we can now build upon. This took longer, cost more, and drove me a little crazy. On a side note, I recently learned on an episode of a Stanford Entrepreneurial Thought Leader Podcast that this is called “technology debt”. It happens when we built in inefficiencies for the sake of speed that we know we’ll have to correct later. However, as I have mentioned in social media and elsewhere, upgrading our site was a “one-step-backward-and-ten-steps-forward” kind of experience. We learned how a lot of the processes on our website did not work like we thought, and it cost us precious time and resources to fix them after they broke.
I tell this story because it reminds me of many parallels between our experience and the administration of government contracts. As a CO, the most extreme learning happened when something “broke” on our contract, such as
- The Statement of Work did not clearly identify the desired result and the contractors’ interpretation did not match the customers (even though the customer wrote the SOW)
- The schedule did not account for the travel time to ship the product from the plant to the dock for deployment
- The previous CO used acceptance “at origin” and the new customer (and me as the new CO) planned for acceptance “at destination” which created a payment lag for the contractor of three weeks
- The contractor was not getting paid for $300,000 in deliveries because they did not know how to manage Wide Area Work Flow (the DOD-wide electronic invoicing system), resulting in them running into cash flow issues and having to get a line of credit to make payroll
- The previous contract specialist committed the project funding on the wrong CLIN in the contract, so the contractor’s invoice bounced
These are just a few of the things that “broke” while I was a CO. When we didn’t know how they worked in the first place, it was much more difficult (and in one case impossible) to fix them after they broke. Some I knew how to fix from experience. Some I had to lean on the experience of our fellow COs to fix. Some I could not fix because it was already too late due to fiscal year funding rules (see Color of Money webinar for more details).
If both I (as the CO) and the contractor clearly understood what was in each contract and how to fix it ahead of time, we would have avoided some of these problems. I see that now…and that is why I focus on our members being proactive in their contract management.
After all, you need to know what’s in your contract.