 |
Digital
channel strategy,
architecture and development |
|
home | services | clients | publications | people | contact The Mobile Business LeaderA series aimed at helping CIOs strengthen their m-business positions with strategic insight and actionable guidelines. 002 - May 2002 Deploy M-business solutions successfully - by returning to base Processes for introducing new systems into the business usually appear robust and well engineered. The end-products of many implementations, with lessons learned and fed back into the design, these processes tend towards similarity across all kinds of IT organizations. The best are focused on delivery, tolerant of in-flight change, and shared by all the teams working on the implementation. As organizations move into m-business, applying mobile devices and networks to relevant areas of the business, some of these processes need questioning. Not because they are wrong in themselves: but because they do not always start in the right place. Let's look at the typical implementation. What does the process look like? A typical answer will look like Figure 1 (see Implementation Risk Reduction).
Figure 1: Implementation Risk Reduction The perceived risk of introducing the new system is managed by controlling the business's incremental exposure to it. The proof-of-concept phase allows us to check that the solution is generally viable. The pilot proves that the solution performs satisfactorily in the business context in which it will be deployed. The rollout program is a phased approach to delivering the solution to a steadily growing population of users, usually prioritized based on a number of factors, including willingness of the group to experiment willingly with new technology. This process only mitigates against business risk if its starting point is correct: that is, as long as the proposed solution answers some business need. The risks being managed in this phase are technical and logistical in nature. So, let us consider the typical pre-process. Figure 2 shows a solution selection process common to many businesses - indeed, one that is legally mandated for some organizations (see Selection Risk Reduction).
Figure 2: Selection Risk Reduction Here the RFI (Request For Information) announces a general problem, the RFP (Request for Proposal) or ITT (Invitation To Tender) embodies a commercial specification, the Responses describe alternative solutions, and the Selection derives the best fit between specification and solution. In most organizations, there is a degree of iteration and negotiation in this process. The process allows the commissioning team to apply objectivity and to gather the best possible diversity of responses. As a way of reducing the field of potential solutions, this process is fine. However, it still relies on the correct framing of an RFI. The process also introduces the possibility that respondents will seek to reinterpret the RFI to match their available technology or expertise. In this case, the rationale of the RFI must be robust, or it will serve only as the trigger on a starting gun in a commercial race, rather than a charter for business change. These observations apply to in-house developments as well as ones sourced from third-party suppliers. What is the pre-process of RFI? In most organizations, it is a cloud labeled "Requirements". The requirements capture phase of any IT project tends to be the least codified, and the least aligned to risk reduction. Yet the task of creating a crisp, comprehensive set of requirements that are explicitly agreed by the business is one of reduction. We start with a collection of (often conflicting) goals or (often ambiguous) desires, and work to cut away the ambiguity, resolve the conflicts and strengthen the business rationale. It's hard work - and it isn't made much easier with diagramming tools, if those tools aren't deployed in support of a coherent methodology. The requirements process is often hindered by:
Why is this problem acute for m-business? Some organizations have reaped rewards using just the Selection and Implementation processes, for example when introducing ERP and CRM solutions into the business. This can work because ERP and CRM can be adopted as vanilla-class applications in enterprises which have no competing legacy systems in their domains and which map easily to known processes. Mobile business applications rarely fall into this category, because m-business applications:
It's this last point which can prove the biggest obstacle to m-business projects that begin at the RFI stage. For many involved in IT, m-business is the first opportunity in a generation to create business-critical systems on a greenfield site. Mobile workers may be the last group to be visited by systems developers, and the last group not constrained by the desktop view of the world - and the desktop UI metaphor. The term "Requirements" stresses the outcome of the requirements gathering activity. "Requirements gathering" sounds deceptively simple and passive. We prefer the term Intention Risk Reduction for this process. This term puts the emphasis on business will, and the management of ambiguous thinking about what a project is intended to achieve. The need for Intention Risk Reduction is particularly important at a time when technology solutions, and their sales people, are driving the m-business agenda. We are seeing too many companies beginning at proof of concept, without considering which concept they really want to prove. We also see companies running m-business pilots with groups of software engineers or early-adopter types in executive roles. These groups do not always stand as perfect proxies for the general population within the organization. We will look at designing an Intention Risk Reduction process later in this series. With thanks to Stuart Campbell of Extended Systems for suggesting the inadequacy of simple 'proof of concept, pilot and rollout' thinking in m-business systems development.
|
| C O N T A C T | ||||||||
|
|
|
home | services | clients publications | people | contact ©Verista 2002 |