Planning change for e-business

Our starting point for managing change is when the objectives, strategy and tactics for introducing e-business change have already been specified as outlined in Part 2. Here, we are concerned with how to implement the strategy to achieve the objectives through the activi­ties performed by the project management team as part of project planning.

1. The imperative for project governance?

A recent survey of the challenges of managing e-business implementation projects is indi­cated by a survey of over 600 European and US businesses involved in management of web-related projects (Econsultancy, 2007). The research found that:

• Only 58% of respondents say that their projects always achieve their goals, and yet only 21% of them say they always achieve deadlines.
• Only 39% always achieve budget and a positive ROI.
• Over 8% of respondents never meet their project deadlines and nearly 6% never deliver their projects within budget.
• Nearly half of all respondents (45.5%) do not have a structured approach to managing their web projects.

Respondents to the Econsultancy (2007) research believed that web-related projects are dif­ferent from other projects because of their need to be responsive to:

• changing customer requirements and market conditions;
• the breadth of people and skills involved;
• the raft of stakeholders;
• frequently tight or fixed deadlines;
• a degree of uncertainty;
• and the need for interaction with real customers.

Econsultancy (2007) also looked at the main challenges of web project management which are shown in Figure 10.4 and corresponding approaches to overcome these challenges in Figure 10.5.

The research concluded that web projects require a project management approach that helps with:

• Evolving requirements;
• Putting focus on the end-customer;
• Collaboration between different skill sets;
• Managing stakeholder expectations.

The research showed that 56 per cent of organizations had experienced failed IT projects in the previous 12 months. The average loss incurred by the businesses surveyed was £8 million per project, with the largest single project failure costing £133 million. Implementation of specific types of information system indicate worse problems. In 2000, it was reported that around 70 per cent of CRM projects failed in terms of delivering a return on investment or completion on time.

It follows that the project governance of e-business projects, like that of other major infor­mation systems is essential to success. The COBIT framework provides a good summary of the requirements from a governance approach. COBIT is the widely adopted IT governance model for Control Objectives for Information and related Technology. This definition is also helpful since it highlights some of the success factors in project management which we will cover later in this chapter. Project management is one of the key processes COBIT identifies for the effec­tive governance of IT. It defines its control objective PO10 (COBIT, 2001) as follows.

Managing projects should satisfy the business requirement:

to set priorities and to deliver on time and within budget

and be enabled by

the organisation identifying and prioritising projects in line with the operational plan and the adoption and application of sound project management techniques for each project undertaken and takes into consideration:

• business management sponsorship for projects
• program management
• project management capabilities
• user involvement
• task breakdown, milestone definition and phase approvals
• allocation of responsibilities
• rigorous tracking of milestones and deliverables
• cost and manpower budgets, balancing internal and external resources
• quality assurance plans and methods
• program and project risk assessments
• transition from development to operations.

For effective project management the following elements need to be incorporated as part of the project management process as described, for example, by Chaffey and Wood (2005):

• Estimation – identifying the activities involved in the project, sometimes referred to as a ‘work breakdown structure’ (WBS). The sequence of activities for implementation of a typical e-business system is shown in Figure 10.6.
• Resource allocation – after the initial WBS, appropriate resources can be allocated to the tasks.
• Schedule/plan – after resource allocation, the amount of time for each task can be deter­mined according to the availability and skills of the people assigned to the tasks. There are two different concepts. Effort time is the total amount of work that needs to occur to complete a task. Elapsed time indicates how long in time (such as calendar days) the task will take, and is dependent on the number of people working on the task, and their skills.
• Monitoring and control – monitoring involves ensuring the project is working to plan once it has started. Control is taking corrective action if the project deviates from the plan. In particular the project manager will want to hit milestones – events that need to happen on a particular date are defined for which performance against objectives can be measured (e.g. end of analysis, production of first prototype).

2. The project plan and schedule for an e-business system

The project plan for an e-business system will involve all of the stages shown in Figure 10.6.

This diagram also shows how the final part of the book is structured.

• In Chapter 10 we review the activities needed during the initiation phase of a project that involves the creation of a change management programme including project planning, managing organizational change and risk management. In this chapter we do not consider feasibility analysis since assessment of the costs and benefits of the e-business system have already been considered as an aspect of strategy as described in Part 2.
• In Chapter 11 the analysis and design phases are described. In these the requirements of the organization and users of the system are defined and translated into a design from which the system can be built. Analysis and design occur in an iterative fashion through prototyping as described in the section that follows on prototyping.
• In Chapter 12 the final stages of developing the e-business system are described. These include writing the program code, building the databases, migrating data, testing the system and managing the changeover to the live system. Chapter 12 also describes the maintenance of the system once it is live. This is monitoring the system and enhancing it as bugs and opportunities arise.

These stages in developing an e-business system use well established approaches to building

IS based on the systems development lifecycle. But significant differences project man­agers need to take into account are:

• The timescales for delivery of the systemare compressed compared to traditional applications – the system needs to be developed in ‘Internet time’. Prototyping and making activities such as analysis, design and testing which occur in parallel are used to achieve tight deadlines, as is the use of off-the-shelf systems perhaps hosted with an ASP (Chapter 3).
• The e-commerce system may be hosted outside of an organization so we need to consider the constraints imposed by hosting the site externally with an ISP and integrating external components of the systemwith data stored and processes occurring inside the organization.
• The focus of the project is on content and services rather than on application; this means that delivery of information is the key.
• Because the system is customer-facing and on the public Internet, speed and availability are crucial, as is securing the system from malicious hackers and spammers.
• Analysis and design are arguably more closely related in an e-commerce implementation since the usability of the site is critically dependent on the needs of the user and the prototyping approach is used to achieve users’ needs.
• Once launched the site should be more dynamic than a traditional application: an effective site will be updated continuously in response to customer demands. The solution is never complete.

