E-business Implementation:

Dougal Watt

• Publisher: Routledge
• Year: 2007
• eBook ISBN: 9781136409417
• Topic: Business
• Subtopic: Business General
• Index: Business

'E-business Implementation' is written as a complete guide to successful e-business delivery, from both a project management and a detailed technological perspective. E-business provides a powerful mechanism for organizations to increase productivity and lower costs. However, in order to utilise these considerable benefits, companies must ensure their e-business is implemented correctly and is appropriate to their market segment. 'E-business Implementation' provides a comprehensive guide to successful implementation and is divided into three parts: * Part one begins with a project management structure designed to deliver successful e-business functionality within time and budget, while avoiding the high failure rates common to many technology projects. * Part two details key concepts, technologies, products, vendors, benefits, limitations, and high-level design architectures for e-business, in a phased and risk-managed approach. These include publishing through the Internet and Intranets, portals and content management systems, transacting using e-commerce, integrating internal enterprise applications, integrating with external partners and suppliers, and responding in real-time to changing levels of demand through dynamic e-business and web services. * Part three details a set of critical foundation technologies that must be implemented correctly for the e-business initiative to be successful. These technologies include e-business development languages such as Java, XML and .Net, hardware platforms and their operating systems, security and networking systems, the Internet Domain Name System, and Open Source technologies.

Part One

Project management phases

1	Structuring an e-business project

When implementing an e-business project a number of processes and structures are required to ensure the project is successful. These include determining the correct structure to guide the course of the project, selecting the appropriate technology to implement, having the correct support technology in place to ensure the implementation will succeed, and choosing the right staff to carry out the project.

Many projects fail because these four elements have not been set up and employed correctly from the beginning. For example, the Standish Group conducted a survey of project failures with 365 organizations of all sizes across a wide range of major industry sectors. Focus groups and personal interviews were also conducted to provide a qualitative assessment of the survey.

Results of this survey showed that over 80 per cent of all projects suffered some form of failure. Only 16.2 per cent of surveyed projects were delivered within time and budget, while 52.7 per cent of projects were delivered but ran over budget, over time and had fewer features than were originally intended. Projects that were cancelled during their development formed 31.1 per cent of the sample.

Project failures included having to restart projects (94 per cent of all projects), cost overruns resulting in an average increase of 189 per cent of original cost, and time overruns, resulting in projects running an average of 222 per cent over original time estimates. Of all companies surveyed, an average of 61 per cent delivered the features originally specified.

The survey found key reasons projects were delayed or failed completely included lack of planning, low user input, incomplete or changing specification of requirements, lack of resources and competent staff, incompetence with technology, unrealistic timeframes and unclear objectives.

A later survey conducted in 2000 by the Standish Group found that 28 per cent of commercial projects were successfully delivered on time and budget with the required functionality. Of the remainder, 49 per cent suffered from partial failure and 23 per cent complete failure. In the government sector 24 per cent of projects succeeded while 50 per cent failed partially and 26 per cent failed completely.

The improvement in figures for project success between 1994 and 2001 was attributed to smaller projects being conducted, which have a higher likelihood of success.

Creating a successful e-business project therefore requires the project be planned correctly from the outset, structured into discrete project steps with identifiable and achievable goals, and the correct staff selected before the project begins.

The following sections discuss these issues, detailing the correct structure and process for conducting an e-business project, and the staff required for fulfilling the project.

1.1 E-business project management

The key to running a successful e-business project is to provide sufficient structure and planning to ensure project success. Success is typically defined as the project meeting its business requirements without running over budget or over time.

Therefore, the project structure should include a set of critical elements that govern the lifecycle of the project and its resulting outcomes. These elements follow the project from its inception to completion, and include the initial project planning, the requirements phase, the solution research phase, the design phase, the build phase, the pilot phase, the implementation phase and the project handover phase. Each phase should be completed with a corresponding set of documents that detail the information gathered in each phase, and the outputs each phase produced.

The initial project planning phase determines the broad outline of the project. This is used to guide the initial project structure, including an outline of what the project is intended to deliver, and covers preliminary project planning issues such as potential technologies, budget, skills and timeframes.

The requirements phase extends the initial planning to determine the core set of deliverables the project should satisfy, which are in turn used to gauge project success. These cover all areas of business and technology relevant to the company, and are subject to analysis to prioritize the most relevant set of requirements to deliver with available resources.

The solution research phase is used to conduct detailed research into potential technology solutions to fulfil the initial project planning and requirements deliverables. This is then analysed and a set of potential technology solutions researched, with the best solution being recommended to proceed into the design phase.

The design phase takes the recommended solution from the research phase to create a high-level conceptual design for the solution. Following best practice, this design is then audited internally and externally to prove its feasibility, before a detailed design is created to cover the chosen technology solution in more detail, including application design, security systems, and the deployment configurations.

The build phase uses the results of the design phase to create the intended solution. Blocks of functionality are coded, deployed and tested using a build process across development, testing and production environments. The complete solution is iteratively assembled using this process by creating and integrating successive blocks of functionality until all chosen requirements are satisfied by the solution.

The pilot phase deploys an initial version of the completed solution for early testing by stakeholders (the members of staff or partners and suppliers who either sponsor a project or who are most affected by its implementation) and users. This allows the project to tune the solution to better fit requirements and satisfy deployment issues.

The implementation phase expands on the pilot phase to deploy the final solution across the business to all relevant business users. This requires the solution be deployed in a production capacity, capable of supporting all users and workloads, and the training and transition of users from old work practices to the new solution.

