Enterprise

Software Implementation: A New Approach

How an iterative approach to implementing Sabisu delivers business benefit faster and with lower risk

White Paper By

Tim Sharpe
CEO & co-founder tim.sharpe@sabisu.co @timjsharpe

Enterprise Software Implementation: A New Approach

White Paper

Contents
1. INTRODUCTION ........................................................................................................... 3 2. CHALLENGES ............................................................................................................... 4
2.1. 2.2. 2.3. 2.4. 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. SELECTION MECHANISM ........................................................................................................................................ 4 COMMERCIAL TERMS .............................................................................................................................................. 5 USER ADOPTION & TRAINING ............................................................................................................................... 6 RISK ........................................................................................................................................................................... 7 PROPERTIES OF AN IDEAL APPROACH ................................................................................................................. 8 TROJAN MICE ........................................................................................................................................................... 9 OVERVIEW OF THE PROCESS .............................................................................................................................. 10 SCOPE ..................................................................................................................................................................... 11 OUTLINE DELIVERABLES .................................................................................................................................... 12 CUSTOMER RESPONSIBILITIES ........................................................................................................................... 13

3. DEFINING A BETTER APPROACH .................................................................................. 8

4. PROCUREMENT CONSIDERATIONS ............................................................................ 14

4.1. SELECTING INNOVATIVE SOFTWARE ................................................................................................................ 14 4.2. A FAIR COMMERCIAL MODEL ............................................................................................................................ 15

5. STEP-BY-STEP GUIDE ................................................................................................. 16

5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7. 5.8. FINDING THE RIGHT PROBLEM .......................................................................................................................... 16 DEVELOP STAKEHOLDER SUPPORT ................................................................................................................... 17 REFERENCE SITES ................................................................................................................................................ 18 DEVELOP THE POINT SOLUTION ........................................................................................................................ 19 DEPLOY THE POINT SOLUTION .......................................................................................................................... 20 SEEK FEEDBACK ................................................................................................................................................... 21 REVIEW .................................................................................................................................................................. 22 THE NEXT TROJAN MOUSE ................................................................................................................................. 23

Figures

Figure 1. Approach Overview ...................................................................................................... 10

2012 Sabisu Ltd

Page 2 of 23

V1.0

Enterprise Software Implementation: A New Approach

White Paper

1. Introduction
Enterprise software is typically secure, resilient and powerful but it can be difficult to select and implement, with significant cost and risk involved. Often benefits are over-stated and take some time to be seen in real terms. This white paper outlines how its possible to take a different approach by delivering substantial change in targeted, low risk, high value solutions. These solutions are aligned to business strategy, meet a genuine need and carry great business benefit, yet are deliberately small in scope. They are more easily managed than large implementations and carry less financial and operational risk. This approach has been successfully adopted by the Sabisu team in delivering the Sabisu platform, resulting in changes to the design of the platform to help meet niche requirements easily. This white paper starts by looking at some common challenges faced when deploying enterprise software, including software selection, commercial terms and risk. It then looks at the proposed alternative approach in three sections;
Definition o How an ideal approach would be designed to be iterative and manageable o Properties and concepts that have informed the development of the process. o Scope, outline deliverables and responsibilities for each iteration of the process. Procurement o How the procurement process must reflect the nature of innovative software solutions and their vendors. o How a well designed commercial model can be fair to all parties. A typical iteration o Key considerations for each step in the iteration. o Focus on delivering business benefit and development of a complete solution.

2012 Sabisu Ltd

Page 3 of 23

V1.0

Enterprise Software Implementation: A New Approach

White Paper

2. Challenges

Some common challenges organisations have to overcome when selecting and deploying enterprise software.

2.1. Selection Mechanism

