The first activity within the Project Definition phase is the development of a Project Mission Statement. The Mission Statement should be either developed or approved by the Executive Sponsor, the individual responsible for funding the project.
The Mission Statement should describe, at a minimum:
The scope of the project (Locations, Applications, Product Lines, etc.)
The project objectives
The primary business reason for the project
The Mission Statement may include strategy information, at a high level, but its primary purpose is to define the purpose and scope of the project. It may also include a description of the major project deliverables, the responsibilities of any outside parties, and designation of responsibility for planning and managing the project.
The Mission Statement will typically not contain a detailed schedule or specific deliverable dates. Those can only be determined after the project effort is estimated and resource commitments are made.
For the same reasons, estimates of project costs and specific team member names are usually omitted from the Project Mission Statement.
The Project Mission Statement must be agreed to by both user management and project management, and should be included in all project orientation materials for new team members.
Once the Mission Statement is documented and approved, it is time to identify the resources who will be responsible for carrying out the project's mission. The project team may include system users, information systems professionals, software vendor employees, and other outside consulting services.
Project Team Organization
The project team may be organized in a variety of ways, but each organization shares some common features: First, each team member has a specific set of responsibilities, and brings to the project a measure of expertise in his area of responsibility. For example, a team member assigned to the project as a representative of the Accounts Payable department would need to have experience in the processing of vouchers and in the payment of the company's suppliers.
Second, a project manager must be designated to coordinate and manage the project activities, and to carry the overall responsibility for the success of the project. On a large project, team leaders may comprise an intermediate level of responsibility between the project manager and the individual members of the project team.
Given that a project team is a temporary organization, assembled for a specific purpose and a limited duration, the reporting relationships in the team need not reflect the relationships within the permanent organization. Caution should be used, however, when assigning team roles which are not consistent with permanent supervisor-subordinate relationship.
Related Teams
Overseeing the project team should be a Steering Committee (sometimes called an Advisory Panel). The Steering Committee monitors the project status through regular meetings, perhaps monthly. Steering Committee members should include:
The Executive Sponsor
The Project Manager
A representative from Information Systems
A Steering Committee should be limited to no more than three or four members. However, the committee's meetings should be attended, at least occasionally, by a management representative from any software vendor or consultant involved in the project.
The Steering Committee may also be used as an escalation point for project issues, and in some cases, for approval of modifications to package software.
Another team whose work may directly impact the project is called a Process Team. A Process Team (or Process Design Team, or Continuous Improvement Team in a manufacturing environment) is looking for ways to improve the company's business processes in order to better serve it's customers, control costs, minimize manual effort, etc. A secondary objective for this team may be to better take advantage of features offered by any new software and hardware being implemented.
Not all systems implementations will include a Process Team, but if Process Redesign, (or "Business Process Reengineering") is included in the project objectives, then such a group will likely be formed. Process Redesign generally complicates a systems implementation, but may greatly increase its business benefits.
Great care needs to be taken to coordinate this team's efforts with the work of the systems project team. Otherwise, the systems project team may be building a solution for a set of business procedures and processes which have been greatly altered.
Roles and Responsibilities
Each team member must clearly understand his or her role in the project. A title, within the project team organization, should therefore be designated for each member. Some examples would be:
Accounts Payable Functional Analyst
Financial Systems Team Leader
Technical Analyst
Project Manager
Similarly, the responsibilities assigned to each role must be documented and understood by the team members. Responsibilities should be described as specifically as possible, while allowing room for assigning unplanned tasks as they are identified.
An example, where a Financial Systems sub-team existed within the project team as a whole, would look like:
|
Role:
|
Financial Systems Team Leader
|
|
Responsibilities:
|
Assist Financial Systems team members in analysis and development tasks. |
|
Identify and resolve issues between the Financial Systems and other sub-teams. |
|
|
Schedule team tasks on a day-to-day basis. |
|
|
Coordinate support from third party consulting resources. |
|
|
Keep management informed of progress. |
|
Resource Commitments
Resource commitments must be obtained for each project resource, whether in-house or representing an outside company. Commitments should include a specific time period, and be obtained in writing.
For resources which will be supplied by a software vendor or outside consultant, the commitment should come from the company's Account Manager or other assigned representative. The best commitment here is a specific name, but many consulting organizations will only commit a skill set, preferring to reserve the right to staff the project as they see fit. This provides flexibility for the consulting firm in managing its resources and clients, but may cause wasted time for the project as resources are replaced and the learning curve is repeated.
For internal resources, written time commitments are just as important. They should come from the line management of the resource in question. A memorandum, citing the project schedule, and asking for a manager's initials as approval, is adequate for this purpose. The project manager needs to discuss the project with the affected managers before formally asking for a long-term resource commitment.
Lastly, the project manager must have approval from his or her manager to stay with the project, even through potential unseen delays or increased scope, to carry the project through to its successful conclusion. Changing project managers in mid-stream is potentially disruptive to the schedule and work environment for the project.
At the end of the Project Definition section of this guide is an example of a Project Team Organization Chart for a package software implementation project.
In this example, the company's project team consists of application experts and technical resources, supported by consulting services from the software vendor. The Organization Chart indicates reporting relationships and lines of communication.
Once the management team has defined the project objectives in a written Mission Statement, and identified the project team members and their responsibilities, the project training plan can be developed. The training plan does not include informal training such as reading the system documentation or unscheduled meetings with co-workers. It identifies specific, scheduled training activities for specific project resources to acquire specific skills.
The training plan consists of two major sections: Project Team Training and End User Training. They differ greatly in their timing, purpose, participants, and training material.
Project Team Training Plan
The purpose of the Project Team Training activity is to prepare the project team members to fulfill their responsibilities during the project. The purpose is not to teach the team members how to use the new system. Project Team Training may include software training, technical training, hardware training, or education concerning project management and methods.
For this reason, Project Team Training must be conducted as soon as possible after the project is organized and team members are identified and committed. Training material should be provided by the software vendor, or hardware vendor in cases where system software and utilities are the subject matter.
If the project involves installing package application software, the bulk of the training may be conducted by the software vendor, and will focus on the individual applications being implemented, and on the technical architecture of the software. If the vendor does not offer training, a qualified third party may be used, but care must be taken to insure that an experienced trainer is used, whose expertise will match the project team's expectations.
For a custom development project, technical training would be a major part of the Project Team Training Plan. It would likely include programming languages, operating systems, system software and utilities, database management and CASE technology.
However, even in a package software implementation, technical support personnel must be included in the training plan. These personnel will be expected to support the installation and maintenance, as well as possible customization, of the software applications.
The Project Team Training plan should be very detailed, specifying:
The name or subject matter of the training course
The start and end dates for each course
The location of the course (on-site, at the vendor's offices, or elsewhere)
The names of the individuals who will attend
In a small-budget project, a tutorial may be used in place of classroom training. However, expertise in the subject matter (software application or technical features) will be limited in individuals having made this substitution. Classroom training creates an interaction and a chance to ask questions that a tutorial cannot provide.
The content of the training should be delivered in sufficient depth to provide team members with a view of how the software works behind the scenes. Accordingly, user-definable system components such as setup options, parameters, report data selection, security features, and system codes should be included in their training. The project team members will have to make decisions during the project about how these items will be set up and used.
End User Training
By contrast, End User Training is based on User Procedures and should only include those screens, functions, and system features that the end user will actually see in performing his or her day-to-day job.
During the Project Definition phase, the exact schedule for End User training will be impossible to determine. Rather, what the training plan should contain at this point is a list of user departments to be trained in each area (ex: Purchasing, General Accounting), and a count of users to be trained in each. This information will tell the project manager enough about the size of the End User Training effort to support estimating the duration of this activity in the overall project work plan.
The following pages illustrate a sample Project Team Training Plan and an initial cut at an End User Training Plan. Together they form the deliverable product from the Develop Training Plan activity.
This example would be appropriate for a package software implementation which included General Ledger, Budgeting, Accounts Payable, Accounts Receivable, Inventory Management, and Order Processing applications.
The Project Team Training Plan has actual dates for each class, and indicates the responsible instructor. It also includes technical courses, and in-depth software set-up training. Here, the classes taught by the software vendor are taught at the customer company's location, while those provided by the hardware vendor are off-site.
Sample Project Team Training Plan
|
Class
|
Days
|
Start
|
End
|
Site
|
Instructor
|
|
Software Overview
|
2
|
1-Feb
|
2-Feb
|
On-site
|
Software Vendor Representative #1
|
|
General Accounting
|
3
|
3-Feb
|
5-Feb
|
On-site
|
Software Vendor Representative #1
|
|
Accounts Payable
|
2
|
8-Feb
|
9-Feb
|
On-site
|
Software Vendor Representative #1
|
|
Accounts Receivable
|
2
|
10-Feb
|
11-Feb
|
On-site
|
Software Vendor Representative #1
|
|
Inventory Management
|
3
|
15-Feb
|
17-Feb
|
On-site
|
Software Vendor Representative #2
|
|
Sales Order Processing
|
3
|
22-Feb
|
24-Feb
|
On-site
|
Software Vendor Representative #2
|
|
Sales Order Setup Options
|
2
|
25-Feb
|
26-Feb
|
On-site
|
Software Vendor Representative #2
|
|
Software Report Writer Tools
|
2
|
1-Mar
|
2-Mar
|
On-site
|
Software Vendor Representative #3
|
|
Software Technical Architecture
|
3
|
3-Mar
|
5-Mar
|
On-site
|
Software Vendor Representative #3
|
|
Programming
|
5
|
8-Mar
|
12-Mar
|
Vendor
|
Hardware Vendor Representative
|
|
Computer Operating System
|
3
|
15-Mar
|
17-Mar
|
Vendor
|
Hardware Vendor Representative
|
The End User Training Plan, prepared here at a summary level, indicates the approximate number of trainees, per department, per application:
Sample End User Training Plan
|
Application
|
User Department
|
# Trainees
|
|
General Ledger
|
|
|
|
|
General Accounting
|
10-12
|
|
|
Budgeting
|
5
|
|
|
Credit/Collections
|
4
|
|
|
Audit
|
2
|
|
|
|
|
|
Budgeting
|
|
|
|
|
General Accounting
|
5-8
|
|
|
Budgeting
|
5
|
|
|
|
|
|
Accounts Payable
|
|
|
|
|
Payables
|
10-12
|
|
|
|
|
|
Accounts Receivable
|
|
|
|
|
Credit & Collections
|
10
|
|
|
Customer Service
|
4
|
|
|
|
|
|
Inventory Management
|
|
|
|
|
Materials Management
|
8-10
|
|
|
Order Entry
|
20
|
|
|
Warehouse Foremen
|
4
|
|
|
|
|
|
Order Processing
|
|
|
|
|
Order Entry
|
20
|
|
|
Customer Service
|
4
|
|
|
|
|
If the training facility accommodates a maximum of 12 trainees, there will need to be two sessions of the Inventory Management and Order Processing classes.
Project team members will normally conduct, or assign responsibility for, End User Training. Outside trainers would require a substantial learning process before training could begin.
The End User Training will be based on user procedures developed after the Conference Room Pilot, rather than on the system's full features, functions, and options. The End User Training sessions will be conducted as close to the system cutover as is practical.
Purpose
The Project Work Plan is the single most critical deliverable from the Project Definition phase. The Develop Project Work Plan activity cannot be omitted for any project, no matter how small or simple.
The Project Work Plan serves several purposes. It is:
A planning tool, allowing project managers to map out the project tasks and determine the size, length and complexity of the project.
A management tool, assigning responsibility to various resources and parties, and establishing deadlines and milestones for project deliverables.
A communication tool, detailing to management, users, and team members what is supposed to happen and when, during the execution of the project.
Work Plan Components
A thorough, comprehensive Project Work Plan should include the following:
A high-level Gantt chart
A more detailed Gantt chart
A designation of primary responsibility for each project task
> A budget, expressed in days or hours, for each project activity or task, including internal and external resources
The Gantt Chart(s)
A high-level Gantt chart should be prepared for even the simplest project. The highest-level chart would at least show the start and completion dates for each project phase.
A more detailed, second-level, Gantt chart would illustrate the timing of each activity within each project phase. A sample second-level chart (showing activities within phases) is provided at the end of the Project Definition section of this guide.
A fully detailed Gantt chart might include a third level of work items: the tasks below each activity. The project tasks would vary greatly from one project to another, depending primarily on the applications and software being implemented.
Care should be taken not to include too much detail in the detailed Gantt chart. A chart showing every single task, no matter how small, would be difficult and time-consuming to maintain. Additionally, an overly-detailed chart can grow to 40 to 50 pages or more, making it ineffective as a communication tool.
Detailed Project Budgets
A project budget is a critical piece of the Project Work Plan. It specifies the target cost of the project as a whole, and of individual phases or activities. In cases where the overall budget will have to be supported with complete detail, the project may be budgeted at the individual task level.
Costs for hardware, package software, network and system software are also important considerations in evaluating the cost of the entire project. However, for purposes of managing a software implementation, they should be kept separate from estimates and budgets for project work.
The work activities, for consultants and internal resources, are budgeted and tracked separately from all other project costs. Budgets may be omitted for internal resources, in cases where management's focus is solely on the costs of outside consulting, programming, or system integration services.
At the end of the Project Definition section of this guide is a sample Implementation Budget. The sample project budget is for an implementation which is being supported by an outside party, in this case a software vendor. Internal resources are budgeted as well, in order to show the full expected required effort.
Once the system hardware (computer, network connections, etc.) are in place, software may be loaded on the system. If the solution being implemented is a single-processor solution, then only one machine will have software installed.
If, however, a Client-Server or distributed architecture is being implemented, several installations must be performed. The number of workstations to be configured for project work depends on the number of participants in Project Team Training and the Conference Room Pilot.
For a package software installation, arrangements should be documented by this time concerning vendor support, including:
Hot Line support
Application expertise and technical consulting
Delivery of upgrades and software fixes
Attempting to use software which was not properly installed can result in frustration, delays, loss of data, and a decrease in project team morale. For these reasons, the initial installation of application software purchased from a vendor should be performed by a representative from that vendor, whenever possible.
If the initial installation is performed by internal staff, there is an immediate loss of accountability concerning the functioning of the software. If the vendor performs the installation, the vendor is responsible for its initial performance. There should be no question about whether an installation error is responsible for software malfunctions.
In any case, once the software is successfully installed, it should be backed up immediately. This backup will provide a pristine copy of the software, for restoration in case of any loss of software for hardware failure on any other reason.
At the same time, an ongoing backup schedule should be arranged with the operations staff, or the individual responsible for other hardware backup duties at the facility.
A member of the internal technical support organization should observe and participate in the software installation. Afterward, subsequent installation of software upgrades, "PTF's", or additional applications may be performed by an internal technical resource.
Installation vs. Implementation
Installing the software on a computer or network is not the same as implementing the software. Software which is installed is resident on a computer, with or without actual data or users. Software which has been implemented is being used, in a production environment, with live data, trained users, and actual transactions or activity being processed.
Project Team Training should be conducted in accordance with the plan developed in the Develop Training Plan Activity. If the training is provided by an outside firm, such as a software vendor, it will include a course evaluation. Complete the evaluation carefully; it is probably the primary tool the vendor uses to improve its training material and training staff.
If the training is conducted internally, an evaluation or similar mechanism should be used to provide feedback for the instructors and course developers.
When a training course has more than three or four participants, it will usually be more economical to hold the training at the customer's site. In these cases, some precautions must be taken:
The training facility should be away from the normal working environment of the class participants. There should not be a telephone inside the training facility.
The training facility should include all equipment and materials as recommended by the training provider, including sufficient workstations, projectors, desk space, flip charts, markers, etc.
The daily schedule should include time before and after class to attend to daily business, answer phone calls, etc.
Participants should attend all sessions for a given course, rather than coming and going from hour-to-hour and day-to-day.
Each class should include a training binder which the attendees keep once the course is completed. The training guide will serve as a reference manual for team members during preparation for the Conference Room Pilot, and afterward.
During the training, team members should begin to log Issue Reports, documenting questions about how the software fits the business requirements to be addressed. These Issue Reports are added to those written during the Conference Room Pilot, for resolution during the CRP phase. A sample Issue Report is provided at the end of the Conference Room Pilot section of this guide.
If the class is conducted at a vendor facility and other customers are represented in the class, the instructor might not allow lengthy discussion of customer-specific issues. On-site courses, on the other hand, may be altered to meet one customer's needs, particularly if the instructor can be briefed well in advance.
Developing, documenting, and distributing standards and procedures helps to ensure that the various team members or project sub-teams are performing and documenting their work in a consistent manner.
Project forms and documentation should be kept in a central Project Binder, which is accessable to all project team members.
Project Standards
Project documentation and forms are used to define and record project activities and deliverables. The forms and documents which are used should be understood and agreed upon by the project team. Among the forms and documents which need to be standardized are:
The Project Binder table of contents
A Project Status Report
A CRP (Conference Room Pilot) Exercise Document
A Project Issue Report (used in all phases)
A Modification Request form
Design documentation for system modifications
System test planning documents
The contents of the Project Binder will depend on each individual project. Samples of the other documents identified above are provided throughout this guide.
Project Administration Procedures
Administrative Procedures must be documented and distributed to all team members as soon as they are agreed upon. Procedures may be very specific of very broad, but in general should provide answers to the following questions:
What regular meetings will be held? Who will attend?
How is status reported, by whom, and at what intervals?
How are issues resolved? (ex: issues may be escalated to the team leaders, the project manager, and finally the steering committee, if necessary)
Who authorizes, performs, and tests system modifications?
How and where is time recorded?
How is third-party billing approved and processed?
Who will approve changes to the project scope?
The last activity in the Project Definition phase is the preparation of a detailed schedule for the Conference Room Pilot. The term "Conference Room Pilot" is used to represent the project phase, and the formal CRP event. The CRP event is the fourth activity in the Conference Room Pilot phase.
The CRP event should be scheduled before the Conference Room Pilot phase begins. Scheduling the CRP event establishes a deadline for all the activities leading up the actual CRP. These activities are:
Analyze and Document Requirements
Establish System Prototype
Define CRP and Exercises
Without a firm target for the beginning of the CRP event, these activities might drag on for a lengthy period of time.
Scheduling the CRP event well in advance also helps ensure that no team members are unavailable when the Conduct CRP activity begins.
The CRP schedule will eventually detail which software application and which functions will be tested on which day. At this stage, however, the start and stop dates for the CRP may be all that can be accurately determined.
If the project is divided into application groups (such as Financial, Distribution, and Manufacturing) the beginning and ending dates for each application group can be determined and published. Later, when the functions which will be tested in the CRP have been identified, more detail will be added.
The last week of the CRP in this example is called the Business Cycle CRP. The Business Cycle section of the CRP combines functions from the various application groups, and follows transactions and business events as they flow through the entire system.
For example, a Sales Order, entered through the Sales Order processing application, may result in a receivable item, which is closed out in the Accounts Receivable application. Then, the sales and cash transactions would result in Journal Entries being generated, which are posted and reported in the General Ledger application.
The roles of the various participants in the CRP are also described in the Conference Room Pilot section of this guide.
The following is an example of a CRP schedule at its inception, showing dates, application groups (or project sub-teams) and participants.
Sample Software Implementation
Conference Room Pilot Schedule
As of
|
START DATE
|
END DATE
|
LOCATION
|
APPLICATION TEAM
|
PARTICIPANTS
|
|
April 30 |
May 4 |
Main Conference Room |
Financials |
Steve, Cindy, Mary, Ted, Frank |
|
May 7 |
May 11 |
Main Conference Room |
Distribution |
Peggy, John, Mike, Ellen, Ed, Frank |
|
May 14 |
May 18 |
Main Conference Room |
Manufacturing |
Andy, Tom, Fran, Steve, Frank |
|
May 21 |
May 25 |
Main Conference Room |
Manufacturing (cont.) |
Andy, Tom, Fran, Steve, Frank |
|
June 4 |
June 8 |
Main Conference Room |
Business Cycle |
Steve, Cindy, John, Mike, Ed, Andy, Fran, Frank |
At the completion of all other activities in the Project Definition phase, the appropriate Project Manager's Checklists need to be reviewed or completed.
Project Manager's Checkpoints, end of Project Definition Phase:
Review & Complete Project Definition Checklist
Review & Complete Software Installation Checklist
Review Procedures and Training Checklist
Review Project Administration Checklist
Sample Project Team Organization Chart
Sample Status Report Format
|
Memorandum
|
|
TO: List of recipients
|
|
FROM: Author
|
|
DATE: Date Report is Distributed
|
|
RE: Status Report for xxxxxxxxxxxxxxxxxxxx (project/site/etc.)
|
|
Executive Summary:
|
|
A paragraph or two summarizing status and plans for the project in the time period being reported on.
|
|
Accomplishments to Date:
|
|
A summary of accomplishments and activities for the previous period, typically one half month, or one month.
|
|
Planned Activities:
|
|
A summary of planned activities for the next status reporting period.
|
|
Management Issues:
|
|
A list of decisions to be made which require management involvement.
|