A large number of CEOs have lost faith in their IT department. Too many projects go off the rails, plagued by budget overruns and costly delays. Worse, precious few tech projects actually create meaningful value for the business. It’s not uncommon for companies to devote millions of dollars to a behemoth, multiyear technology initiative — only to wind up writing it off as a failure. And perhaps that’s not so surprising. The failure of IT projects isn’t due to a lack of talent or skill. It’s systemic.
Most IT departments simply aren’t set up to deliver great software. The architects and project managers aren’t connected enough to end users (whether employees or customers), project leaders are skeptical that complex projects can be chunked into potentially shippable increments, and execution therefore focuses on a risky “big bang” release. By embracing a new approach to IT, teams can design projects that create tremendous value for the business — and deliver results that CEOs will love. 5 strategies to transform it projects
Although big corporations have begun to embrace agile for their customer-oriented products, large and costly back-office projects — such as enterprise resource planning, human capital management, and supply chain management — are still being managed with the same methods that were popular more than 20 years ago. By changing their approach to such projects, companies have the potential to save millions of dollars each year and free up resources for new business initiatives. To escape the quagmire of overpromising and underdelivering, IT departments need to completely reinvent the way they manage projects. Start with empathy.
It’s in digital startups’ DNA to test concepts with users before launch. Teams observe users interacting with digital technologies, identify moments of frustration or delight, and find ways to create a unique and differentiated experience that users will love. This approach is entirely sensible — and shockingly rare in corporations. While many organisations give lip service to the importance of the customer, relatively few continually engage with real-world customers and employees to test concepts and solicit feedback.
To build great products, teams need to start with empathy. Do you know where users are feeling burdened, confused, or frustrated? And where they’re feeling excited, engaged, and delighted? One of the best ways to gather this data is through firsthand observation. Consider this: teams create a detailed plan to deliver multimillion-dollar projects that span a multiyear time horizon, but they don’t have time to test their assumptions with real-world users?
It should be common practice for executives, IT teams, and others in the business to observe the habits and preferences of customers and learn how they engage with products and how they weigh tradeoffs when making decisions. It’s not enough to rely on business analysts who have conducted a few interviews. The project team needs to engage with potential users through ethnographic research, focus groups, and other techniques and then leverage the insights gained in the design of large-scale IT projects. This kind of deep engagement with customers not only helps companies address pain points but also allows them to better anticipate unmet needs. Start small.
Agile development has been a hot topic for several years and numerous companies have embraced its basic principles, but many are still surprisingly hesitant to use it in big projects. This is a shame, since big projects are often the ones that need agile the most. With agile development, cross-functional teams can quickly develop a minimum viable product, test it on real users, and iterate based on what they learn. Oftentimes, IT teams will argue that a project will cost more if it’s delivered in smaller pieces, rather than all at once. But the risk of committing to a massive IT project, without testing and learning as it evolves, is enormous.
Rather than developing monolithic projects, it is usually better to divide projects into small, manageable chunks. The chunks will vary in size and can be delivered every few weeks or months, depending on the project. Roadmaps can help focus efforts on improving key performance indicators (as opposed to delivering features over time), with precise metrics used for the coming quarter, less precise metrics for the year, and purely indicative metrics over the long term. Don’t expect a precise business case upfront.
In today’s digital environment, the encyclopedic business case is entirely counterproductive. While business cases may be crafted with the best intentions, they are completely unreliable and often pointless. But because many executives are not fully comfortable with IT, they believe that the business case is the best way to keep projects in check. And IT teams, eager to move forward with the project, do what is required to gain approval. As a result, no one admits that the emperor has no clothes.
At the early concept stage, estimates of costs and potential revenue tend to be highly inaccurate. Estimates of projected cost savings over time tend to be more precise, but these metrics are rarely tracked after launch, which means that they carry little weight. Knowing this, teams have a built-in incentive to be overly optimistic about the project’s potential benefits (and costs).
To break out of this cycle, executives can request a simple, straightforward, almost back-of-the-napkin tally of immediate and long-term costs and value to the business. The team then goes off to build a mockup or a prototype that can be tested with users, knowing that it will meet with the executives again in three months to provide more data, user feedback, and customer insights. In essence, the team builds a business case from the ground up, testing, learning, and releasing new features in response to user input. By allocating dedicated teams to a project over an extended period of time, and thereby shifting from fixed budgets to fixed capacity, companies can simplify their finances. Business leaders track the results, observe successes and failures, and continue to evaluate the project as it evolves. If the project fails to deliver on its promise, they can cut it off before too much time and money are lost. Think differently.
To create unconventional and disruptive products, employees need to think differently. Teams quickly become accustomed to working in conventional ways and requesting products and tools that build incrementally on what has come before. Too often, pain points are only superficially analyzed and root causes are ill-defined. This is not a recipe for breakthrough products.
Employees need some freedom and incentives to think creatively about product development. Software developers often have pet projects that they pursue after hours, in the evenings and on weekends, driven purely by their passion. Companies need to create opportunities for employees of all stripes — senior managers, middle managers, business analysts, designers, IT architects, and software developers — to harness that passion in their product design and development process.
While it may seem counterintuitive, constraints can be used to very good effect. Think of the beautiful simplicity of successful mobile apps, compared with the overwhelming complexity of many enterprise software tools. The process of overcoming obstacles and limitations often sparks extraordinary creativity and problem solving, which is exactly what’s needed to create superior products. Build a culture of transparency — especially around setbacks.
By their very nature, IT projects are often large, complex, and prone to unanticipated setbacks and delays. When we audit such projects for our clients, it is commonplace for team members to acknowledge that they knew the project wouldn’t deliver on its promise, but they failed to communicate that to their managers.
This isn’t entirely surprising. Project managers are the people most accountable for the project’s success — and they know it. If the project begins to falter, they will likely scramble to recover, investing even more resources to make up for lost time, which pushes the project further into the red. In their interactions with management, they may be tempted to project a can-do attitude, highlight the small successes, and gloss over the mounting setbacks, hoping all the while that the project will rebound.
This is no way to run a project. In project management as in politics, the coverup is worse than the crime. It can be okay for a project to be three months late, but not if management only hears about it one month before the project is scheduled to go live. It’s okay for the initial release to receive a tepid response from users, as long as there’s an understanding of why and a plan to test, learn, iterate, and improve. Executives cannot praise the “fail fast, fail often” startup culture and then hammer employees when they do fail—and this kind of culture change must be driven from the top. With the right culture, where transparency is rewarded, disappointing results allow companies to make better, more informed decisions at every stage of development.
Digital strategy has become a top priority for CEOs, but most IT projects are highly complex and costly, and CEOs have limited visibility into the details of major decisions. This is an uncomfortable place to be. From the CEO’s perspective, the IT department can be more of a black box than just about any other aspect of the business, and most have been disappointed with results more than once. But it’s important to note that CEOs have an important role to play, because teams need support from the top as they adopt these new methods. Therefore, it’s incumbent upon the CEO to foster an organisational culture that supports experimentation, tolerates setbacks, and focuses relentlessly on customers’ needs. With a supportive organisation behind them, IT teams are well positioned to develop products that users will love — and IT projects that CEOs will love.