Imagine an electronics company planning a new tablet or phone and building the business case based on pre-committed orders. Similarly, imagine a utility trying to get residents to sign-up to their electricity plan ahead of the advertising campaign. It just wouldn't happen. And yet, this is the model that information technology finds itself obliged to adhere to inside many large organisations.
How often do we hear of how an organisation needs an enterprise data warehouse and the first step is a departmental project? Similarly many a business is crying out for identity management, middleware and customer relationship management solutions that span divisions and other organisational siloes. Despite the chorus of agreement on the need, taking the first steps and then following through on the journey to implementing these foundational capabilities often seems too hard.
Technology projects are inherently complex but the last twenty years has seen the disciplines around the project management of information technology mature. Regardless of whether the approach is waterfall or agile, the objective of formalising the implementation is to reduce the rate at which information technology projects fail. The proponents of waterfall require thorough specification of requirements ahead of development with clear stakeholders. The advocates of iterative or agile methods require the organisation to stand-up fewer capabilities at one time through the engagement of a smaller group of stakeholders who are actively involved.
Increasingly, as a result of this maturing, our profession can be proud of our success rate at delivering solutions for individual departments or divisions. However, when the solution provides a service that spans the enterprise, problems and general dissatisfaction still seem to be more common than not.
Part of the problem is the very focus on individual projects that has helped to so dramatically improve the success rate of information technology investments over the past couple of decades. Like the utility company launching a new electricity or gas plan, enterprise solutions are typically providing a service that will be used in a myriad of different ways by their stakeholders. Rather than intricately collect the requirements of these individual users, the best that the information technology team can do is to define a service with specific parameters and test them with focus groups.
The situation is even more complex when the funding of these enterprise solutions is considered. Even businesses that reject cost recovery from individual stakeholders struggle to kick these projects off or sustain them past the first tranche of functionality.
When treated as a series of individual projects, someone has to go first. For a data warehouse that might be marketing, finance, or an individual line-of-business. Similarly for customer relationship management, one product area might have the most obvious and compelling need. Individual needs can always be delivered more effectively as standalone solutions without establishing capability for the future. Even the most enlightened team, supported by the most visionary executives, find it hard when focused on delivering a project to avoid compromising the future for the sake of dealing with the complexity of the present.
Worse, when progressing to the second and third drops the focus and urgency is often lost as the initial surge of enthusiasm supported by the most pressing business need begins to dissipate.
There is, however, a solution. Increasingly business and government is moving beyond a model that only supports new functionality as a series of projects and is shifting the focus to capabilities and services. The concept of a service enables the business to look at the return on investment in the same way as consumer focused businesses, like an electronics company, look at the potential of a new product launch.
As the tools of service management mature, and there is a convergence of thinking on the funding and resourcing of technology delivery, far more complex capabilities are becoming easier to develop with fewer missteps. In this environment technologists don't need to apologise for the complexity of the foundational technologies that the organisation needs rather they can make them available and support their evolution without requiring any one group take that first big leap of faith.
Comments