Fixing Backwards Planning
Fixing Backwards Planning by Don Van Doren
Enterprises often plan new communications and collaboration initiatives backwards from the way suggested by best practices. Today, industry changes make it even more important to plan correctly. Fortunately, there is a growing body of knowledge that points the way to more effective planning.
When enterprises decide to introduce new technology solutions, too often an unfortunate pattern emerges in planning and deployment. The pattern is, first, to decide on a specific technology solution. Next, identify and categorize the capabilities of the favored system. Finally, seek to find ways to make those capabilities fit into established business processes and to make the solution attractive to line-of-business management.
In general, that’s exactly backwards from the way things should happen. Logic (and demonstrable results) suggests starting by identifying the business requirements—issues that cry out for solutions or transformative opportunities to take business practices to a new level. Then determine what capabilities are required to address those opportunities or challenges. And finally, figure out what technology may best support the capabilities needed.
Of course, there are lots of reasons why planning happens backwards. In most companies, IT staff initiate change bringing new technical capabilities, and they tend to start with what is comfortable for them – the features and functions of technology systems. Further, the technology staff members often don’t have a deep understanding of the kinds of challenges that business units face, or how a particular technology solution would fit into current or alternative practices.
Conversely, business managers tend to be biased against change, as change can bring disruption in established processes and other unwelcome challenges. Moreover, business managers are good at, well, “managing" – using existing tools they have. Many excellent business managers don’t have a good appreciation of what might be possible with new capabilities, so tend not to know how to look for or evaluate such opportunities.
These factors drive the strong tendency for new technology initiatives to start with identified technology solutions seeking problems to solve. In many companies, there can be other, challenging factors. Often there are strong allegiances to vendor partners, and familiarity (or inertia) will favor solutions from partner suppliers. In larger enterprises, it can get even more complicated if different IT groups have responsibility for managing and promoting the solutions from different suppliers. In the good ol’ days, when telecom equipment vendors sold PBXs and desktop software suppliers stayed in the computer applications, that wasn’t much of a problem. Cisco and Microsoft were strong partners. Now, there are significant overlaps in product functionality, with, for example, Lync and Jabber bumping into each other, with more to come. In such an environment, the business requirements fade to a dim light in the glare of positioning battles going on among different IT factions.
The complexities in selecting technology solutions have a growing number of dimensions. In the good ol’ days referenced above, things were pretty simple, with clear separation among voice, desktop software, and business applications. Now, voice is delivered through each of these. Developments are exploding in mobility, mobile applications, social networking, peer-to-peer communications, internal and external portals, a variety of collaborative workspace capabilities, and much more. On top of it all are competing sourcing methods including premise, hybrids, managed services, and billowing cloud solutions. All these and more mean that slavishly following the path of partner vendors – and fitting business challenges into preferred vendor capabilities – may increasingly mean missing important opportunities.
Fortunately, there are well-proven methods that start with the business issues and work toward the best technology solution. In particular, the technique of identifying business “use cases” or “usage profiles” helps identify patterns of communications impacts in business activities throughout the organization. Areas with communications bottlenecks or breakdowns, or conversely areas of missing opportunities, are revealed.
The methodology has similarities to any business requirements gathering activity, with a focus on the kinds of communication and collaboration capabilities needed to solve existing issues or open up new opportunities. Key is having facilitated meetings directly with the individuals doing the day-to-day activities, business analysts and architects, and management to understand corporate and departmental directions. The facilitator is familiar with the kinds of technical capabilities available, and also is familiar with how work gets done in a business environment. The methodology identifies job and performance characteristics of individuals such as:
-
Their tasks
-
Their communications and collaboration requirements
-
The information or software supporting their communications activities
-
Who they communicate with
-
Challenges in accomplishing effective communications
What emerges is that different groups within the organization have very different patterns of communications and different tools that would be most helpful in doing their job. These requirements are distilled into use cases that characterize the way individuals within this case group use or could use communications and collaboration tools. Most organizations can describe most of their staff communications patterns in a half dozen or so use cases.
The use cases are then analyzed to identify the communications and collaboration elements that are critical to support the staff in that case. These lead to functional capabilities that appropriate technology will need to have. These requirements, in turn, can be contrasted against vendor solution capabilities. The other advantage of this approach is that deployment can often be staged – prioritize the use case opportunities and tackle the most important or those with the highest bottom line impact first. The advantage of this kind of deployment is to learn success patterns, build confidence, spread the word, convert skeptics, and use savings in the first implementations to fund subsequent initiatives.
This approach, starting with the business requirements, consistently produces better results. I feel that it’s critical for IT staff to understand these techniques and help its business colleagues to find solutions. As the potential solutions get more complex, approaching this from the perspective of the business issues first is critical.
In addition to the reasons cited above, there is another emerging consideration. Increasingly, communications and collaboration capabilities are being built into the business application software that many staff use continually on a daily basis. Frequently, it’s the line-of-business executive who has budget to purchase such functionality directly, without going through IT. In that case, IT needs to learn these techniques to identify real opportunity directly from the business and help steer the technology solutions that are implemented in directions consistent with IT’s long term goals.