Don't take the next step in a project just because that forward momentum is comfortable—it can actually be a recipe for failure. Here is how to prevent an embarrassing project defeat.
As leaders, at some point most of us have been directly responsible for executing a complex project. This was likely an exciting role—dozens or even hundreds of staff were dedicated to the effort, and we were the prime person directing significant company resources at a complex problem. Some aspect of that program likely had a tech component, and we likely spent countless meetings and whiteboarding sessions marshaling resources, overcoming technical hurdles, and ultimately watching as systems were activated, integrated, and hopefully, deployed successfully.
With any endeavor worth doing, there's always a possibility of failure. Unless you've spent a career sticking to what's safe or have been extremely lucky, you've likely encountered a failure or two along the way. Perhaps the worst type of failure is when you successfully execute a project, perhaps even completing the stated objective on time and under budget, but it ultimately doesn't meet its goals of revenue generation, user adoption, or some other factor that might even seem somewhat outside your direct control. These failures can be expensive and public—most of us remember the Amazon Fire Phone, Google Plus social network, Microsoft Zune, or the most infamous of them all: New Coke.
SEE: Hiring Kit: Project Manager (TechRepublic Premium)
In each case, exceptional people with significant resources produced technically well-executed products; however, they failed to understand the market, customer tastes, competitive landscape, or a complex combination of many factors. While it's easy to scoff at these high-profile examples as something that can't happen to us, most of us have been on a project where it seemed there were complex, lingering questions about whether the project was ultimately targeting the right outcomes. While these questions might be floated among a handful of people after hours over a cold beverage, they were quickly swept under the rug or devoutly ignored in public forums.
The problem with action
In most cases I've experienced, it can take weeks, months, or even years to build the organizational momentum to execute a large project. There are countless meetings, impassioned pitches to executives or board members, and long evenings poring over spreadsheets to get the numbers and timeline just right. Some of the complex questions about whether end users or consumers actually want the product or project are easily deferred to a phase zero after the hard work of getting organizational approval to proceed is garnered.
SEE: Chasing hankos: How to handle those who struggle to accept change (TechRepublic)
Once that approval is won, there's a bias toward action--in particular action that's public and comfortable. Interestingly, complex and challenging tasks are often where we find comfort, since they're dramatic and exciting, use and publicly display our long-honed skills, and win the aplomb of peers and bosses.
For tech leaders, implementing technology is right in that comfort zone. Even if it's complex, we'd rather corral a dozen vendors and our best technicians to solve a technical problem than be the lone voice standing in front of an accelerating train asking if customers really want what we've finally decided to fund and build. Multiply this effect across several teams and dozens of individuals, and you've created a momentum that's largely unstoppable.
Give yourself an exit ramp
Rarely are individuals being malicious when they fall back on their core talents and attempt to impress their peers through action once a project begins. To avoid this natural tendency, design exit ramps into your program, starting with the very first activities once funding is approved. Part of what contributes to these grand failures is funding and approval cycles that are all-or-nothing, or perhaps fund a tiny pilot of MVP version of a project, and then assume that's good enough and fund an effort that's magnitudes more complex.
SEE: How to actively build and maintain culture in a remote workplace (TechRepublic)
Break complex and expensive efforts into chunks, with the stated objective for each chunk being that you'll attempt to answer the hard questions around whether your product or project can actually succeed in the market versus attacking the exciting and dramatic (yet ultimately low-risk) actions associated with implementation. Despite the sound and fury of a complex implementation, it's usually the least risky aspect of a broader program assuming you've done large implementations before, have a reasonable program management approach, and have filled in any skill gaps from the hundreds of specialist vendors that can help.
Don't let the siren song of action lull you into a false sense that the more you do, the better your chances of success. Rather, spend the first weeks of any program asking the hard questions about what value it will bring to end users or consumers, how you'll encourage them to buy or adapt your product, and how and why you're the right group to deliver. Those questions might take a couple days or months to answer with some degree of certainty, but doing that diligence will ultimately avoid falling victim to the action problem.
- How to become a CIO: A cheat sheet (TechRepublic)
- Top 5 programming languages for systems admins to learn (free PDF) (TechRepublic)
- New Employee Checklist and Default Access Policy (TechRepublic Premium)
- ZDNet's top enterprise CEOs of the 2010s (ZDNet)
- CXO: More must-read coverage (TechRepublic on Flipboard)