If You Build It, They Might Not Come
Updated: Oct 24, 2020
It’s December 2019, and many organizations have finalized their IT governance portfolios for the 2020 budget planning cycles. These portfolios invariably contain project profiles that address required annual maintenance, end of life system replacement, a pet project or two from the business and often, a new or ongoing swing-for-the-fences digital transformation initiative that if successfully delivered will have enterprise-wide implications and the potential for tremendous ROI.
Why is it that these latter project types are so frequently late, over budget, or characterized by watered-down results? Or delivered by an eager IT department only to see the solution underutilized by the business? Or begrudgingly accepted by the business because they are forced to substantively adapt the organization or operational processes to actually use the new tools they’ve been given?
It may nearly be 2020, but the game hasn’t really changed: if you build it, there’s a strong possibility that they won’t come. In 2017, the Project Management Institute determined that 39% of IT projects did not meet their goals, 43% went over budget and 49% were late. The likelihood that this cycle will be repeated next year, across multiple industries, is as high as it was before the introduction of software delivery methodologies like Agile, Scrum, XP & Lean.
And yet, project delivery models that sufficiently incorporate holistic people, process, & technology considerations have lost traction in the face of rapid development cycles. The pendulum has swung from old school, slow, Waterfall-style project delivery with heavy emphasis on up-front documentation to iterative development sprints producing light documentation that accompanies working code. That shift sounds promising, but the failure rate remains very high for a number of reasons, among them the desire to build something simply for the sake of building (or because it’s cool/fun) as opposed to asking a handful of key questions:
· Why this?
· Why now?
· What are we missing?
· What’s likely to fail?
What’s Old is New(ish) Once More
64% of respondents to PwC’s Global Digital IQ Survey confirmed that lack of collaboration between IT and the business hinders digital transformation; 58% of respondents indicated that slow or inflexible processes were to blame. What’s frequently lost in today’s project funding & planning exercises are organizational considerations that can include good old-fashioned fear of change, interdepartmental politics, a lack of a sufficiently senior project champion, or a bridge-building program oversight philosophy that brings all aspects of the enterprise along for the ride.
So how to break the cycle? How to ensure that once built, they will come?
Enter The Brain Trust
In 2019, IT departments with multi-million dollar capital/operating expense budgets frequently lost sight of the value that a seasoned multidisciplinary team brings to enterprise-level digital transformation. This brain trust advises (and can act as a surrogate for) the executive champion of the project, advocating on behalf of the business who must adopt and ultimately, live with the project result. This group is a credible liaison to the CIO/CTO, a vigilant watchdog for the CFO, and a surrogate for the CEO & COO who lead the business.
The brain trust also acts as an insurance policy of sorts. While nothing is guaranteed in enterprise software development, their multifaceted focus on three old school fundamentals addresses the issues that continue to plague projects:
· People: the organization, the client, the adopters
· Processes: what’s known & entrenched as well as what is still effective
· Technology: is this the right solution for this business today?
People – a.k.a, those who must live with what’s been built – are invariably the wild card and organizational change management (OCM) is the key to addressing this unpredictability. Knowledgeable practitioners will take the time to understand where resistance lies, ferret out fears about job security, process & tool adoption issues, and identify legacy interoffice politics to inform their project rollout strategy.
Processes – business process re-engineering has long been a consideration within a digital transformation initiative. In recent years, though, what seems obvious in hindsight has often been overlooked in the pre-project work. Legacy processes have often been battle-tested over time, and the frequent desire to introduce a fresh model in conjunction with new technology rollout can overlook process steps that are both worth keeping and sometimes, essential for operational continuity.
Technology - it’s worth noting that the technical heart of digital transformation lies in its enterprise architecture – and often, it remains a significant point of project failure. In a 2016 survey conducted with Henley Business School, McKinsey noted that “when companies go all in on digitization, the number of point-to-point connections among systems rises almost 50 percent, the quality of business-process documentation deteriorates, and services get reused less often.” A considered enterprise architectural design will reduce unnecessary complexity, increase pragmatic reuse, and enhance consistency across the enterprise.
A capable brain trust must to be able to simultaneously balance all three of these elements, sometimes in equal measure and other times, emphasizing some at the expense of the others. If such a group of individuals does not exist within an organization, executive leaders and IT portfolio owners are encouraged to engage external experts who can act in this capacity - ideally, prior to finalizing the 2020 budget and without question, prior to project inception. Early involvement, guidance, and engagement from this team of experts can make the difference between another compromised project or realization of that swing-for-the-fences initiative next year, the version to which they do come.