The handover phase collates the output of all previous phases into a set of support resources for operational and support staff. It also includes training of support staff, and the creation of final project documentation.

This structured approach to designing and running a project is depicted in Figure 1.1.

Figure 1.1 Structured project planning

This structured process begins with the initial project planning and requirements phases, and progresses through the main project execution phases until the completed project handover phase, where the project is turned over to internal teams for ongoing support. Each phase requires a set of inputs and produces a set of documented outputs that are required for each successive project lifecycle phase. These well-documented outputs are a fundamental advantage to this approach, and are used for project support, future developments, and auditing purposes.

The following sections discuss the elements of this structured approach to running e-business projects in detail.

1.2 The project planning phase

Before a project begins it is essential to have a broad understanding of the issues the project will address, and how the project will fulfil these issues. These are detailed in the project initiation document, which details the business problems facing the company, a broad overview of potential technology solutions, and estimates of the amount of time the project will take, what it will cost, and what staff will be required. These estimates are intended as a guide to assist in setting up the project, and are finalized in successive project phases.

An internal project manager and an internal or external e-business technical architect typically conduct the initial project planning, with each team member occupying distinct roles. The project manager is responsible for managing and tracking the project to ensure each phase is being delivered successfully. They typically create preliminary budgets and project timeframes in collaboration with the e-business technical architect. The e-business technical architect conducts preliminary research and assessments of the likely technologies necessary to solve the business problem.

The initial project planning is critical to establishing a clearly understood context for the decision-making, through a focus on why there is a need for the e-business project. This involves getting the different stakeholders affected by project decisions or involved in the decision-making process to understand and agree with the problems that are to be addressed. This is critical for ‘buy-in’ to the project, so that possible conflict between different stakeholders is prevented or minimized.

The core element of the initial project planning is the statement of the nature of the business problem confronting the company. This typically provides the motivation for the company to conduct the e-business project, and the extent to which the company resolves this problem determines the success of the project. It is therefore the focal point for understanding and determining intended technical solutions.

The statement of the business problems should include the nature of the business, the challenges facing it, and what business problems the technology is required to solve. It should also incorporate statements of the medium-term and long-term strategic views of business and technology needs. This ensures that all proposed solutions are aligned with medium-term and long-term plans, thus preventing selection of temporary solutions that will be discarded in future. The statement of the business problem should be expressed in a very simple and clear form, as shown in Figure 1.2.

Figure 1.2 Statement of business problem

Defining the business problem at this stage is also critically important as it provides a baseline to assist in minimizing the risks that may arise from making incorrect decisions during the course of the project. Frequent sources of risk include changes in business issues arising during the project, which in turn invalidate subsequent stages in the decision-making process, and potentially the technology solution selected and deployed.

However, these risks can be mitigated if the business issues have been made explicit at the outset of the project. Any changes in business issues or other requirements during the project can then be compared to the original assumptions, and if they differ significantly, the project can be modified to accommodate them without seriously jeopardizing the outcome.

Once the business problem has been stated, the e-business technical architect conducts preliminary research to provide prospective technology solutions and preliminary budgets and timeframes. Typically, this requires the e-business technical architect to research a range of appropriate design patterns and products from technologies commonly applied to specific business problems. These patterns typically include collections of technology architectures and products, design and development methodologies, and deployment factors utilized in previous e-business projects.

Selection of a range of appropriate design patterns and products is complicated due to the very large volume of technology information available, and the complexities and risks inherent in matching technology solutions to business problems. Therefore, this requires the e-business technical architect to have specialist knowledge, experience and skills of e-business technology, a broad and detailed understanding of the technology industry as a whole, and the ability to match technology solutions to business requirements.

The use of a formal research approach by the e-business technical architect provides several benefits to the project. It offers the ability to shorten the research phase, as the design patterns and products provide a structure to guide research. As the design patterns utilize proven pre-existing successful technology strategies, they lower the risk of making incorrect choices and allow the architect to reduce project timeframes. Finally, the use of such patterns shifts the solution focus away from individual point solutions reactively designed to solve a single business problem, and permits the e-business solution to be synchronized with long-term strategic planning within an enterprise.

This preliminary research must also consider a number of factors that are in turn related to the statement of the business problem. For example, the statement of business problem listed above would influence the technical architect to research e-business design patterns capable of targeting multiple channels, including online and offline channels, and supporting CRM functionality. They would also research solutions capable of integrating with financial services back-end systems, typically legacy AS/400 or mainframe products, and products that can be used with their partners and suppliers. Their choices should also be capable of extension to web services in the future, allowing for alignment of the solution to future medium-term and long-term strategic goals.

The factors affecting the preliminary decisions of the e-business technical architect can be classified into business-specific factors, and general external factors related to industry, vendor and technology trends.

Business factors

Business factors are comprised of business issues specific to the company that may affect initial technology choices. These typically include areas such as the company industry sector, available budgets, current technologies in use, and available staff skills and timeframes.

Industry sector factors are unique to each industry segment a company is active within. For example, manufacturing or retail businesses frequently require real-time information regarding stock levels, while service specific businesses may require a single complete view of all customer information for call centre staff.

Budgets provide limits to the purchase and implementation costs of technologies. They also constrain other resources employed during the project phases, such as skills and levels of staffin...

Table of contents

• Cover
• Full Title
• Copyright
• Table of Contents
• Computer Weekly Professional Series
• Overview
• Part One - Project management phases
• Part Two - E-business technology phases
• Part Three - E-business supporting technologies
• References
• Index