Starting at the beginning, with the selection process; its often a process thats great for procurement compliance, but not so great for getting the right enterprise software. Without dwelling too much on the Request For Proposal/Information process itself (see http://go.microsoft.com/fwlink/p/?LinkId=208380 for a detailed discussion) its fair to say that a traditional RFP/I driven procurement process doesnt guarantee the best results. A typical RFP procurement process starts with an executive decision to procure a strategic solution. The executive gets a project manager to build the RFP/I by surveying affected parties. Vendors respond positively to the RFP/I so they can be in with a chance of winning the inevitable beauty pageant where the vendors get their chance to pitch. The best sales team wins not necessarily the best software. In fact, experienced sales people will shortcut the process wherever possible, going straight to the executive who started the ball rolling. This approach doesnt guarantee the right software will be selected as it doesnt allow for all the factors that influence successful implementation and adoption of enterprise software. It also doesnt allow for particularly innovative needs or solutions, where there might be only one solution on the market as is covered in the Selecting Innovative Software section below. Its also too risky; once the selection is made and commercial terms agreed, the procurement process often seen as complete, where in fact its just started; the ongoing maintenance and development of the software should see continued procurement involvement throughout the softwares full life-cycle.

2012 Sabisu Ltd

Page 4 of 23

V1.0

Enterprise Software Implementation: A New Approach

White Paper

2.2. Commercial Terms

Enterprise software has traditionally been offered on a license plus annual maintenance model, where the annual maintenance charged is calculated as a percentage of the license cost. These costs are often set as high as possible by the vendor as they expect to be negotiated down during the procurement process. The license may be payable up front, or may be annual. Typically the cost will be calculated on factors like:
Feature Set Its relatively common for enterprise software vendors to charge an initial fee based on feature set. Typically the offered software will be priced according to the market segment. Complex pricing models that lack transparency can be a barrier to entry for customers, or for senior management sign off of procurement decisions. Users A license per seat is quite usual; this may be user specific, machine specific, or a non-specific maximum number of users. Often large enterprises enter into enterprise agreements effectively bulk buy contracts. Either way, every new user adds cost. Data points Some process industry software is charged by the number of data points to be accessed. As the tendency is never to delete data points but add more as the business evolves, the total cost also increases. Data stored/accessed Particularly and understandably prevalent in cloud solutions, this sees the enterprise incurring additional cost as solution starts becoming used in earnest. As with the data point model above, the tendency is for data stored to increase. Enterprise search solutions are often seen following a similar model, where cost is dependent on the number of documents to be indexed.

The annual maintenance cost is then based on the license typically 15% to 20% of the license cost. This maintenance cost can therefore be significant. Generally annual maintenance includes upgrades and a default level of support. Generally as usage of the software increases the cost to the enterprise increases. Therefore once the cost reaches a prohibitive level the enterprise starts to ration usage. This is somewhat counter-productive given that the software is required and is expected to deliver benefit. Wouldnt it be great if enterprise software was subject to a commercial model that encourages its propagation and increased use?

2012 Sabisu Ltd

Page 5 of 23

V1.0

Enterprise Software Implementation: A New Approach

White Paper

2.3. User Adoption & Training

Often enterprise software requires significant user numbers before it starts delivering business benefit. This argument is particularly prevalent in social business, collaboration or business process execution software. Most enterprise software is designed with the business in mind, rather than the end user; its focus is security, process/data integrity and control. These are worthy and necessary principles. Often the result is software that is in some way non-intuitive and so a significant amount of training for end-users is required. This both increases the expense and the likelihood that some users will not adopt the software particularly those who have no cause to use it day-to-day. Wouldnt it be great if any user could derive maximum benefit from enterprise software without training?

2012 Sabisu Ltd

Page 6 of 23

V1.0

Enterprise Software Implementation: A New Approach

White Paper

2.4. Risk
Enterprise software traditionally carries significant risk both in terms of implementation and operation. Implementing enterprise software should be low risk; until the software is operational it should be possible to change or even cancel deployment. However, funding is usually staged, reputations invested and tight contracts drawn up so that mid-way through deployment a change is difficult and painful. If enterprise software was less expensive to license, deploy and support, then organisations could make more balanced decisions about the process of implementation. Often enterprise software is deployed across the organization within a single project, as quickly as possible. This is a high risk strategy in terms of cost, as it front-loads spend, and schedule, as any delays resonate through the plan causing slippage. Its also high risk in terms of operations as many users need to be trained simultaneously or in quick succession. Wouldnt it be great if benefit could be realized through partial adoption and throughout a gradual, well-managed deployment? Operating enterprise software should be low risk; the software has probably been designed and implemented by experts. However, it often leads to increased and sometime unsustainable drains on funding and expertise within the IT function as the use of the software grows. Organisations are understandably reticent to take on new software as it carries with it unforeseen overhead. Wouldnt it be great if enterprise software was designed to alleviate resource and funding stress on the IT function?

2012 Sabisu Ltd

Page 7 of 23

V1.0

Enterprise Software Implementation: A New Approach

White Paper

3. Defining A Better Approach

How an ideal approach should be designed; iterative, manageable, low risk, with high impact rapidly achieved.

3.1. Properties of an Ideal Approach

Given the challenges of current approaches as detailed above, an alternative approach would have properties such as:
Limited initial spend Low initial effort Low initial risk o Revenue o IT and business continuity o Security

This approach would choose a strategic, scalable solution but start with a small deployment focused on solving a particular problem to ensure quality and suitability. This focus ensures value is added both immediately as the current problem is resolved and in the future, as the ideal problem will be representative of others in the organization. The solution is a strategic one. Although the apparent opposite of the mass roll-out, big-bang approach required in some business transformation programmes, in fact this approach could be the essential precursor to such programmes as it reduces their risk exposure significantly. The initial deployment may be intentionally focused but the solution is strategic. Whilst often the larger transformation programmes are delivered using a specific methodology, the ideal approach would be as useful as an repeatable delivery method as it would be for a proof of concept. Indeed, the iterative model is perhaps a better way to truly achieve enterprise change, as suggested in the Trojan Mice section below; it allows constant focus on the customers. One of the benefits of starting with a low risk point solution is that the key procurement decision points can be incorporated, informing process rather than leaving it separate. The procurement process is made more efficient as a result. Enterprise software is valuable because of the problems it solves and efficiencies it introduces, so all parties benefit from realizing real business benefit as quickly as possible; theres no better way to demonstrate the platforms potential when implemented even with a small subset of customer data or small team.

2012 Sabisu Ltd

Page 8 of 23

V1.0

Enterprise Software Implementation: A New Approach

White Paper

3.2. Trojan Mice

This approach is known within the Sabisu organization as the trojan mouse approach, as credited to Peter Fryer (http://www.trojanmice.com/index.htm). Enterprise software implementations represent a particular niche kind of enterprise change programme. Such programmes are frequently expensive, time consuming and ambitious, yet deliver varied results and limited change. As an example, enterprise software implementations are often excellent at reproducing the same problems on a new platform. The trojan mouse concept describes: small, focused changes which are introduced in an ongoing, inconspicuous waysmall enough to be understood and owned by all concerned but their effects can be far-reaching. Peter Fryer Applying this concept appeals given the propensity of enterprise software deployments to be high-risk and high-cost with business benefit realized late on in the life-cycle.

2012 Sabisu Ltd

Page 9 of 23

V1.0

Enterprise Software Implementation: A New Approach

White Paper

3.3. Overview of the Process

The process proposed in this paper would run as follows:
Find the right problems Identify well-defined, high impact business problems to address. Develop stakeholder support Engage stakeholders to validate the problem and assist in the identification of a solution. Visit reference sites Consult other users to learn from their experience. Develop the point solution Iterative, developers working directly with end-users. Deploy the point solution Ensure business change is appropriately managed for communities of users, piloting with smaller communities if required. Seek feedback Communicate successes, highlight benefits, build momentum. Review Check strategic fit, identify other business problems that might benefit.

Once this process has been completed, then its into the deployment process, which is for another white paper but will follow an iterative model with the same or similar elements. Fig.1 shows how the approach could be the basis for this.

Figure 1. Approach Overview Note that a pilot - a pre-roll-out stage intended to ensure that the roll-out is of a high quality - could be included into the Deploy point solution process. There is a management process that runs in parallel involving the development and acceptance of a proposal to cover the required work, along with an appropriate purchase order. This would be complete before the start of the Build phase shown in Fig.1. 2012 Sabisu Ltd
Page 10 of 23 V1.0

Enterprise Software Implementation: A New Approach

White Paper

3.4. Scope
The scope of each iteration of the process is to implement an iteration resulting in a fully working Sabisu solution albeit a solution to a niche problem. This could be a deliverable as part of a larger plan, or a Sabisu proof of concept. The process includes:
Evaluation of technical landscape to ensure Sabisu will deliver as required Installation and configuration of Sabisu On-Premise onto one hardware platform or the installation & configuration of a Sabisu On-Premise Appliance Configuration of connection to data sources typically a single data source initially Integration with Active Directory environment Creation of communities (usually 3 or 4) Creation of reporting dashboards (usually 2 pages, each with 5 widgets) System familiarisation for key users Regular review and evaluation of the implementation Support for any further engagement

In order to deliver a competitively priced, rapid proof of concept the target systems for integration are intentionally limited. The ideal strategic partner should be pleased to assist post-project by attending user groups or workshops. Indeed, the implemented product is made stronger and implementations higher quality by close involvement of developers with users. Conventional enterprise software would require a significant amount of training with each iterative delivery. This has effectively been designed out of the process by building Sabisu to be so intuitive and user friendly that users can find their own way around the system; we use modern user interface design principles to make the experience as consistent with mass market web platforms as possible. If the scope is to deliver a proof of concept the objective is to leave the customer with a solution that users can interact with as they would a full implementation; its not expected that the customer will be sufficiently familiar with the platform that they can carry out complex configuration activities this tends to naturally follow in subsequent phases.

2012 Sabisu Ltd

Page 11 of 23

V1.0

Enterprise Software Implementation: A New Approach

White Paper

3.5. Outline Deliverables

The key final deliverable is a tested and operational Sabisu proof of concept. The following are typically required:
Technical Evaluation o Active Directory Implementation o Outbound/Inbound Connectivity o Access to Target Systems o Other Integration Potential o Hardware Platform Suitability Installation of Sabisu On-Premise o Installation o Activation o Verification Connectivity to specified data source Active Directory o Connection o Configuration of evalution users o Verification of internal login & redirection to On-Premise Creation of communities o Usually 3 or 4, after which users should be able to create their own (see System Familiarisation) o To be specified by customer Creation of solution, e.g., reporting dashboard o Usually 2 pages, after which users should be able to create their own (see System Familiarisation) o 5 widgets per page, illustrating different Sabisu capabilities and key customer requirements System familiarisation for key users o One session o Community creation and administration o Community page creation and administration o Creating new pages from widgets Review of progress and evaluation of ongoing requirements

2012 Sabisu Ltd

Page 12 of 23

V1.0

Enterprise Software Implementation: A New Approach

White Paper

3.6. Customer Responsibilities

As implied in the Overview of the Process section above, a customer commitment of resource effort and funding is required to ensure success. Ideally a customer senior technical resource is made available so as to ensure access to both systems and other expertise in the organization. The senior technical resource may be responsible for the implemented system, its maintenance and improvement. As would be made clear in a proof of concept proposal, the customer would have responsibilities around the following:
Documentation Its important to get the process off to the right start, which means it can only be initiated in response to acceptance of a proposal. This ensures a joint understanding of priorities and deliverables. Problem definition In order to get the best value from the proof of concept all parties should be clear as to the identified problem, allowing the most important content to be prioritised during the build process. System access Appropriate and timely access to data sources is required if implementation and integration is to be efficiently carried out.

2012 Sabisu Ltd

Page 13 of 23

V1.0

Enterprise Software Implementation: A New Approach

White Paper

4. Procurement Considerations

Procurement processes are often not optimized for the purchasing of innovative software solutions. This section discusses how they can adjust.

4.1. Selecting Innovative Software

As described above in Selection Mechanism, procurement processes can have difficulty with particularly innovative requirements or solutions where a single vendor may offer a unique solution. In this case, the traditional commodity procurement approach has a problem there is no competition. Something like this tends to happen with Sabisu - its innovative feature set puts it in a class of its own. In addition the responsive and inclusive nature of the Sabisu organization causes a partnership with the customer to be developed early. This could be seen to disadvantage competitors. However this partnership is just as important as the feature set because the product is not the solution; its the product, implementation and support that creates a workable solution. This is sometimes referred to as the whole product, as created by Regis McKenna and popularized by Geoffrey Moore. Instead of then creating an artificial competitive environment against which to evaluate an innovative software solution, wed recommend the procurement process looks at the:
Feature set Implementation Support Cost Benefit Strategic fit

With all these factors taken into account the likelihood of creating a strategic partnership is good.

2012 Sabisu Ltd

Page 14 of 23

V1.0

Enterprise Software Implementation: A New Approach

White Paper

4.2. A Fair Commercial Model

The Sabisu commercial model is designed to encourage use of the platform whilst being fair to all parties. Sabisu has two key components; the cloud servers and the on-premise servers. Use of Sabisus cloud computing capability is free of charge. This encourages collaboration between users and enterprises and creates more efficient business processes as a result, as outlined in the white paper, Rebooting Operational Intelligence. For enterprises that require significant Sabisu cloud-based file storage we negotiate individual terms per GB per month used. Use of the on-premise server software is covered in a single annual charge that covers maintenance and license to use. The license permits unlimited numbers of users so as to promote growth. The annual on-premise server charge has three tiers, with the cost depending on:
Data sources Permits customers with simple needs to be charged less. Processor cores Accommodates customers with virtualised server environments and permits appropriate and fair charging depending on requirements.

Some services essential to the engagement, build and deployment will be costed into any proof of concept proposal. All commercial negotiations are open book and transparent as they should be with a trusted, strategic partner.

2012 Sabisu Ltd

Page 15 of 23

V1.0

Enterprise Software Implementation: A New Approach

White Paper

5. Step-by-Step Guide

Key considerations for each step in an typical iteration, focusing on delivering business benefit and development of a complete solution.

5.1. Finding the Right Problem

Ideally, the process starts with a defined business need. Often the business need develops to indicate a strategic need, e.g., a user identifies a need for a KPI report that highlights the need for a new reporting platform. Whilst the strategic need might demand a strategic solution, the initial step should be to identify the problems that need to be resolved. Typically with Sabisu these problems are expressed in business process or management visibility and control terms. Once a selection of problems has been identified they need to be narrowed down to one or two that are:
Precise and well boundaried, i.e., with clear scope Low operational risk High impact, either in terms of customer satisfaction, demonstrating potential, reducing cost or increasing revenue Stakeholder supported, or likely to engender stakeholder support

Limiting the scope to high value problems such as these will allow the maximum benefit to be delivered and the solutions potential to be demonstrated. Even if the number of users affected is initially small this approach can deliver great benefit. Its important that the solution is applicable to other problems in the future. Examples of niche problems appropriate for proving Sabisu have included;
Energy Usage Monitoring o Make energy usage data from data historian available to management team o Proved integration, presentation and collaboration capabiliities of Sabisu o Precise measurement and reporting problem o Significant benefit as any energy saving has significant cost impact o Small, focused team Digital Signage o Make key operational data available on public screens around organisation o Proved integration and presentation capabilities of Sabisu o Low risk, high visibility and impact o Small deployment o Limited number of specific KPIs to address Shift Management o Deliver Shift Logging capability alongside operational data for Shift Management team o Proved integration, collaboration and rapid development capability of Sabisu o Operational impact o Small, focused team of Shift Managers o Senior management relevance o Opportunity to exploit integration capabilities of Sabisu. Page 16 of 23 V1.0

2012 Sabisu Ltd

Enterprise Software Implementation: A New Approach

White Paper

5.2. Develop Stakeholder Support

Depending on the nature of the identified problems it might be appropriate to start this process with senior management, or it might be that an appreciation of the business problems as they are experienced operationally is the right starting point. Stakeholder support validates the problem, engages stakeholders in the architecture of a solution early and ensures the problem is sufficiently well understood to select an appropriate solution. The value of stakeholder support should not be underestimated, with the proviso that sometimes users cannot visualize the benefit of a step-change in capability that new technology will bring. Therefore sometimes it is necessary to build out the proof of concept to build stakeholder support another reason why an inexpensive and low risk approach is preferable. Senior Management support is important early in the process. As discussed above, sometimes this means building a low cost proof of concept which falls within discretionary spend levels so as to allow Senior Management to visualize the potential of the software. Even if Senior Management support for the strategic solution isnt forthcoming, the point solution may still be valid, so if the right problem is chosen in the first place all concerned can look to the proof of concept to continue adding value even if its not developed into a widely deployed solution. If the problems identified meet the criteria laid out above and are described in terms of business impact and alignment to the strategic goals of the business, Senior Management engagement should be no problem.

2012 Sabisu Ltd

Page 17 of 23

V1.0

Enterprise Software Implementation: A New Approach

White Paper

5.3. Reference Sites

Proper use of reference sites allows the procurer to differentiate between organisations that are merely software vendors and those that will become reliable, trusted strategic partners. Often reference sites are used very late in the procurement and an early visit, web or telephone conference with reference sites should be a key part of building towards the proof of concept. Indeed, we encourage everyone in the Sabisu user community to collaborate, exchange best practice and learn from each other through forums such as our Sabisu User Groups. Sabisu customers are always happy to share their story, so even if the story isnt a precise fit for your circumstances, therell be lessons that can be learned by asking the kind of questions youd ask any reference site, e.g.,
How has the solution impacted your business processes? Has the solution solved your problem? Whats the turn around time on modifications or fixes? How flexible is the supplier in meeting needs or challenges? What would you, as a customer, have done differently? Where next for the solution?

Other subjects may be too sensitive to yield useful information, including return in investment, business growth, cost savings or so on. As with any other enterprise software procurement you should aim to determine whether the vendor is a candidate for strategic partnership. For example:
How can the vendor share the risk of adopting the new technology? What expertise can the vendor commit to supporting the implementation? How can the implementation be frequently assessed to ensure suitability and capability of the solution? What is the strategic plan for the solution, product and/or vendor organization?

Your enterprise software vendor shouldnt just expect these questions; any vendor committed to a strategic partnership should recommend you ask them of all other enterprise software vendors.

2012 Sabisu Ltd

Page 18 of 23

V1.0

Enterprise Software Implementation: A New Approach

White Paper

5.4. Develop the Point Solution

With stakeholders in support and an understanding of how other customers have approached similar problems now is an appropriate time to develop the solution. This is the point in the process where items identified in Outline Deliverables section begin to be produced. The first step in developing the point solution is to install the Sabisu On-Premise and connect it to the appropriate data sources, which involves:
Technical Evaluation Installation Connection

Sabisu is designed in such a way as to make this a rapid process exactly the opposite to enterprise software which seeks to maximize services revenue. Following this a small number of user communities are created within Sabisu, each holding a small number of users necessary to support development. These communities will expand organically as more users are required to test. As this is a point solution to a specific problem its low risk and suitable for a collaborative, iterative approach. Therefore its common to have developers work closely with end-users to ensure that the solution meets their requirements. Another factor supporting the iterative approach and one of the advantages of implementing a platform like Sabisu - is that theres no development as such; the solution is provided as a number of components that are constructed rapidly in a dedicated Sabisu development environment. In cases where custom development is required using the Sabisu API, the iterative approach holds. Whilst the use of a development environment like Visual Studio may be required, Sabisus API makes the development much easier and allows for a rapid rate of progress. During the development process it might be appropriate to release beta versions of the solution to selected users. This is easily accommodated by setting up a pre-release user community and making the solution available to those within it. When the solution is ready to be published the developer simply makes the elements available to the wider user community.

2012 Sabisu Ltd

Page 19 of 23

V1.0

Enterprise Software Implementation: A New Approach

White Paper

5.5. Deploy the Point Solution

Deployment of the solution is invariably a simple affair. When the solution is at an acceptable level of quality, the developer makes it available to the wider community. A senior user can then share the pages that make up the solution with the community or with selected users, who can in turn do the same thing within the constraints of data security and administrative control. This leads to a managed but rapid deployment to the users who need the solution; a controlled, administered, viral expansion of the user-base. At this point the efforts expended earlier in the process to define a niche problem, properly evaluate the technical environment and develop the solution collaboratively begin to pay off; the solution is usually a great fit for the problem as its been validated and optimized constantly throughout the process. The deployment process is also usually iterative, as users may have different levels of access to the data sources or new users are introduced to the communities. These issues present few problems and are usually dealt with by end-users with little load on IT. During the deployment process it may be required to familiarize users with the system. Typically this is not required as Sabisu is intuitive and easy to use, but a single session on the basics of community administration and page creation is sometimes of benefit.

2012 Sabisu Ltd

Page 20 of 23

V1.0

Enterprise Software Implementation: A New Approach

White Paper

5.6. Seek Feedback

Whilst feedback from the user communities involved in the development, testing and acceptance of the solution is usually already collected as part of the process, with a niche solution in place its appropriate to get feedback from a wider audience. If senior management are not yet engaged, now is a great time to get key members of the team together and demonstrate what can be done at low risk and with a small amount of funding. There is no better demonstration than that which shows an organisations data in the context of a resolved problem. Wider feedback can also be obtained through publicity in corporate journals, blogs or other communications. This is a great way to spread the word but also lay the foundations for establishing the next set of problems that can be solved. Communicating successes and highlighting benefits builds momentum.

2012 Sabisu Ltd

Page 21 of 23

V1.0

Enterprise Software Implementation: A New Approach

White Paper

5.7. Review
After feedback has been gathered its appropriate to review progress and look ahead with a view to maintaining the momentum already built. In addition to user and management feedback, Sabisu is unique in that it can be used to demonstrate genuine system usage; amount of data shared, widgets in use, messages left, chats initiated and so on. This allows future deployments to be better planned, whether in problem selection, solution development or deployment itself. The review process should involve senior management; at this stage the senior management team have either been involved throughout, or appraised of success in the Seek Feedback step immediately before. This is a great opportunity to engage them at the start of the next process. The review process may be completed in a single meeting with all stakeholders. Items that should be reviewed include:
System usage o How was the system used? o How could the effort and financial investment made so far be further leveraged? o Did anything prevent wider usage? o Were some aspects particularly successful? Lessons learned o Could the implementation have been smoother? o Are there any aspects of the process that would be useful in other projects? o Are there outstanding actions that should be carried through to other projects, deployments or business as usual? Strategic fit o Are the original assumptions on strategic fit still valid? o Have any external factors arisen which change the assessment of strategic fit? Evaluation of any new requirements raised during the implementation Identification of well-defined, high impact business problems that should be addressed next

2012 Sabisu Ltd

Page 22 of 23

V1.0

Enterprise Software Implementation: A New Approach

White Paper

5.8. The Next Trojan Mouse

The review process documented above evaluates new requirements that may have arisen during the implementation and identifies new high-impact business problems that should be addressed. These problems should be evaluated as described in the Finding the Right Problem section so as to arrive at the next trojan mouse to be addressed. Of course, multiple problems could be solved simultaneously and the temptation is to take a success and apply it to as many areas as possible. The benefits of doing this need to be weighed against the risks, particularly in terms of committing end-user time; this process could be end-user effort intensive and multiple simultaneous initiatives could cause resource conflicts. Usually the next ideal candidate problem arises during the previous solution development and its a matter of delaying work on the new problem until the old one is far enough along the process. To that end theres nothing wrong with overlapping solution development; as one solution is in deployment another can be in the development phase. In this manner the trojan mouse approach can be seen as enabling a series of solutions to be implemented, each widening the reach of the platform, the business processes affected and increasing the business value delivered. In this manner the engagement with and deployment to the enterprise is built on success after success.

2012 Sabisu Ltd

Page 23 of 23

V1.0