Home improvement involves learning the related terminology and processes, and employing help where necessary. Chances are, so does your IT project.
I've long been fascinated by the building trades. Perhaps a career that's involved way more keyboarding than carpentry has given me an unhealthy interest in manual labor and the skilled trades, a condition that's manifested itself in my finishing a detached garage on our property that's been an empty hull since we bought the place. I have some basic competence in home improvement and have completed some minor carpentry projects, so I wasn't starting completely from scratch, but I also planned on doing the work "right" and obtaining all necessary permits and inspections, and trying my hand at plumbing and electrical work, trades I knew next to nothing about.
Much like an IT organization that's faced with a new technology or way of working, be it an emerging technology like IoT or a more organizational and philosophical process like DevOps, I was starting with a basket of preconceived notions, disjointed facts, and assumptions, about what the process entailed.
Sometimes the horror stories aren't true
Before picking up a hammer (which I shortly abandoned for a pneumatic nail gun), I faced the seemingly daunting process of applying for a building permit. Much of what I knew about permits stemmed from home improvement reality shows, with surly inspectors and unreasonable regulations. With my bias toward technical solutions to every problem, I spent days researching codes and sample permit applications and posting to home improvement forums before someone told me to simply call the building department. The staff were exceptionally helpful, and detailed exactly what was needed for my project, ultimately requirements that were far less onerous than what I was expecting. Even the permit approval itself took about 48 hours, versus the weeks I was expecting.
As your organization approaches unfamiliar new areas, try to reduce reliance on your old ways of working and your assumptions that may or may not have any basis in fact. Just because you've heard Six Sigma is "horrible," or that a vendor you've never worked with will be unaffordable, a simple phone call or two might leave you pleasantly surprised. Like my fruitless efforts to "research" my way through the permitting process when help from the source was only a phone call away, legions of third parties can probably help streamline your journey into the unknown and, like my county building inspector, might even have the unexpected belief that they're actually there to help someone accomplish their goals, rather than create roadblocks.
Weigh the value of experience vs. the value of your time
I was quite pleased to pass my plumbing inspections on the first try, especially since plumbing was right next to voodoo in my ranking of "dark arts" before I started this project. However, I probably spent nearly 100 hours on a job a competent plumber would have performed in fewer than five. From even a fairly low valuation of my time, this was the most expensive rough plumbing job in history, but going into the project I knew that would be the case, and I placed a high value on learning basic plumbing techniques and systems.
In your own organizational endeavors, there may be times when organizational learning and staff development are key goals and worth the high cost of knowledge acquisition, both in time spent and very low initial productivity. Going into the new area armed with this knowledge and expectation is perfectly fine; however, failing to value your staff's time and the cost of learning can make for disaster later. As with my plumbing project, it might take you months to do internally what you could do with a vendor at commodity costs, resulting in moderately skilled staff but a market that has moved on and left you in the dust. In either case, don't use cost as the sole metric. Sometimes skill building is more important than dollars and hours, and other times, buying a "trade" in the open market will allow you to move toward more interesting endeavors.
As I went through my project, I'd often post pictures to various online forums, particularly when I was doing something new like wiring my breaker panel. Within hours I'd get feedback when I'd done something incorrectly or sub-optimally, and I was able to correct my process before performing a repetitive task, ranging from building a wall to wiring up an outlet box.
As you build competence in a new area, employ experts with knowledge in the area to "spot check" your progress and help you course correct along the way. It's tempting in IT, especially organizations used to waterfall-style delivery models, to wait until large portions of a new system or process are constructed to validate the results; however, this can be time-consuming to correct. Implement a tiny piece of DevOps or a new mobile app, check it with an expert, and then apply the learnings to the next piece.
Call in experts -- but not all the time
There are some areas of my garage project that I'll be outsourcing. Hanging drywall, for one, requires significant labor combined with a bit of an artist's touch, and when the latter is absent you're left with wavy walls that will last forever. I also outsourced wiring of the electrical subpanel, since that required dealing with the main electrical feed to the house, and 200A of juice that would drop me dead in an instant. Too many organizations fall into a trap of "either/or," insisting that all activities be performed in-house, or that everything go to a vendor. Break a new endeavor into component pieces and make the right choice for each one based on factors like risk, time, skill required, and difficulty of execution.
Whether you're building a building or changing how your IT organization works, taking a thoughtful approach and considering the goals of each step of the process will create a better end result that balances your desire for speed, organizational learning, and quality.
6 lessons your organization can learn from Google's help systems
Getting into the IoT game? Your business needs a well-defined use case first
8 tips for building tech leadership skills
Transition between IT projects like a triathlete