In Part 1 of this blog, I argued that although IT and business leaders have different perspectives of the same situation, they both want the same things. And while I use the phrase “marriage counseling” somewhat tongue-in-cheek, this really is a serious problem most companies must overcome.
So how can IT and Business reconcile their differing perspectives? Much of what needs to be done (as my colleague Justin Lake discussed in a previous post) involves cultural change. But let's face it: culture change is hard, and companies can't just change overnight. So, let's not think about changing the entire corporate culture – let's think about some things that companies can do to develop a new collaborative mindset between IT and Business.
Think “Succeed Small” instead of “Fail Fast”
As my colleague Justin aptly described in his blog, “every week, another executive is telling us they’re being challenged to become the Amazon (or Uber, or Netflix) of their industry.” As we all know, one of the core tenets of the Silicon Valley culture is “fail fast”; I’ve heard several companies outside Silicon Valley give at least lip-service to creating a “fail fast” mentality, too. The reality is different than the talk, however. It’s challenging for businesses that have operated under a traditional, legacy IT model to flip the switch, so I recommend an interim step: “succeed small.”
The concept of “succeed small” is to get away from typical IT project bloat. One problem we encounter with traditional IT initiatives is that ALL the POTENTIAL business requirements of a solution get thrown into a project up front. Why? Well, business users often believe that if they don’t get all their requirements into the first version of a solution, they’ll never get them in – because too frequently the first version is the ONLY version. One of my colleagues was lambasted in a client meeting by a business stakeholder for even suggesting an iterative approach to solution design for an application we were proposing. I’m paraphrasing, but what she said – vehemently – to my colleague was, “If we don’t get it in now, it will NEVER happen!”
But if companies can get past this initial distrust and deliver quick, small, initial versions of a solution that solve the most critical features/requirements of users, these small successes should yield results that do two crucial things: 1) deliver business results and build trust between IT and Business and 2) provide the business justification for moving ahead with additional iterations.
If you're thinking that the difference between “fail fast” and “succeed small” is largely semantic, you might be correct. You might also think this sounds a lot like agile or continuous development, and you wouldn’t be wrong there either. However, the mentality shift is more important than the process and needs to come first. Even if the change is mostly semantic, it's a necessary shift in mentality for enterprises with legacy IT approaches. Even though you’re a large organization, not all your IT initiatives need to be proportionately large and complex. In fact, small project successes can have disproportionately large impacts on your business, especially if you're lagging behind in digital transformation.
Create Cross-collaborative Teams for Emerging Tech
There are companies already doing this with the creation of sandbox innovation labs to experiment, test, and prototype outside the constraints of traditional IT approaches – all good things. However, these lab environments often lack two things: 1) cross-collaboration between IT and Business within working groups and 2) focus. Let's look at these.
Cross-collaboration. Many labs are run and staffed by technology people: smart folks who love new tech and bring expertise in engineering and computer science disciplines. These people are absolutely necessary because we need folks who can take immature and sometimes experimental technology and create something new that actually works. However, these environments are often missing operations people – folks in the organization with the experience and knowledge of core business operations, who have been in the field, on the factory floor, or on the front line with customers. Effective teams will have a mix of both.
Focus. Shouldn’t a lab environment be unencumbered by constraints to facilitate out-of-the-box thinking? Well, yes and no. Certainly, safe spaces for emerging tech should provide an environment where things can be researched, tested, and prototyped, even if some things never move from concept to production. However, for most organizations getting started with innovation approaches, they still need focus. The focus should be on 'where': where within our organization – our manufacturing plant, maintenance & repair teams, customer service – is innovation most needed; and 'why': the key business outcomes that are critical to future business success. By starting with the where and why, the smart folks in your labs are free to figure out the 'how' – how to get it done. The constraints for where and why can act as an impetus for focused innovation efforts.
Align Measurement for Business Impact
Here’s a problem: the ultimate business objective of technology solutions often gets lost after projects are implemented. Let’s consider how budgeting and project scoping often work in enterprises for IT projects. There's a gathering of potential initiatives throughout the organization during a budgeting cycle; business cases are developed to justify which initiatives get funded. These are rolled up into larger budgets – either owned entirely by the CIO's organization, allocated within different business units, or a combination of both. When it's time to execute individual project initiatives, IT falls back on their KPIs of delivering within cost and on time. And the original business case developed by the business unit is sitting deep in a file folder on someone’s hard drive, with the original business metrics used to justify the project largely forgotten.
To align Business and IT on digital transformation initiatives, we need a common way to measure business outcomes; metrics should be about true business impact: is the solution we are building – together – delivering on the organizational change we imagined? And IT and Business must hold each other accountable for these core business impact metrics throughout the design, development, and full life cycle of the solution – and then adjust when business needs change.
Think Product vs. Project
Another key mental shift for companies is to think about technology solutions products instead of projects. What does that mean exactly? Well, a typical project mentality is gathering requirements from the business, designing, building, testing, deploying, and (sometimes) training on a solution that goes out into users’ hands. The project is now “done.” And often in legacy IT enterprise organizations, that solution just lives on, well past its “freshness date,” with no real road map for how or when improvements and enhancements should or will be done.
In today’s digital world, solutions have morphed into experiences; the digital solutions we introduce are part of a bigger experience for users – whether those users are customers interacting with your brand or employees in the field servicing your customers. Therefore, companies must shift to a product mentality, as if digital solutions are an extension of its products, services, or business operations. This implies that digital initiatives must be managed with a full product life cycle approach: from conception to deployment to improvements and enhancement and even to end-of-life-cycle and sunsetting.
One way to achieve this shift is to assign digital initiatives Product Owners instead of Project Managers. Project management should remain a function in designing, deploying, and managing an ongoing solution, but the Product Owner has overall responsibility for the full life cycle of the digital solution and accountability for ensuring it continues to serve user needs, deliver the business impacts described above, and prioritize new enhancements to expand on the original business outcomes. Ideally, the Product Owner – even if he or she is a technical resource – should either sit within the operational organization the solution serves or have dotted-line responsibility to the business unit.
Don’t Design Solutions from the Boardroom – Get into the Field
Recently, one of our IT customers took me to a field operations center. He knew everyone there. He was greeted affectionately. He knew exactly how their applications were used every day. Yes, folks, IT people and operations people can be happy together! In this case, IT understood the needs of its end users from a front-line perspective; by getting into the field, IT can develop both a deep knowledge of business requirements and trust from the business.
From a business perspective, when you’re heads down in doing your thing every day, it’s easy to forget that not everyone else understands core business operations as well as you. Even though business stakeholders and end users may think they're telling IT what they need, IT may not understand those needs clearly. At Skyllful, we say you can’t design a solution for the field from the boardroom; operations people must be open to IT folks sticking their noses into their business occasionally, so IT can appreciate and understand the on-the-ground, or in-the-field, requirements.
Building a healthy relationship between IT and Business for long-term digital evolution success isn’t easy. It requires a dedicated effort around a new collaborative mindset. But implementing some of these recommendations is a good starting point.
Obviously, we here at Skyllful would love to help, and we’ll be discussing this topic more in the future.
Skyllful is a leading provider of a mobile digital adoption platform that helps companies with large, mobile workforces deploy mission-critical enterprise mobile applications smoothly and successfully. With deep expertise of mobile technology and best practice field deployments as well as a leadership team with decades of experience working with large enterprise mobile workforces and applications, Skyllful offers a platform for empowering field workers to use enterprise mobile apps more efficiently and effectively, maximizing the positive effect of mobile application deployments.
Skyllful’s approach to technology-driven training and engagement combines on-device, on-demand, contextual-based simulations, reinforcement activities, deep analytics and reporting on field readiness for an enterprise-wide view of mobile employees’ impact on the organization. Whether a company is deploying a new mission-critical workforce app or seeking to improve its workforce engagement with existing apps, the Skyllful platform is easy to use, intuitively designed and proven to increase productivity and deliver greater returns on investments in technology.