Home     |     About Us     |     Tell A Friend     |     Add A Link     |     Contact Us     |     Advertise

How to Search   Tips

 

 Solutions Catalog
 Products & Services
 Vendors
 The Market
 Application Mall
 Business Cases
 Solution Components
 Networks
 Application Development
 System Design
 Resources & Links
 Education
 Professional Services
 Conferences & Events
 Reports & Presentations
 Templates & Aids
 Glossary
 Community Forum
 News
 Topics
 Handheld

 
For CIOs & Senior IT Executives

The Mobile Business Leader
Paul May, the Author

 Article (Web Page) #2 - May 2002

 

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 actionable guidelines.

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

  • weak or absent methods

  • unacknowledged politics

  • unpopular or absent common services (such as database experts or network experts)

  • poor understanding of possibilities (because the project is launched without market research or business sponsorship)

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 organization.

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

About 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.


Related Resources:
Go to Paul May's First Article (April 2002)
More CIO Topics 
Mobile Professional Topics
 

 

 
Site Map     |     About Us     |     Tell A Friend     |     Add A Link     |     Contact Us     |     Advertise

Copyright 1999 - 2001.  All Rights Reserved. 
Reproduction of any material from the MobileInfo.com website or its newsletters without written permission is strictly prohibited.