With the use of tailored off-the-shelf packages such as Siebel’s CRM solutions or SAP’s supply chain solutions to implement e-business, the analysis, design and build stages tend to be different from bespoke IS implementation. The analysis stage is equally important, but will focus on mapping the facilities of the off-the-shelf software with the existing business practices. A vital decision is the extent to which the company will change or adapt its prac­tices and processes to match the software or the extent it will be possible to tailor the software to match the processes. With a tailored off-the-shelf approach it is inevitable that a move away from the existing business processes and practices will be required.

The design phase will require much less input than for a bespoke system. It will focus on issues of how to tailor the user interface, database structures and security of the off-the-shelf package to the needs of the e-business solution. The build and implementation phases will still be involved and, as for any implementation, the project manager will have to schedule software and database configuration, data migration, testing and training.

3. Prototyping

Prototyping is a common approach to the development of e-business systems; its essence is that it is:

• Rapid – Prototyping is part of a systems development approach known as ‘RAD – Rapid Application Development’ since the time from inception to completion is reduced to months rather than years. More rapid development is achieved through reducing the length of time of the analysis, design and build stages by combining them in conjunction with the use of graphical software tools with which applications can be built quickly from pre-assembled components.

• Simple – Skeleton applications are produced as prototypes that do not contain all the functions of a system but are a framework which gives a good indication to users of the information available and the look and feel of an application. They can then comment on it and say, for example, ‘this information is missing’ or ‘we like that feature, but it would be nice to do that also’ or ‘that feature isn’t necessary, it’s not what we meant’. The proto­type may initially be storyboarded as a ‘paper prototype’ but is usually produced as a series of screens that can be interacted with, but are not connected to a database.
• Iterative – Prototypes are produced often at a frequency of one every few days or weeks so that the comments from the last review can be fed into the evolving system.
• Incremental – Each prototype incorporates the feedback from the previous review, so each version of the application has a limited number of new features.
• User-centred – Users are involved at all stages of development, in describing the existing system, reviewing the prototypes and testing the system.

The stages involved with prototyping are to first identify the user requirements in outline and then rapidly develop a working prototype which the users operate to check the software proposed is in line with their needs. Once the first prototype has been produced there are several alternatives:

• iterate and produce further refinements, which often occurs throughout the specification stage; when a satisfactory version has been produced other alternatives may follow;
• develop module prototypes – prototype key views of the data from a workflow system or Lotus Notes or important data entry dialogues;
• throw away the prototype and develop a more robust version of the software for the produc­tion version. This is often prudent, since in rapid prototyping some corners have to be cut so it may not be optimized for performance or may not have exception handling features.

A frequent general problem with prototyping is to do ‘demonstration prototyping’ rather than ‘hands-on’ prototyping. Often prototypes are merely shown by developers to clients for general feedback and not used ‘hands-on’ until after several iterations of the prototype when many more features are integrated. This causes delays because problems that could have been trapped earlier will only become apparent at a late stage.

The prototyping approach is now ubiquitous since it reduces the risk of major design, functional or informational errors during the construction of the application that may be costly and time-consuming to fix at a later stage in development. Such errors will hopefully be identified early on and then corrected. The iterative approach is intended to be rapid and a site can be produced in a period of months or weeks.

Agile software development

Today, the concept of prototyping has been extended across the whole lifecycle for develop­ing web site functionality or software applications where it is known as agile software development. The goal of agile development is to be able to create stable releases more fre­quently than traditional development methodologies, i.e. new functionality will be introduced through several releases each month rather than a more significant release every few weeks, months or even years. The approach is sometimes known as ‘permanent beta’. Another difference with agile development is the emphasis on face-to-face communication to define requirements rather than detailed requirements specifications.

Scrum is a methodology that supports agile software development. Scrum involves these stakeholders including the scrum master who is effectively a project manager, the product owner who represents the stakeholders such as the business owners and customers and the scrum team which includes the developers.

Scrum is based on focused sprints of a 15-30-day period where the team creates an incre­ment of potentiallly releasable software. Potential functionality for each sprint are agreed at a sprint planning meeting from the product backlog, a prioritized set of high-level require­ments. The sprint planning meeting is itself iterative with the product owner stating their requirements from the product backlog and the technical team then determining how much of this they can commit to complete during the forthcoming sprint. The term ‘scrum’ refers to a daily project status meeting during the sprint. See www.softhouse.se/Uploades/ Scrum_eng_webb.pdf for an overview of the process.

The principles of agile development are encapsulated in the Agile Manifesto (http:// agilemanifesto.org/) which was agreed in 2001 by proponents of previous rapid develop­ment methodologies including the Dynamic Systems Development Methodology and Extreme Programming. The Agile Manifesto is useful in illustrating the principles of agile programming it contrasts with traditional approaches. The text of the manifesto is:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Source: Dave Chaffey (2010), E-Business and E-Commerce Management: Strategy, Implementation and Practice, Prentice Hall (4th Edition).