Implementation and project management

Overview Project outline People Process Product Implementation SMCN home

Overview Our implementation and project management services can be readily applied to new and existing projects. Like most people we employ a methodology that is based around PRINCE 2 (this respects the fact that whilst Prince 2 is an extremely comprehensive methodology, it can be readily ‘stripped down’ and tailored to specific project needs). Our experience suggests that projects don’t generally fail nowadays because of hardware or software malfunction, sadly, all the problems typically come down to people. This underlines the need for an effective and reliable methodology. There are two major risk factors that apply to all projects, these and consequences of neglect are summarised as: - Project organisation not defined/accepted No ownership Moving targets Replicate existing systems Project process not defined/accepted No vision / focus No strategy / direction Delays and disappointments Poor payback Our methodology and means of safeguarding against these risks are outlined below. The methodology can be readily flexed to work effectively with specific supplier packages or similar methodologies. The following notes relate to the preceding diagram. _____________________________________________________________ 1: Project outline We advocate the need for a low risk strategy that establishes a business partnership structure between the customer and any other involved parties. We recognise the need to develop a customer specific ‘Product’ deliverable and ensure that the Implementation methodology is optimised for the environment. The project should incorporate Company Objectives and act as a catalyst/vehicle for managing ‘Change’. Wherever possible we advocate the best use of internal competencies. Software implementation projects in particular will provide generic business solutions, which will mean a degree of compromise. The upside being that they should present a future proof product investment. The project outline is intended to create and maintain a project structure designed to: - Provide control Protect investment Deliver solutions Specifically the project must have an agreed methodology for: Delivery/Commissioning Configuration Acceptance Conversion All this must be in a framework that will control of costs and timescales. Additionally, we must define owners and escalations procedures. The starting point of any project is that you must understand your business needs. You must also set a realistic budget, have evaluated the offerings and selected a solution that are confident about and committed to. Reference - Product, Implementation, Support – are essential. The project objectives should be clearly defined, they should be: Specific Measurable Agreed Realistic Timely 1.1: People All the people involved with the project should have clearly defined roles and responsibilities, more on this later. 1.2: Process The project outline must consider the project process; further details will be added in the planning stages. The following diagram presents a typical project process: - 1.3: Product The project outline must consider how the product will be configured to support a proof of concept; further details will be added in the planning stages. 1.4: Objectives Basic targets should be an early realisation of benefits supported by a rapid transfer of ownership. It’s a good idea to broadcast project goals and provide clear visibility. 2: People A typical project structure would involve the following key responsibilities Customer: Sponsor, Manager, Administrator Supplier: Site Consultant, Account Manager Steering committee: Project sponsor, Project manager, Functional heads Project team: Project Manager, Functional representatives These individuals are tasked with establishing a joint strategy for defining the content and processes for delivery and Implementation of the Business solution. 2.1: Structure Specific roles and responsibilities are outlined below. 2.1.1: Sponsor The executive level owner of the project, this is the person who must ultimately accept responsibility for the project. 2.1.2: Project management The Project Manager has the following responsibilities: - Project plan Resource management Policy decisions Executive briefings Specifically the Project manager must monitor and report project status to the company. They must also evaluates project team performance (on an on-going basis) and ensure that goals and objectives are being met The Project Manager is also responsible for the end product and must ensure that the end user training and documentation are completed satisfactorily. 2.1.3: System administrator The system administrator is the owner of the new system; this individual is responsible for the system’s day-to-day operation. Specific areas of attention being performance, security and resilience. 2.1.4: Steering committee The responsibilities of Steering Committee Member can be summarised as: - Project definition and direction Support - financial and otherwise Project participation Problem resolution Executive support The steering committee should comprise the sponsor, the project manager and the heads of the major functional areas affected by the project (which often equates to the Board of Directors). 2.1.5: Project team The Project Team must represent all the major business areas affected by the project, typical representations coming from: - Sales Manufacturing Stock/Warehousing Planning/purchasing Accounts Quality IT The responsibilities of Project Team being: - Must learn all about their applications Responsible for working on project tasks Responsible for calling on extra help Defines how the product will be used Responsible for delivering user training In short, the project team must represent the business needs and become expert in the business solution. They will be responsible for system configuration, system conversion and delivery to the end users. 2.1.6: Super-users Where appropriate Super Users should be seconded to the project. These are specific individuals who would have a the detailed knowledge to represent the needs of a particular function area, 2.2: Process ownership Process ownership involves having the correct representation on a project for the business areas affected. Its important to recognise that the correct process owner is the person who will define what the process should be rather than what it may currently be. Typical process ownership would involve the following areas. Sales Manufacturing Stock/Warehousing Planning/purchasing Accounts Quality IT 2.3: Empowerment Empowerment is an all-important but often neglected aspect of every project. When individuals are seconded to project teams and work groups they must understand their role and be empowered to deliver. Specific areas requiring attention follow. 2.3.1: Availability There’s little point in dumping responsibility on people without giving them the capability to deliver. Consideration must be given to current workloads and demands and where necessary provide additional support. 2.3.2: Skill As with availability, there’s no point in assigning someone a responsibility that they do not have the skill to deliver against. To counteract this issue the necessary skills should be defined and the current skills assessed. Training effort should be invested as necessary. An obvious point that should be considered is that the people who are readily available may not be the best candidates for the job! 2.3.3: Training Any skills shortfall should be addressed be appropriate training. This could include training in technology and the implementation methodology. 2.3.4: Roles and responsibilities These should be clearly defined and broadcast 3: Process Software implementation projects will typically involve use of packaged system. There must be an agreed methodology for: Delivery/Commissioning Configuration Acceptance Conversion The project process must be adaptable to sympathetic to the company’s ability to absorb change 3.1: Define process scope The project scope should be defined in terms of its functional scope – how much of the business does it affect? With modern integrated systems there is a tendency for software implementations to be particularly wide reaching, manufacturing systems, for instance would typically replace most existing systems with the exception of human resources and payroll. It’s also likely that a prospective solution would have its potential extended by use of specialist partner products (e.g. Business Intelligence systems such as Cognos or Crystal Reports). The important requirement is to declare the scope and then stick to it. Scope should only be extended through a proper change control process and then only if there is a strong justification. It’s often better to see an implementation extend its scope across a number of subsequent phases rather than unduly broaden and complicate the initial scope. It makes good sense to see the initial implementation phase as a foundation that replaces existing systems; this foundation will then support additional stages. 3.2: Create project mandate The project mandate is a document that formally records: - Key personnel Project Background Project Objectives Business Processes Constraints Accepted areas of Non-Conformance Interfaces Third party applications Quality Exceptions Outline Business Case (reasons) Associated Documents & Products Executive sponsor & Project Manager Customer(s), User(s) other Interested Parties The mandate provides a fixed point of reference for any project and is a valuable record of a projects expectations and deliverables. 3.3: Define business model The business model should be defined that represents the major processes. 3.4: Define representative data For each data entity that is included in the model there should be agreed representative data that will be used in the proof of concept stage. This data should typically use real examples that represent the simple, the normal and complex cases. Typical data entities that would be considered are as follows: Chart of accounts Locations Products Customers Suppliers. Transaction data can also be defined that will effectively prove a systems capability to support an existing business process. 3.5: Create system environments Before any configuration or testing work can commence it is necessary to define the appropriate system environments. Some obvious considerations for data environments (as distinct from software programme environments) being: - Demonstration system Test system Training systems Model base system Live system These environments would need appropriate security controls and copy/refresh routine. 4: Product The approach to developing the software product will vary according to the software itself and the scope of the implementation. It is also expected that the software supplier would (should!) have a proven and well-defined approach to developing the product configuration. 4.1: Project team training If there is to be a transfer of product ownership from the supplier to the customer then the Project Team should be educated on a ‘Train the Trainer’ basis. The Project team will then be responsible (with consultancy support from the supplier) for system configuration and ultimately end user training. 4.2: Build model system After initial training a model system should be built to support proof of concept trials. This approach provides for a trial configuration that: - Is based on the company business model Provides for minimise Risk Defines the implement able system Is the basis for detail planning Produces a franchised deliverable 4.3: Proof of concept trials The proof of concept trial involves building and demonstrating a system configuration that will meet the requirements as defined in the project scope. The trial should stay focused on the defined scope and thereby provide for the essential features rather than stray into ‘wish lists’ and ‘nice to haves’. Its important to recognise that trial should demonstrate to functional capability to support the system, it would not, at this point, be expected to handle realistic business volumes. For that reason it is often preferable to manual load the system. Note that the decisions made in the trial will form the basic rules for later data conversion and volume testing. The proof of concept trial is intended to simulate key operating conditions; it will also assist with the definition of Reports and Documents. 4.4: Proof of concept acceptance Proof of concept acceptance defines a base configuration that will then be developed into an implementable system. This next stage will involve a number of activities that are designated to take the configuration from a ‘workshop’ to a live setting. Additional areas of activity being: - Interface development Data conversion User procedures User training Switchover planning Help desk set-up Etc 4.5: Define pilot project Where possible a pilot site should be identified where the system can go live in a restricted sense. Pilot implementations are particularly effective at building confidence prior to a full system ‘switch on’. They represent a safer alternative to the ‘big bang’ approach. It should be noted that often due to the integrated aspect of existing systems that a pilot is simply not practical and there is no alternative to the ‘big bang’. 4.6: Build pilot The pilot system will be built prior to moving into the implementation stage. 5: Implementation Typical implementation phases are presented below: - Phase 1 Project set-up and start Phase 2 Education and planning Phase 3 System modelling and configuration Phase 4 Implementable systems definition Phase 5 Introduce and audit live system The specific activities required to put a system live include: Data transfer User training Changeover planning Pilot go-live Pilot implementation audit Implementation rollout Overview - BACK TO TOP