For CIOs & Senior IT Executives
The Mobile Business
Paul May, the Author
Article (Web Page) #2 -
This is the second column
(shall we say, web page) in a series
of pages (by Paul May) aimed at helping CIOs
strengthen their m-business positions with strategic insight and
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:
cross existing boundaries - of function as well as system
impact and exploit contingent systems
automate unexamined processes
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
We will look at designing an Intention Risk Reduction process later in this series.
With thanks to Stuart Campbell of Extended Systems (www.extendedsystems.com) for suggesting the inadequacy of simple 'proof of concept, pilot and rollout' thinking in m-business systems development.
© Verista 2002 - Reproduced here by
MobileInfo.Com with permission
Paul May and Verista
Paul May is a Principal Consultant with Verista (www.verista.com)
and the author of Mobile Commerce: Opportunities, Applications and
Technologies of Wireless Business (2001) and The Business of
Ecommerce: from Corporate Strategy to Technology (2000), both
published by Cambridge University Press.
Verista is an independent consultancy specialising in digital
channel strategy and management, wireless technologies, mobile
workforce enablement and mobile marketing. We work with channel
partners, systems integrators, network operators and software vendors
to bring the appropriate mix of capabilities to our clients.