- Technical Scope;
- Individual areas of responsibility;
- Initial estimates of time and cost.
(Meredith 2000)
Following this meeting department heads will compile initial plans covering their individual areas of responsibility, including tasks and expected costs (Meredith 2000).
A follow up meeting will see all plans being scrutinized by the group and eventually combined into one master plan. Once the project champion has approved the plan, changes will require formal agreement.
Project Plan
A plan is an explicit statement of intention that identifies both objectives and the actions needed to achieve them (Naylor 1999).
Plan Objectives
- Provide a baseline against which the project progress will be measure;
- Define the stages of the project;
- Define the main products and activities to be completed, and the milestones to be achieved;
- Illustrate a complete set of schedules and resources required to complete the project;
- Define the tolerances for the plan.
Timescales
Current estimates predict project completion within 4 months and 1 week, well within agreed timescales. Leaving enough time to monitor and evaluate the system. The total working days spent on the project will be 72 (excluding all bank holidays and weekends). A list of our milestones can be seen below.
Budget
Project budget and timescale are major parts of the plan (Meredith 2000). At this stage it is estimated that the following man-hours and funding will be required:
To ensure staffs are aware of when they are scheduled to work on this project a breakdown has been compiled and is found at Annex A.
Business approach used
Our corporate approach to implementing systems at Direct Consultancy is to follow the Waterfall model. This way we outline a series of steps that should occur when building an Information System. The approach recognises that systems are developed in a series of steps or phases with each step being completed before moving on to the next. It highlights the importance of user requirements being established before programming or design begins (Bocij 2003).
The sequence of phases in the waterfall model:
(Bocij 2003)
Hierarchal structure & chain of command
At Direct Consultancy we operate on a functional basis, allocating a departmental head in charge of each function. This allows us to perform many tasks at once and place people together with the same skills. For a diagram of our hierarchal structure see Annex B.
Plan Requirements
Constraints: To identify possible constraints within our project a Gantt chart was created (Annex C). Maylor (2003) identified constraints could be:
- The critical path of the project. Our critical path (Annex D) runs from the start date through to the end of the project. Dates therefore that are placed on the critical path are fixed and cannot be moved;
- Human resources that are placed on the critical path.
Due to limited resources and time, some specific engineering activities were outsourced to Techno Services reducing time and human resource constraints. The table below highlights the activities and reasons behind the decision to outsource.
Other forms of constraints that were identified are start-to-start and finish-to-start. By producing a Gantt chart (Annex C) and precedence network (Annex E) we were able to examine and allocate resources effectively. For example once the supplies were ordered for systems implementation we had to put a constraint on the delivery due to the lack of space to store the supplies.
Assumptions: This plan assumes the availability of resources as listed at Annex A. It also assumes Techno services will deliver according to contract. The plan assumes a five-day working week with all weekends and bank holidays unavailable.
Lead-time estimates for new hardware and software include current contractual agreements with DC’s suppliers.
Dependencies:
- The project will not proceed beyond the initiation/analysis phase without the authority to proceed (sign off of project proposal document);
-
The project will not proceed beyond the design phase without a signed Project Mandate. The project requires full and free access to Sterling Motors current Management Information System.
For a full list of dependencies please refer to our Gantt chart (Annex C)
Tolerances
A precedence network, (Annex E) was used to identify tolerances within the project. This facilitated a reduced allocation of resources on activities which were not critical and had days of float. For example the activity of ‘choosing an appropriate database management system’ (ID15) only 1 employee has been allocated, despite it being a significant task, because there were 2 days float between that and the next activity.
Planning
Planning Steps
The approach to planning will be as follows:
- Determine the terms of reference – constraints, objectives, deliverables and Scope;
- Identify the activities;
- Prioritise and sequence the activities;
- Produce estimates for each activity;
- Allocate resources;
- Schedule the plan;
- Agree the plan;
- Publish the plan;
- Implement and control the plan.
(Cap Gemini 1996)
Planning Control
Planning a project of this size is complex. At this early stage MS Project has been used to illustrate our operational plan (Annex A), however, plans will migrate to Project Manager Workbench (PMW), as it is compatible with Team Workbench (TWB), the timesheet recording system.
The Project Manager will be responsible for the co-ordination and communication of all changes to the approved plan. Any change to the project specifications will be subject to change control as described in section 4.1 of this document.
Contingency Planning
All projects contain an element of risk; we have identified the following activities as containing the highest levels and have listed the current plans to resolve these issues if necessary:
Contractual Details
Direct Consultancy will provide in-house analyst programmers to ascertain system requirements through consultation with nominated parties at Sterling Motors and design and build the new ERP in line with customer requirements and expectations. Various infrastructure work is to be carried out by a third party, Techno services.
Monitoring and control
Planning and control are inextricably linked, whilst planning sets the organisational direction, it is control that maintains it (Maylor 2003). Control is the comparison of actual progress against planned; it begins with detailed and accurate planning (Meredith 2000). The quality of control depends upon the quality of the plan and the frequency and accuracy of monitoring. The Project Manager will be responsible for monitoring the plan on a daily basis. Team members are required to complete timesheets on TWB daily; team leaders are to ensure this happens.
When carried out together, planning and control form a cycle. The diagram below illustrates the continuous cycle to be followed throughout the project life:
(Naylor 1999)
The diagram demonstrates that planning is not a one-time activity, but an ongoing process that must be flexible enough to allow change if required. Control is a two-stage process, comparison and correction. Effective comparison requires observation of outcomes at every stage of the project to check planned against actual development (Naylor 1999). This process will form the basis for stage end reports.
The clarification of objectives can also assist in project control they not only establish what is to be measured but stipulate the required performance standards to be achieved (Naylor 1999).
Change Control
As the project progresses it is expected that stakeholders may change their views about their requirements. Therefore project control must be capable of changing the inputs to the process in line with these requirements (Meredith 2000). To prevent ‘Scope Creep’ and spiralling costs, once the customer requirements document and project mandate have been authorised by the client, any changes requested either by DC or SM will be subject to change control. DC’s change control system is illustrated below:
If agreed with sponsor
Is passed to raises
to inform
who
appoints
which is passed to
who which
generates comprises
gives
go-ahead to
who generates
A copy of the change control form can be found at Annex F. All change requests (CR) will be channelled through the DC’s Change Control manager. Changes will be subject to agreement by both parties and any change to product specifications or increases in project time or costs must be authorised by the client (Meredith 2000).
Financial control
Work break down structures
Work breakdown structures are simply a list of project activities (Maylor 2000); major activities are broken down into sub activities to allow for clear and precise recording of time and costs.
In this project we have a number of different teams working together. As each team will work on it’s own area of the WBS structure there is a danger that they can become entirely focused on that, loosing site of the project as a whole and how their work interfaces with others. To overcome this potential problem an interface manager has been appointed to co-ordinate the different parts of the WBS.
Control of hours booked to project WBS
IPSO TWB Timesheets are automatically generated from the plans controlled by the PM. Users record their time against their list of tasks, and the plans are automatically updated with approved time. This restricts the allocation of time booked to the project to the resources designated by the Project manager and therefore reduces the risk of incorrect time allocation adversely affected the project costs.
Purchasing
All purchases for the project must be allocated to the project cost code. All requests for purchases must be authorised by the PM before processing. It is the responsibility of the purchasing department to ensure the PM has authorised requests.
Reporting
The project is divided into 7 Stages:
- Initiation/Analysis
- Design
- Build
- System Test
- Acceptance
- Implementation
- Training
The completion of each stage will generate a stage end report to be distributed to the project champion and the client.
Monthly review meeting will be held to discuss progress. During the course of these meetings DC will provide SM with the following reports:
- Project progress reports
- Index and status of all CR’s
- Exception reports (if any raised)
- Financial update
Maintenance and Support
As part of project sign off a help desk will be created for continuing user support, calls will be charged at standard charge out rates, however problems that arise through errors on the part of DC such as bugs will not generate charges for a period of 6 months.
Evaluation Methods
Project success will be measured in terms of:
- Time – was the project delivered on time?
- Cost – was the project delivered within budget?
- Quality – does the product meet the requirements as specified by the client?
All of the above will be measured against latest version of the plan to incorporate any applicable changes as a result of change control.
Customer satisfaction depends upon products perceived performance against the buyer’s expectations (Jobber 2001). Satisfaction occurs when performance matches or exceeds expectations; it is therefore essential to carefully manage customer expectations from the outset. The customer requirements document (CRD) formalises expectations, therefore planning and actual activities must always take into account what has been agreed with the customer in the CRD. Post implementation review will involve comparing the CRD with the finished product; input will be sought from both the project team and the client.
In the interests of long-term improvement it is necessary to conduct reviews of projects using appropriate techniques (Maylor 2003). Reviews can help identify required procedural changes or training needs for individuals (Maylor 2003).
The project sponsor, who will be assisted by a PM of his choice, will carry out project review.
Immediate project review
Evaluation will require the complete project history. All changes made to the project during its life will be recorded and preserved for the purposes of project termination (Meredith 2000).
Staff appraisals will be carried out at the end of the project. Additionally, the project sponsor will conduct an audit of the management, distributing a questionnaire to the project team asking them to give feedback on certain characteristics of the PM such as approachability, openness and ability to delegate (Maylor 2003). Feedback received can help individuals identify the positive aspects of their behaviour and areas where improvement is needed.
Longer term Project review
This will be carried out in a constructive manner and will include:
- Focus on processes – avoiding focus on individuals
- The use of factual data only
- The consideration of alternatives – incorporating scenario’s of possible events and considering what would have happened if they had occurred, and an exploration of how the project system would have coped under different circumstances
Review of calls to the help desk and their nature can help establish product quality. Ongoing measurement of project outcomes is considered a useful measure for IT suppliers (Maylor 2003).