EXTENDED CASE STUDY AND SAMPLE DOCUMENTATION

Case Study: EnviroClean

E
nviroClean is a 40-year-old manufac- specifications are passed to the product speci-
turer of chemicals used in the cleaning fication system. Modifications to a formula are
industry. Originally established as a handled in the same way.
small company with a primary staff of Problems integrating specification approval
chemists and engineers, the corporation has procedures have pointed out the need for an
grown to an international presence. It is clearly integrated system to store and approve all
recognized as the market leader in chemicals product specifications, including integrating
used for commercial cleaning, and in the last marketing and governmental restriction
five years has moved into producing products awareness with the specification process. The
for the home market. workflow required to move a product from
EnviroClean grew rapidly during the last Research and Development to Production
10 years through the acquisition of several varies from R&D site to R&D site, and from
smaller companies that produced products plant to plant. The only centralized function is
attractive to EnviroClean’s customers. Most the passing of the information to a centralized
enterprises were allowed to stay autonomous Product Specification system.
and function as they had in the past. How- The current product specification system is
ever, during an executive-sponsored evalua- accessible to only two members of the Enviro-
tion of internal processes and procedures Clean Information Systems staff. The current
conducted three years ago, it was discovered system holds duplicate information that con-
that several organizations were performing fuses the specification process because product
duplicate tasks. A good deal of economy objects are not appropriately archived or man-
could be gained by the consolidation of sev- aged. Object ownership is difficult to deter-
eral key processes. Additionally, chemists mine. Therefore, when changes are made to any
from several different organizations were part of the product specification, it is difficult
working on the development of very similar to determine who is responsible for the change.
products. The production of the products Objects are not linked in the system. Relation-
was different enough to require production ships between specification components and
plants to “re-tool” each time a slightly differ- manufacturing dependencies are difficult to
ent chemical formula was presented for pro- track. Frequently, product information is not
duction. This caused a great deal of down complete. Incomplete product specifications
time and loss of the advantage of quickly slow the development and manufacturing
delivering new products to market. process, thereby keeping products from being
Over the last six quarters, business has delivered to the marketplace in a timely manner.
dropped off. The loss of market share is par- Tom Johnston is the Vice President of
tially attributable to the lack of timely, accu- Information Systems for Research and Devel-
rate, and accessible information across all units opment. Tom has been given the assignment to
responsible for defining product components propose a solution to the current business
in the Research and Development organiza- challenge. Tom has asked Julia Cavanaugh to
tion. New governmental restrictions to protect investigate the information systems currently
the environment have severely affected the supporting the specification and manufactur-
speed with which new products can be ing process. Tom is concerned that the few Note: The persons,
approved and ready for distribution to the computer applications they have were devel- companies, and prod-
marketplace. oped in the decentralized, laissez-faire style ucts named in this
Most chemists in the Research and Devel- of the company. Maybe it is time to look at case study are ficti-
tious. Any similarity
opment staff are used to keeping their formu- information as a competitive weapon to see between those named
las and product specifications on their what might be done to increase its impact on herein and real per-
workstation computers. Once the product for- EnviroClean’s future. sons, companies, or
mulas have been formalised and tested, the products is entirely
coincidental.

Appendix B
Sample Documentation: Stakeholder Identification

Project: Installation Central Knowledge System: Research and Development

Management System Software Specification Management

Project Manager: Julia Cavanaugh Project Owner: Tom Johnston

Stakeholder Interest Role Requirement

Sponsor • Economic viability The individual or organi- • Earnings per share
• Cycle time zation that is initiating the • Revenue growth
• Cost of services work and providing the • Profit growth
resources. A member of • Market share
upper management.
Customer Value for the customer The individual or • Customer satisfaction
organization that will • Accurate/approved
receive the service or specifications delivered
use the new information quickly to production
system.
End users Information availability The people who will be Increased speed of deliv-
affected by the new ering specifications from
technologies. initiation to production
with proper approvals.
Performing Share and gain knowledge The individuals who Successfully implement
organization in data warehousing form the project organ- and understand relational
isational team. database structures that
are easily maintainable.
Project team • Adaptability The professionals or Successfully implement
• Employee satisfaction other specialists who and understand relational
• Accurate delivery of serve on the project team. database structures that
information are easily maintainable.
Project manager Meet project goals and The individual responsi- • Meet project goals and
objectives, system ble for managing the objectives
requirements project. • Meet all project mile-
stones on time and
budget

Sample Documentation: transfer function, in particular the role of one

person. The current system is not accessible
Project Concept by all departments responsible for the product
Description of Project Initiatives development cycle. The current process slows
For the business to thrive, it requires a work- the creation of product specifications, market-
flow be in place that everyone can understand ing materials and bills of materials used by the
and follow. Workflow is the path a business plants to manufacture the various Enviro-
object follows to reach completion. Currently, Clean products. Without this centralized func-
EnviroClean’s workflow depends on a central- tion, no product would be produced or
ized process focused around the technology changed.

IT Professional’s Guide to Project Management

Sample Documentation: Stakeholders

Project: Installation Central Knowledge System: Research and Development

Management System Software Specification Management

Project Manager: Julia Cavanaugh Project Owner: Tom Johnston

Stakeholder Group Name Role

Sponsor Vice President of Research and Provide financial and organizational support.
Development—Tom Johnston
Customer • Research and Development Each department’s workflow will be affected by the implementa-
group members tion of the new software product. Internal process may need to
• Engineers, Chemists, Plant be adjusted or changed based on the functionality of the software.
Managers, Marketing
End users • Research and Development Each department will have input into the new workflow process
group members and the creation of the list of objects and attributes necessary
• Engineers, Chemists, Plant for their work product.
Managers, Marketing
Performing EnviroClean’s Information Provide resources for project leadership and tasks.
organization Systems—New development
team
Other individuals/ • Consultants from Contractors will be used to design, develop, and deliver training
organizations Sawyer Systems, Inc. materials to be used as a part of the project roll-out.
• Training and documentation
consultants
Project team • Consultant from Sawyer • Software functionality may need to be modified based on the
Systems, Inc. requirements of each business unit
• 5 team members from IS new • Provide representation from Information Services, Engineer-
development group ing, Research Scientists, Plant Managers, Marketing
• Project leads for speciality • Report project progress to their respective constituents
areas: workflow definition, • Provide feedback to project team based on discussions with
database object definition, constituent groups
infrastructure team, software
support and installation team
• End-users from Research and
Development
• 2 Plant Managers
• Training and documentation
staff
Project manager Julia Cavanaugh Director of Information Services for Research and Development.

EnviroClean recognizes that the current definitions necessary for product develop-
system requires change based on the busi- ment and manufacturing. As the Enviro-
ness risk presented by an undocumented Clean’s business undergoes growth and
process and lack of access to the component change, the unwritten process understood

Appendix B
Sample Documentation: Balanced Scorecard

Project: Installation Central Knowledge System: Research and Development

Management System Software Specification Management

Project Manager: Julia Cavanaugh Project Owner: Tom Johnston

Perspective Objective Measures Targets

Financial Improve profits and • Revenue growth > 20%
shareholder equity. • Profit growth > 10%
Customer Increase market share • Market share > 40%
through new product • Retention > 90%
releases. • New product acceptance > 75%
Internal business Reduce time to market. • Internal approval < 3 days
Reduce duplicate infor- cycle time < 45 days
mation that might lead to • Government approval < 6 months
inconsistency in approval, cycle time
verification, and release • Development
processes. cycle time
Learning and growth Improve information • Cross-project references > 2 references per
sharing so new projects project
can take better advantage
of specification informa-
tion from other projects.
Reduce employee frus- • Targeted survey > 80% satisfied or highly
tration with project satisfied
administration.

only by long-term EnviroClean employees The CORE software supports a collabora-

does not provide the flexibility necessary to tive development environment using workflow
survive in the new business environment. and messaging technology. It is an object-ori-
The new environment requires a more flexi- ented system that allows users to:
ble process, where ownership of business
Create a central repository for all product
objects is moved to the business unit level. information
EnviroClean selected a repository software

Create objects representing products and
system called CORE from Sawyer Systems,
define the attributes of the products
Inc. to support EnviroClean’s product devel-
opment lifecycle. The introduction of the
Identify the relationships between objects
CORE computerised workflow process to the
Identify object owners
EnviroClean enterprise is an attempt to enrich The CORE system will be customised to
and streamline the current workflow. match the required EnviroClean workflow
CORE embraces the flexibility and accuracy processes. The CORE repository will include
required in the new business environment. A all specifications, marketing materials, and bills
more accessible workflow product promotes of materials required for the production and
ownership of the business objects at the shipping of EnviroClean’s chemical products.
appropriate business unit level. The CORE repository will not include product

IT Professional’s Guide to Project Management

specifications that have been archived for over
Speed to market is increased by 10% after
three (3) years. 80% of the end-users have implemented
Several challenges must be considered: the system

The customer population is large and
At least 80% of the system end-users rate
diverse. Differing perspectives and require- the new system as an improvement over
ments for objects and attributes in the data- their existing system based on an evaluation
base could slow project progress. after the first six (6) months of operation

Differing functional requirements for each
All current data from the existing specifica-
business unit could require that object defi- tion system will be successfully converted
nitions be too ambiguous to be functional. and available through the new CORE

Multiple complex business processes are repository
dependent on the smooth flow of informa-
All objects and their attributes necessary for
tion from one business unit to another. If production will be clearly identified in the
the system installation and implementation repository
does not proceed as planned, work could be
disrupted.
1. What business needs does the develop-
ment of the system satisfy?

The estimated length of the project is two The loss of market share over the last six
(2) years. quarters is partially attributable to the lack

Some critical project tasks are outside the of timely, accurate, and accessible informa-
realm of the project team’s control. Soft- tion across all units responsible for defining
ware upgrades and fixes from the vendor product components in the Research and
are scheduled to be delivered in the next Development organization.
six (6) months. If the upgrades are not 2. What is the strategic direction of the
delivered as promised, installation and organization?
implementation of the system will be
For the business to thrive, it requires a
delayed.
workflow be in place that everyone can

Essential IS staff may not be available for understand and follow. Workflow is the
the full length of the project. path a business object follows to reach

The software technology (object oriented) is completion. Currently, EnviroClean’s work-
unfamiliar to the majority of the IS staff. flow depends on a centralized process
This project directly affects the profitability focused around the technology transfer
of EnviroClean and has been designated by function, in particular the role of one per-
the Vice President of Research and Develop- son. The current system is not accessible by
ment as the highest priority project for Infor- all departments responsible for the product
mation Services for the coming fiscal year. development cycle. The current process
The CORE system project is expected to be slows the creation of product specifications,
completed within two years (24 months) of marketing materials, and bills of materials
the acquisition of the CORE system software. used by the plants to manufacture the vari-
The funding for this project is $7 million ous EnviroClean products. Without this
($7,000,000) total. Funding will cover the two centralized function, no product would be
years of the project execution and software produced or changed.
implementation. Funding includes the pur- 3. What are the existing organizational
chase of the CORE software at a cost of $75 needs or the potential deficiencies of
thousand ($75,000). the existing system?
The project will be evaluated for its success EnviroClean recognizes that the current
based on the following criteria: system requires change based on the busi-
ness risk presented by an undocumented

Appendix B
 process and lack of access to the compo- stored in the current database. They are
nent definitions necessary for product required to ensure a product specification
development and manufacturing. As the flows smoothly through the system with the
EnviroClean’s business undergoes growth proper approvals.
and change, the unwritten process under- 5. What enterprise resources will be
stood only by long-term EnviroClean required to support the system
employees does not provide the flexibility development?
necessary to survive in the new business
environment. The new environment The enterprise resources required to sup-
requires a more flexible process where port the project are listed in the Stakehold-
ownership of business objects is moved ers table that appears on page 3.
to the business unit level. 6. What technical, environmental, and
4. Are there alternative ways of accom- economic considerations must be taken
plishing the same goal? into account for the project to be con-
sidered successful?
Several alternatives have been considered to
meet this business need. • Speed to market is increased by 10%
after 80% of the end-users have imple-
• Continue using the existing system with mented the system
no change in processes and procedures.
• At least 80% of the system end-users
—This alternative will not improve performance rate the new system as an improvement
in speed to market and increasing the coordi- over their existing system based on an
nation of the multiple departments that must evaluation after the first six (6) months
have access to the data and approve each of operation
product element before it is ready to be sent to
the plants for production. • All current data from the existing specifi-
cation system will be successfully con-
• Encourage individuals to maintain their verted and available through the new
own specification information and be CORE repository
accountable to pass the information to
marketing and production before it is • All objects and their attributes necessary
required for product production. for production will be clearly identified
in the repository
—Individual responsibility to keep and
coordinate data does not allow the corporate Sample Documentation:
sharing of information. Standardisation is
required of information formats to be able to
Scope Document/Project Goals
share the data widely throughout the organi- Problem/Opportunity
zation. If individuals are responsible for The loss of market share over the last six quar-
maintaining their own databases, they will ters is partially attributable to the lack of
not be easily accessible to the wider enterprise. timely, accurate and accessible information
Standardisation will be difficult to enforce. across all units responsible for defining prod-
• Use an existing database format (flat file uct components in the Research and Develop-
format) to store information and aug- ment organization.
ment e-mail system to pass information For the business to thrive, it requires a
to marketing and production. workflow be in place that everyone can
understand and follow. Workflow is the path a
—The existing database format does not allow business object follows to reach completion.
for entities to carry attributes and does not Currently, EnviroClean’s workflow depends on
allow for relationship diagramming. Each a centralized process focused around the tech-
entity in the database needs to be related to nology transfer function, in particular the role
another. Process flow diagrams cannot be of one person. The current system is not

IT Professional’s Guide to Project Management

accessible by all departments responsible for the change. Objects are not linked in the sys-
the product development cycle. The current tem. Relationships between specification com-
process slows the creation of product specifi- ponents and manufacturing dependencies are
cations, marketing materials, and bills of mate- difficult to track. Frequently, product informa-
rials used by the plants to manufacture the tion is not complete. Incomplete product
various EnviroClean products. Without this specifications slow the development and man-
centralized function, no product would be pro- ufacturing process, thereby hindering products
duced or changed. being delivered to the marketplace in a timely
manner.
Business Requirement
EnviroClean recognizes that the current sys- Ownership
tem requires change based on the business risk The Vice President of Research and Develop-
presented by an undocumented process and ment owns the project.
lack of access to the component definitions
necessary for product development and manu-
Deliverables
The CORE software supports a collaborative
facturing. As EnviroClean’s business under-
development environment using workflow and
goes growth and change, the unwritten process
messaging technology. It is an object-oriented
understood only by long-term EnviroClean
system that allows users to:
employees does not provide the flexibility nec-
essary to survive in the new business environ-
Create a central repository for all product
ment. The new environment requires a more information
flexible process where ownership of business
Create objects representing products and
objects is moved to the business unit level. define the attributes of the products
Project Charter
Identify the relationships between objects
EnviroClean selected a repository software
Identify object owners
system called CORE from Sawyer Systems, The CORE system will be customised to
Inc. to support EnviroClean’s product devel- match the required EnviroClean workflow
opment lifecycle. The introduction of the processes.
CORE computerised workflow process to the
EnviroClean enterprise is an attempt to enrich Size
and streamline the current workflow. The CORE repository will include all specifica-
CORE embraces the flexibility and accuracy tions, marketing materials, and bill of materials
required in the new business environment. A required for the production and shipping of
more accessible workflow product promotes EnviroClean’s chemical products.
ownership of the business objects at the The CORE repository will not include
appropriate business unit level. product specifications that have been archived
for over three (3) years.
Boundaries
Quality
Needs Assessment
The current product specification system is Success Criteria
accessible to only two members of the Enviro- 1. Speed to market is increased by 10% after
Clean Information Systems staff. The current 80% of the end-users have implemented
system holds duplicate information that con- the system.
fuses the specification process because prod- 2. At least 80% of the system end-users rate
uct objects are not appropriately archived or the new system as an improvement over
managed. Object ownership is difficult to their existing system based on an evaluation
determine. Therefore, when changes are made after the first six (6) months of operation.
to any part of the product specification, it is 3. All current data from the existing specifica-
difficult to determine who is responsible for tion system will be successfully converted

Appendix B
 and available through the new CORE Risks and Assumptions
repository.
4. All objects and their attributes necessary for
Business Risks/Assumptions
production will be clearly identified in the 1. The customer population is large and
repository. diverse. Differing perspectives and require-
ments for objects and attributes in the data-
Priority base could slow project progress.
This project directly impacts the profitability of 2. Differing functional requirements for each
EnviroClean and has been designated by the business unit could require that object defi-
Vice President of Research and Development nitions be too ambiguous to be functional.
as the highest priority project for Information
Services for the coming fiscal year. 3. Multiple complex business processes are
The CORE system project is expected to be dependent on the smooth flow of informa-
completed within two years (24 months) of tion from one business unit to another. If
the acquisition of the CORE system software. the system installation and implementation
does not proceed as planned, work could be
End Date disrupted.
The project must be completed by the end of 4. The estimated length of the project is two
fourth (4th) Quarter 1998. (2) years.
Overall Budget IT Risks/Assumptions
The funding for this project is $7 million
1. Some critical project tasks are outside the
($7,000,000) total. Funding will cover the two
realm of the project team’s control. Soft-
years of the project execution and software
ware upgrades and fixes from the vendor
implementation.
are scheduled to be delivered in the next six
Funding includes the purchase of the
(6) months. If the upgrades are not delivered
CORE software at a cost of $75,000.

Sample Documentation: Project Estimating Components

Project: Installation Central Knowledge System: Research and Development

Management System Software Specification Management

Project Manager: Julia Cavanaugh Project Owner: Tom Johnston

Project Category Level of Effort Hours Cost

System development labor 16 1,160 $595,000
Hardware 12 240 $140,000
Software 10 440 $610,000
Project execution 10 3,640 $1,895,000
Project client 25 2,080 $2,275,000
Implementation 30 670 $866,250
System operation 5 50 $206,250
Estimated total project 108 8,280 $6,587,500

IT Professional’s Guide to Project Management

 as promised, installation and implementa- Work Breakdown Structure
tion of the system will be delayed.
(WBS)—By Systems
2. Essential IS staff may not be available for
the full length of the project. System Development
3. The software technology (object oriented) is 1.1. Define system requirements
unfamiliar to the majority of the IS staff. 1.1.1. Interview stakeholders
1.1.1.1. Engineering
Milestones
1.1.1.2. Chemists
1. System requirements definition:
1.1.1.3. Marketing
1.1. Define system requirements
1.1.1.4. Administrative staff
1.2. Design system
1.2. Design system
1.3. Design system infrastructure
1.2.1. Interface dependencies
2. Workflow analysis sign-off
1.2.2. Entity relationship
3. Hardware:
diagramming
3.1. Define scope, configuration, order
1.2.3. Database definitions
hardware
1.2.4. Attribute definitions
3.2. Obtain capital funds to purchase
hardware 1.3. Design system infrastructure
3.3. Hardware installation 1.3.1. Assess current operating
system limitations
3.4. Obtain hardware maintenance funding
1.3.2. Determine additional
4. Software:
components required
4.1. Define scope, configuration, order
1.4. Development of documentation,
software
training material
4.2. Obtain funding for software
1.4.1. Needs analysis
4.3. Purchase software
1.4.2. Job task analysis
4.4. Install software
1.4.3. Preliminary outline
5. Software coding complete
6. Quality assurance/test: Hardware
1.5. Define scope
6.1. Unit testing complete
1.6. Define configuration
6.2. Integration testing complete
1.7. Order hardware
6.3. System testing complete
1.8. Obtain capital costs to purchase
7. Implementation: hardware
7.1. Software installed on end-user
1.9. Schedule hardware installation
computers
1.10. Notify users of hardware change and
7.2. Development of documentation,
scheduling
training material
7.3. Training delivered to end-users Software
8. Maintenance transferred to on-going 1.11. Define scope and software perform-
maintenance group ance requirements
1.12. Define software configuration
including security levels

Appendix B
 1.13. Obtain sign-off on software facturing company. Each component in the
requirements creation of a product was previously stored in
1.14. Purchase operating systems software a separate database. The installation and
implementation of the CORE system
1.15. Purchase infrastructure software required that data be transferred from the
1.16. Purchase applications and develop- legacy systems to the new combined database
ment software structure. Each of the five major tasks in the
1.17. Purchase development software WBS was managed by a project lead for that
technical area. The tasks were mostly com-
Software Installation pleted in parallel. The project manager for this
1.18. Server installation project tracked the progress of each of the
1.19. Client installation five major tasks.
1. Switch to CORE for document
Project Execution management
1.20. Code software to match requirements 1.1. Install CORE on Workstations
1.21. Develop training materials 1.2. Build
1.2.1. Create Title

Quality Assurance and Testing 1.2.2. Dummy Title

1.22. Unit test and debugging 1.2.3. Update Total Pages
1.23. Data file format and layout testing 1.2.4. Create Custom Document
Originator
1.24. User documentation and training
testing 1.2.5. Document Master
1.25. Report layout testing 1.2.6. Legal Archive
1.26. On-line inquiry requests and response 1.2.7. Title Block Update
testing 1.2.8. Object Model Server Client
1.27. Security access and authorization 1.2.9. Perform Adapter
testing 1.3. Test
1.28. Communication protocol testing 1.3.1. Create Title
1.29. Hardware compatibility testing 1.3.2. Dummy Title
1.30. Rework and re-testing 1.3.3. Update Total Pages
1.31. User acceptance testing 1.3.4. Create Custom Document
Implementation Originator
1.32. Software accessible to end-users 1.3.5. Document Master
1.33. End-user training completed 1.3.6. Legal Archive
1.34. Software support turned over to 1.3.7. Title Block Update
maintenance and support group 1.3.8. Object Model Server Client

Work Breakdown Structure 1.3.9. Perform Adapter

(WBS)—By Stages 1.4. Fix Client
The Work Breakdown Structure (WBS) is for 1.4.1. Create Title
the installation of a combined drawing and 1.4.2. Dummy Title
specification management system for a manu-

IT Professional’s Guide to Project Management

 1.4.3. Update Total Pages 2.5.1. Auto Integrated Database
1.4.4. Create Custom Document Management (IDM) system
Originator tested and installed
1.4.5. Document Master 2.5.2. Database Definition File
(DDF) Setup complete
1.4.6. Legal Archive
2.5.2.1. Product purchase of
1.4.7. Title Block Update conversion program
1.4.8. Object Model Server Client 2.5.2.2. Query test of sample
1.4.9. Perform Adapter data converted
1.5. Build 2.5.3. AS/400
1.5.1. Document Master-OLE 2.5.3.1. Query Tests
server client 2.5.3.2. Permission issues
1.5.2. Legal Archive resolved
1.5.3. Title Block Update 2.5.3.3. Learning from
1.5.4. Build/Test/Fix Generic prototype activity
Batch Loader implemented
1.6. Test 2.5.3.4. Ambiguity conflicts
resolved in database
1.6.1. Document Master-OLE
definitions
server client
2.5.4. AutoCAD Drawings
1.6.2. Legal Archive
2.5.4.1. DWG Unplugged
1.6.3. Title Block Update
Investigation
1.6.4. Build/Test/Fix Generic
2.5.4.1.1. Estimate
Batch Loader
impact on delivery
1.7. Fix Queued Services schedule
1.7.1. Document Master-OLE 2.5.4.1.2. Estimate
server client level of effort to com-
1.7.2. Legal Archive plete conversion
1.7.3. Title Block Update 2.5.4.2. Consider sponsor
proposal
1.7.4. Build/Test/Fix Generic
Batch Loader 2.5.4.3. Development of
database definitions
2. Generic Batch Loader
2.5.4.4. Process training/
2.1. Design Generic Batch Loader
documentation
2.2. Code Generic Batch Loader
2.5.4.4.1. Engineers
Prototype
2.5.4.4.2. Designers
2.3. Review Design of the Generic Batch
Loader through prototype 2.5.4.4.3. Documenta-
tion specialists
2.4. Modify Generic Batch Loader based
comments from prototype review 2.6. Test, Revise GBL, and Review
Specifications
2.5. Import Processing Design—
Shared Steps 2.6.1. DDC Drawings

Appendix B
 2.6.2. Customer and Supplier— 4. Application Server Issues
Hard copy specifications 4.1. Investigate Queuing Techniques
2.6.3. CADNet drawings translated 4.2. List Problems to be Corrected in Pool
2.6.4. Pro/E – Hard copy Manager
2.6.5. CNC - Jig - Binary Files 4.3. Conduct Design Review
2.6.6. CNC - BMC - Binary Files 4.4. Program Queued Pool Manager
2.6.7. CNC - WEDM - Binary Files 4.5. Program Client Code to point to
2.6.8. Design Engineering - Current Queued Pool Manager
2.6.9. Design Engineering - History 4.6. Test Program Units
3. Title Block Update 4.7. Review Object Dictionary and add use
to Other Performs
3.1. Review Program Specification
4.8. Test Program Units
3.2. Design Server Program Unit
5. Plotter Integration
3.3. Design Client Program Unit Interface
5.1. Select a plotter and a software driver
3.4. Design Queued Pool Manager
Interface 5.2. Investigate plotter integration require-
ments
3.5. Design Program Unit Test Plan
5.3. Write integration specification
3.6. Code and Test Server Program Unit
5.4. Conduct Design Review
3.7. Code and Test Client Unit
5.5. Develop integration
3.8. Code and Test Queued Pool Manager
Interface 5.6. Write unit test for plotter integration
3.9. Write Designer/Developer 5.7. Execute plotter integration unit test
Documentation 5.8. Modify integration
2.9.1. Installation Documentation 5.9. Re-execute unit test
2.9.2. Administrative Documentation

IT Professional’s Guide to Project Management

Sample Documentation: Risk Management

Project: Installation Central Knowledge System: Research and Development

Management System Software Specification Management

Project Manager: Julia Cavanaugh Project Owner: Tom Johnston

Risk Probability Severity Mitigation Approach

Project team experience High Project delay, cost overrun. Implement training program for all
project team members regarding
roles, responsibilities. Train to tech-
nical competencies as required.
Appropriate team members High Learning curve time could Identify additional potential team
not available to complete slow project deliverables. members. Keep potential team
project Team “burnout” reduces members appraised of project
team efficiency. progress.
Customer availability Low Requirements not fully Contract with functional managers
defined. Feedback on system so they fully understand the business
performance not readily requirements and project priority
available to project team. status in the organisation.
Equipment—access to hard- Low Inability of project team to Estimate complete project equip-
ware restricted, required complete assigned tasks. ment requirements based on previ-
hardware not available, work- ous experiences with similar efforts.
stations not available for all Plan for additional equipment
members of project team acquisition during project phases.
Budget—project budget Medium Project delay, reduced scope. Seek other less expensive solutions
reduced due to changing to business challenge.
company priorities
Statistics used in preparing Low Cost overrun. Contact other entities that have
budget estimates are implemented similar systems to
unreliable verify project budget and time
estimates.
Scope changes—Require- Medium Project deliverable delay, cost Scope document and requirements
ments not surfaced in the overrun. definition are reviewed and formally
design phase add time and approved by all project stakeholders.
cost to original project scope Change control process is strictly
followed. Project scope revisited
during project execution.

Appendix B
Sample Documentation: Project Estimating Components Worksheet
Project: Installation Central Knowledge System: Research and Development
Management System Software Specification Management

Project Manager: Julia Cavanaugh Project Owner: Tom Johnston

Cost Category Level of Effort Hours Cost

System development labor cost
Define system requirements 5 160 $100,000
Design system 5 480 $300,000
Design system infrastructure 3 40 $15,000
Coding, unit testing, integration, system test 3 480 $180,000
Development of documentation, training material 2 160 $32,000
Hardware costs
Define scope, configuration, order hardware 2 160 $40,000
Capital costs to purchase hardware $50,000
Hardware installation costs 5 40 $25,000
Hardware maintenance costs 5 40 $25,000
Software costs
Define scope, configuration, order software 5 40 $25,000
Purchase costs for operating systems software $100,000
Purchase costs for infrastructure software $85,000
Purchase costs for applications software $75,000
Purchase costs for development software $75,000
Software installation costs 5 400 $250,000
Project execution costs
Travel and living 5 2080 $1,300,000
External consulting 3 1040 $390,000
Training 2 520 $130,000
Supplies and materials $25,000
Incentive costs $50,000
Project client costs
Operating cost for staff attendance at training programs 5 520 $325,000
Operating cost for user participation on project team 10 520 $650,000
Operating cost for client involvement 10 1040 $1,300,000
Implementation costs
Operating cost for additional staff effort during implementation 15 520 $585,000
Travel and living during implementation 15 150 $281,250
System operation costs
Staff labor during payback period 5 50 $31,250
Materials and supplies during payback period $50,000
Hardware and software maintenance contracts $75,000
Hardware leasing $0
Project costs for hardware and software upgrades $50,000

IT Professional’s Guide to Project Management

Sample Documentation: 3. Resource requirements for each activity are
defined based on what we know today.
Estimating Issues Additional resources that will be required
Project Scope are not yet identified. We will not know how
1. The only data available for similar project many additional resources we need until
time and cost standards does not apply to after the database definitions are completed.
this project. The data was collected over 10 4. Activity estimates will be influenced by how
years ago when the old system was built. quickly the vendor can respond to our
The information does not take into account requests for customisation and new ver-
constructing a relational database. sions of the software.
2. Experience in similar business critical proj- 5. Contingency plans for acquiring the appro-
ects would empathise the need for strict priate technical and personnel resources
adherence to the change control process. have been developed.
3. Resource requirements for each activity are 6. Uncertainty in this project is high. We have
defined based on what we know today. not implemented a similar system previously
Additional resources that will be required and the technical abilities required for pro-
are not yet identified. We will not know how gramming staff can not be totally assessed.
many additional resources we need until
7. The new version of the software should
after the database definitions are completed.
provide functionality we have requested.
4. Estimates will be influenced by personnel The uncertain release date of the new ver-
resource availability. Difficult to predict at sion means we may have to do some pro-
this time. gramming and customisation in-house that
5. Contingency plans have been developed to is included minimally in the budget and
account for schedule slippage. time estimates.
6. Uncertainty in this project is high. We have Resource Skill Levels
not implemented a similar system previously 1. Supportive data is not available for resource
and the vendor does not have extensive data skill level estimates other than from the
to confirm our time and cost estimates. vendor.
7. The new version of the software should 2. Information on experiences with similar
provide functionality we have requested. implementations comes from external
The uncertain release date of the new ver- consultants.
sion means we may have to do some pro-
gramming and customisation in-house that 3. Resource requirements regarding technical
is included minimally in the budget and skill will mean that we need to make
time estimates. allowances in the schedule for staff training on
the new software and programming languages.
Activity Requirements 4. Estimates will be influenced by training
1. Activity requirements for this project schedules and the amount of time it takes a
should be similar to that necessary for the programmer and database administrator to
implementation of the product marketing be able to fully use the software.
database. The activities for this project will
5. Contingency planning includes hiring exter-
encompass more company resources and
nal consultants to perform some of the pro-
more coordination between departments.
gramming and database construction tasks.
Therefore the activity estimates are length-
This could increase the cost of the project.
ened by a factor of two.
6. Uncertainty in this project is high. We have
2. The extension of the activity estimates
not implemented a similar system. Few of
should allow enough time for each task to
our internal staff have worked with rela-
be completed within the scheduled time.
tional databases.

Appendix B
 7. Since our internal staff has not worked 5. Contingency plans have been developed to
with the new technology, we are uncertain account for additional resource expenses if
of the time requirements to have personnel required.
fully trained and productive in the new 6. Resource expenses have been estimated
environment. based on cost requirements for projects
Resource Availability with a similar budget.
1. Time and cost standards regarding resource 7. Technical resource expenses have been
availability suggests we will need to acquire clearly documented based on previous
at least a third of our resources for this experience and conversations with consult-
project externally. ing enterprises locally.
2. Experience with projects of similar size and Original Time and Cost Expectations
budget would suggest the cost estimate for 1. Original time and cost expectations were
acquiring external resources may be low. based on information from the vendor
3. Resource availability for the first two project regarding similar implementations.
phases is clearly defined. Additional phase 2. Experience in similar business critical projects
resource availability will depend on the out- would empathise the need for strict adher-
come of the first two phases ence to the change control process to be able
4. Will the estimates be influenced by factors to adhere to original time and cost estimates.
other than time and cost? 3. Original time and cost expectations may
5. Complete contingency plans for phases have been low. Resource requirements for
following the first two have not been each activity are defined based on what we
developed. know today. Additional resources that will
6. Uncertainty in this project is high. External be required are not yet identified.
resources may not be locally available. 4. Estimates will be influenced by personnel
Acquiring resources personnel from outside resource availability. Original estimates did
the local area means an increase in travel not take into account changes to versions of
and expense costs. the vendor software.
7. The uncertain release date of the new ver- 5. Contingency plans have been developed to
sion means we do not have a clear idea of account for variations from original time
when additional resources will be required. and cost expectations.
Therefore we cannot predict their availability. 6. Expectations are based on previous imple-
Resource Expense mentations of similar systems at other
enterprises. Expectations will have to be
1. Expense information has been estimated carefully managed internally. Additional
based on recommendations from the ven-
time and cost may be required to be certain
dor and external consultants who have
expectations are appropriately managed.
implemented similar systems.
7. Changes in purchase prices for the required
2. Experience would suggest the expenses technologies to implement the new system
identified are reasonable.
will impact original expectations.
3. Resource expenses categories for each
activity are clearly defined.
4. Estimates will be influenced by personnel
resource availability. Difficult to predict at
this time.

IT Professional’s Guide to Project Management

Sample Documentation: Project Scheduling Components Worksheet
Project: Installation Central Knowledge System: Research and Development
Management System Software Specification Management
Project Manager: Julia Cavanaugh Project Owner: Tom Johnston

Tasks Duration Start Finish

Central system development 957.45d Wed 1/8/97 Fri 9/8/00
1. System development 299.78d Wed 1/8/97 Tue 3/3/98
1.1. Define system requirements 30d Wed 1/8/97 Tue 2/18/97
1.2. Design system 20d Wed 2/19/97 Tue 3/18/97
1.3. Design system infrastructure 15d Wed 3/19/97 Tue 4/8/97
1.4. Development of documentation, training material 234.78d Wed 4/9/97 Tue 3/3/98
2. Hardware 85d Tue 3/3/98 Tue 6/30/98
2.1. Define scope 30d Tue 3/3/98 Tue 4/14/98
2.2. Define configuration 15d Tue 4/14/98 Tue 5/5/98
2.3. Order hardware 10d Tue 5/5/98 Tue 5/19/98
2.4. Obtain capital costs to purchase hardware 10d Tue 5/19/98 Tue 6/2/98
2.5. Schedule hardware installation 10d Tue 6/2/98 Tue 6/16/98
2.6. Notify users of hardware change and scheduling 10d Tue 6/16/98 Tue 6/30/98
3. Software 85d Tue 6/30/98 Tue 10/27/98
3.1. Define scope and software performance requirements 30d Tue 6/30/98 Tue 8/11/98
3.2. Define software configuration including security levels 10d Tue 8/11/98 Tue 8/25/98
3.3. Obtain sign-off on software requirements 5d Tue 8/25/98 Tue 9/1/98
3.4. Purchase operating systems software 10d Tue 9/1/98 Tue 9/15/98
3.5. Purchase infrastructure software 10d Tue 9/15/98 Tue 9/29/98
3.6. Purchase applications software 10d Tue 9/29/98 Tue 10/13/98
3.7. Purchase development software 10d Tue 10/13/98 Tue 10/27/98
4. Software installation 30d Tue 10/27/98 Tue 12/8/98
4.1. Server installation 15d Tue 10/27/98 Tue 11/17/98
4.2. Client installation 15d Tue 11/17/98 Tue 12/8/98
5. Project execution 180d Tue 12/8/98 Tue 8/17/99
5.1. Code software to match requirements 180d Tue 12/8/98 Tue 8/17/99
5.2. Develop training materials 45d Tue 12/8/98 Tue 2/9/99
6. Quality assurance and testing 209.67d Tue 8/17/99 Tue 6/6/00
6.1. Unit test and debugging 20d Tue 8/17/99 Tue 9/14/99
6.2. Data file format and layout testing 15d Tue 9/14/99 Tue 10/5/99
6.3. User documentation and training testing 4.67d Tue 10/5/99 Tue 10/12/99
6.4. Report layout testing 20d Tue 10/12/99 Tue 11/9/99
6.5. On-line inquiry requests and response testing 20d Tue 11/9/99 Tue 12/7/99
6.6. Security access and authorization testing 20d Tue 12/7/99 Tue 1/4/00
6.7. Communication protocol testing 20d Tue 1/4/00 Tue 2/1/00
6.8. Hardware compatibility testing 20d Tue 2/1/00 Tue 2/29/00
6.9. Rework and re-testing 45d Tue 2/29/00 Tue 5/2/00
6.10. User acceptance testing 20d Tue 5/2/00 Tue 6/6/00
7. Implementation 68d Tue 6/6/00 Fri 9/8/00
7.1. Software accessible to end-users 15d Tue 6/6/00 Tue 6/27/00
7.2. End-user training completed 33d Tue 6/27/00 Fri 8/18/00
7.3. Software support turned over to maintenance and support group 15d Fri 8/18/00 Fri 9/8/00

Appendix B
Sample Documentation: Communication Plan

Project: Installation Central Knowledge System: Research and Development

Management System Software Specification Management

Project Manager: Julia Cavanaugh Project Owner: Tom Johnston

Report Description Recipient Frequency

Preliminary project concept Executive summary or Tom Johnston Once at beginning of project.
project overview.
Scope definition Document describing • Tom Johnston, Once at beginning of project.
project scope, boundaries, Julia Cavanaugh
budget, requirements, etc. • All project team
members
Balanced scorecard Part of project scope • Tom Johnston, Julia • Beginning.
document, recognizes Cavanaugh • After project kick-off meeting.
that financial measures • Project team • End of project.
by themselves are not
sufficient measures of
enterprise performance.
Risk management report Describes project risks, Tom Johnston, Review weekly throughout life of
impact and mitigation Julia Cavanaugh project.
strategy.
Project effort estimate Describes level of effort Tom Johnston, Review weekly throughout life of
required to complete Julia Cavanaugh project.
project.
Project time estimate Describes time required Tom Johnston, Review weekly throughout life of
to complete project. Julia Cavanaugh project
Project cost estimate Describes time required Tom Johnston, Review weekly throughout life of
to complete project. Julia Cavanaugh project
Work Breakdown Describes which activi- • Julia Cavanaugh Review weekly throughout life of
Structure (WBS) ties need to be done in • Project team leads project
order to meet project
goals. It is a hierarchical
division of activities.
Project schedule/ Project plan Created from WBS. • Julia Cavanaugh Review weekly throughout life of
Schedules work activi- • Project team leads project.
ties and shows task
dependencies.
Project resource assignment Defines which individu- • Julia Cavanaugh Review weekly throughout life of
matrix als are responsible for • Project team leads project.
project components.

IT Professional’s Guide to Project Management

Sample Documentation: Communication Plan (cont.)

Report Description Recipient Frequency

Project status report Scheduled project • Julia Cavanaugh Weekly.
progress reports. • Project team leads
Project variance report Reports variances from • Julia Cavanaugh As required.
the project plan (time to • Project team leads
complete), budget (cost)
or requirements (scope).
Change request form Formal requests for a • Julia Cavanaugh As required.
variance from the proj- • Project team leads
ect plan (time to com-
plete), budget (cost), or
requirements (scope).
Project review document Evaluates the success or • Julia Cavanaugh Completed at the end of a project
failure of a project • Project team leads as part of project closure.
based on project original • Project team members
scope and change
requests.
Lessons learned document Documents lessons • Julia Cavanaugh Completed at the end of a project
learned as the project • Project team leads as part of project closure.
progressed. Used to • Project team members
collect historical data
to be used by other proj-
ect teams for similar
projects.

Appendix B
Sample Documentation: Project Responsibility Matrix

Project: Installation Central Knowledge System: Research and Development

Management System Software Specification Management

Project Manager: Julia Cavanaugh Project Owner: Tom Johnston

Web Elements Resource Initials/ Code

1. System requirements definition CH P
1.1. Define system requirements TK, A R S
1.2. Design system CH, JG, MP A P B
1.3. Design system infrastructure JK A P
2. Workflow analysis sign-off JB, UA P A
3. Hardware JK P
3.1. Define scope, configuration, order hardware MM, ST A B
3.2. Obtain capital funds to purchase hardware OR A
3.3. Hardware installation LK P A
3.4. Obtain hardware maintenance funding TS A P
4. Software KH P
4.1. Define scope, configuration, order software DK, AA A P B
4.2. Obtain funding for software DB P
4.3. Purchase software JR A R S
4.4. Install software AS A P B
5. Software coding complete JK A P
6. Quality assurance/test JA P A
6.1. Unit testing complete TD P
6.2. Integration testing complete JA A B
6.3. System testing complete SS A
7. Implementation JG P A
7.1. Software installed on end-user computers PK A P
7.2. Development of documentation, training material LN, FL P A B
7.3. Training delivered to end-users LN, FL A P B
8. Maintenance transferred to on-going maintenance group CH

Code: A—Assigned resource I—Input R—Reviewer

B—Backup person P—Person accountable S—Signature required

IT Professional’s Guide to Project Management

Sample Documentation: Project Status Report

Project: Installation Central Knowledge System: Research and Development

Management System Software Specification Management

Project Manager: Julia Cavanaugh Project Owner: Tom Johnston

Status (Red, Scheduled Projected

Activity Yellow, Green) Completion Completion
Define workflow process once specifications are Green 11/25/99 11/25/99
accessible to plant personnel
Coordinate with software development to ensure Red 11/15/99 12/20/99
plant workflow are accommodated by new software
Complete user acceptance testing of CORE Yellow 11/15/99 11/20/99
system prototype

Issues: 2. Access to the prototyped objects and soft-

1. Coordination with the software develop- ware has been restricted to specific hours to
ment group has been hampered by the cur- allow all access to the system. This con-
rent lag in delivery of the updated software straint has reduced the amount of time the
from the vendor. system is available to do extensive work
with the prototype.

Plans for next reporting period:

Appendix B
Sample Documentation: Variance Report

Project: Installation Central Knowledge System: Research and Development

Management System Software Specification Management

Project Manager: Julia Cavanaugh Project Owner: Tom Johnston

Task BWCS BWCP ACWP CV SV Remaining $

Central system development 1,074,813 450,348 451,191 (843) (624,465) 777,025
1. System development 294,378 217,345 217,345 (0) (77,033) 77,033
1.1. Design system 89,275 89,275 89,275 0 0 0
1.2. Design system infrastructure 38,275 28,775 28,775 0 (9,500) 9,500
1.3. Development of documen- 166,828 99,295 99,295 (0) (67,533) 67,533
tation, training material
2. Hardware 191,133 142,914 143,633 (719) (48,219) 47,500
2.1. Define scope 132,781 132,781 132,781 0 0 0
2.2. Define configuration 17,779 5,393 5,434 (41) (12,386) 12,345
2.3. Order hardware 24,479 3,146 3,824 (678) (21,333) 20,655
2.4. Obtain capital costs to 10,094 1,594 1,594 0 (8,500) 8,500
purchase hardware
2.5. Schedule hardware 3,000 0 0 0 (3,000) 3,000
installation
2.6. Notify users of hardware 3,000 0 0 0 (3,000) 3,000
change and scheduling
3. Software 149,869 1,788 1,788 0 (148,081) 148,081
3.1. Define scope and software 132,781 0 0 0 (132,781) 132,781
performance requirements
3.2. Define software configura- 17,088 1,788 1,788 0 (15,300) 15,300
tion including security levels
3.3. Obtain sign-off on 0 0 0 0 0 0
software requirements
3.4. Purchase operating 0 0 0 0 0 0
systems software
3.5. Purchase infrastructure 0 0 0 0 0 0
software
3.6. Purchase applications 0 0 0 0 0 0
software
3.7. Purchase development 0 0 0 0 0 0
software
4. Software installation 0 0 0 0 0 0
4.1. Server installation 0 0 0 0 0 0
4.2. Client installation 0 0 0 0 0 0
5. Project Execution 0 0 0 0 0 0
5.1. Code software to 0 0 0 0 0 0
match requirements
5.2. Develop training materials 0 0 0 0 0 0

IT Professional’s Guide to Project Management

Sample Documentation: Variance Report (cont.)
Task BWCS BWCP ACWP CV SV Remaining $
6. Quality assurance and testing 11,559 0 60 (60) (11,559) 12,004
6.1. Unit test and debugging 0 0 0 0 0 0
6.2. Data file format and 0 0 0 0 0 0
layout testing
6.3. User documentation 11,559 0 60 (60) (11,559) 12,004
and training testing
6.4. Report layout testing 0 0 0 0 0 0
6.5. On-line inquiry requests 0 0 0 0 0 0
and response testing
6.6. Security access and 0 0 0 0 0 0
authorization testing
6.7. Communication 0 0 0 0 0 0
protocol testing
6.8. Hardware compatibility 0 0 0 0 0 0
testing
6.9. Rework and re-testing 0 0 0 0 0 0
6.10. User acceptance testing 0 0 0 0 0 0
7. Implementation 0 0 0 0 0 0
7.1. Software accessible to
end-users 0 0 0 0 0 0
7.2. End-user training completed 0 0 0 0 0 0
7.3. Software support turned 0 0 0 0 0 0
over to maintenance and
support group

Appendix B
Sample Documentation: Change Request Form

Control Number: 6.9.874-62

Request Date: 9/16/97
Requestor: James Stone
Telephone: 507.987.3543
Fax: 507.987.3541
E-Mail: [email protected]
R
E Nature of Change: (Include information on the problem, cause(s) for the change, reason for the request—
attach additional documentation as necessary.)
Q
Rename chemical component object to dry chemical component object.
U
The current name causes some confusion among chemist who have been able to distinguish between dry and
E
wet chemicals in the specification process in their product specification process.
S
T
Impact Assessment: (Include estimates on impact, task duration, scheduling, project team members, work loads,
O facilities, equipment, quality, cost, and related tasks – attach additional documentation as necessary.)
R Changing the object name would mean an additional level of effort of 16 to 24 hours. Relationships and
dependencies already established for the object would have to be deleted and re-established with the new object.
The additional work could negatively impact the current workflow process defined in the system.

Suggested Solution(s) / Alternative(s):

Add additional attribute to current chemical component object to distinguish between dry and wet chemical
components.

P Recipient: Julia Cavanaugh

R
O Date Received: 9/17/97
J
E Disposition: (Include information on how decision was reached, adjust estimated impact of the change on the
C project – attach additional documentation as necessary.)
T
Add additional attribute to current chemical component object to distinguish between dry and wet chemical com-
M ponents. The addition of the attribute should allow chemist to make the appropriate distinctions for the object
A without having to disrupt the current workflow or negatively impact the project schedule.
N
A
G Approved By: James Stone, Julia Cavanaugh
E Date Approved: 9/20/97
R

IT Professional’s Guide to Project Management

Sample Documentation: Project Review Document

Project: Installation Central Knowledge System: Research and Development

Management System Software Specification Management

Project Manager: Julia Cavanaugh Project Owner: Tom Johnston

Project Area Questions

Project definition scope and 1. Was the role of the project manager clearly defined?
team building 1.1. The role of the project manager was not clearly defined at the beginning of the proj-
ect in the scope document. The role evolved and changed as the project progressed.
Documentation of the project manager’s role was created during the planning phase.
Stakeholders were required to sign-off on the project manager’s role definition.

2. Did the project team include the right members? Were additional members needed?
2.1. Initially the project team did not include all stakeholders. Administrative staff, who
are primarily responsible for the input of the data, were not included in the first
round of entity definitions by the database administrators. This caused a delay in the
acceptance of the entity and attribute definitions and caused a schedule slippage in
the end-user acceptance phase of the project.

3. What changes would you recommend to the organizational structure?

3.1. The organizational hierarchy of the project worked well. However, additional
resources were required during the end-user acceptance phase. Recommend a more
thorough evaluation of the project stakeholders during the project planning phase to
be certain all stakeholders are included.

4. Did customers and stakeholders participate? Should they?

4.1. Yes.
4.2. Customers and stakeholders were required to participate in the project definition
phase.

5. Did the team have adequate management support?

5.1. Yes.

6. Were the project/product objectives clearly defined?

6.1. Yes.

7. Were the product definition and requirements clear?

7.1. Database definitions were slightly ambiguous.

8. What caused product definition and requirement changes?

8.1. Certain assumptions were made about database entity and attribute definitions.
Definitions were understood at one level by the technical staff and differently by
end-users and stakeholders.

9. Was the necessary documentation available?

9.1. Current documentation from the vendor was not always available.

Appendix B
Sample Documentation: Project Review Document (cont.)

Project Area Questions

Planning 10. Was planning done adequately?
10.1. Preliminary planning underestimated the amount of time required by end-users to
approve and sign-off on database definitions and changing work process.

11. Was the plan tracked adequately?

11.1. The plan was tracked weekly for milestone and deliverable schedules.

12. Were changes to the plan adequately communicated?

12.1. Changes in the plan were communicated when the project was 10% over the
scheduled timeframes. Changes to the plan were communicated to members of the
project team weekly and to stakeholders as a part of the biweekly project status
meetings. Changes to the project plan could have been communicated earlier to
project stakeholders.

13. Did you have adequate input into planning?

13.1. Yes.

14. Suggestions for improving the planning process.

14.1. The planning process could have been improved if the additional stakeholders were
identified earlier in the planning process.

15. What caused deviation from the plan?

15.1. Assumptions that departmental processes and procedures were standard and identi-
cal in each department caused deviations from the project plan.
15.2. Vendor delays in delivering software updates delayed the project by up to one
month.

Cost 16. Were costs adequately anticipated?

16.1. Cost incurred for additional resources due to vendor delay in delivering software
updates were not adequately anticipated.

17. Were there costs that were not anticipated? Why?

17.1. Additional training time and resources were not anticipated. Assumptions about
standard processes and procedures were not varied and impacted training costs.

18. What caused cost growth?

18.1. Required additional resources.
18.2. Schedule slippage due to incorrect assumptions.

Resources 19. Were resources available when needed?

19.1. Additional database administration skills were required that were not readily available.

20. Were the tools used in the project adequate?

20.1. Yes.

IT Professional’s Guide to Project Management

Sample Documentation: Project Review Document (cont.)

Project Area Questions

Communications and 21. Were communications timely and adequate? What about other means to communicate?
meetings 21.1. A communication plan developed and documented during the planning phase
ensured that communications were timely and adequate to the project. Informal
communications during the project could have been improved by co-locating more
members of the project development team.

22. Were meetings useful, necessary?

22.1. Most meetings were useful. Not all status meetings (held weekly) were necessary.

23. Were meetings held too often, not often enough?

23.1. End-user meetings should have been held more often.

24. Were meetings run efficiently?

24.1. Not all meetings had a formal agenda. 60% of the team meetings were run effi-
ciently. The remaining 40% could have benefited from a meeting facilitator and a
formal agenda.

25. Were team members prepared for meetings?

25.1. Not all team members were prepared for all meetings. As the project activities
became more complex and the demands for developers time was increased, prepara-
tion for status and end-user meetings began to slip.

26. Were the results of meetings delivered to all team members in a timely fashion?
26.1. Most meetings assigned one person as responsible for communicating the results of
the meeting to project team members and stakeholders. The information was not
always communicated in a timely fashion.

27. Did the process of decision-making work? Improvement?

27.1. Decision-making was done by consensus. Most times it was very effective, as team
members felt they had an opportunity to voice their concerns. Consensus decision-
making can take longer than other methods. It may have been more appropriate at
times for the project manager or executive team to make the decisions independent
of the consensus process.

28. Were conflicts resolved adequately?

28.1. The priority status of the project and the commonly understood business objectives
helped to resolve conflicts quickly and adequately.

Reflection 29. What did you enjoy the most during the project?
29.1. Many parts of the enterprise seem to work in isolation. The project offered an
opportunity for many cross-functional teams to work together. Learning more about
the needs and concerns of other business units was beneficial.

30. What did you find frustrating during the project?

30.1. Decisions did not always seem to be made in the most expedient manner.
30.2. Assumptions about other functions and business unit processes and procedures
should have been uncovered earlier in the scope definition phase of the project and
not been left until the project was well into execution.

Appendix B
Sample Documentation: Project Review Document (cont.)
Project Area Questions
Reflection 31. What was successful?
31.1. The software was successfully installed and implemented on 85% of the end-user
systems.
31.2. Database definitions were clearly documented and agreed to by all stakeholders and
members of the business units affected by the process and software change.
31.3. Business processes were clearly defined and shared throughout the organization for
the first time in the history of the company.
31.4. Cross-functional teams gained an appreciation of various business unit requirements
not easily understood in the past.
32. What was not successful?
32.1. End-users are still running parallel systems for product specification in some units.
Full acceptance and usage of the new processes and procedures for specification
approval has not been implemented in all units.

33. What was not achieved?

33.1. Not all end users implemented the system.
33.2. Not all database definitions (entities and attributes) were defined and signed off.
Additional work is required in this area.

34. If asked to be on another project team, what one thing would you make sure was in place?
34.1. Stakeholders need to be clearly identified along with their particular concerns and
project perspective.

35. What could have been done differently (hindsight)?

35.1. Identify stakeholders earlier in the process.
35.2. Validate assumptions about business unit process and procedures.
35.3. Schedule more time for software implementation and end-user training.
35.4. Co-locate more members of the development and project team.

IT Professional’s Guide to Project Management

Sample Documentation: Lessons Learned Document

Project: Installation Central Knowledge System: Research and Development

Management System Software Specification Management

Project Manager: Julia Cavanaugh Project Owner: Tom Johnston

1. What did you enjoy the most during the 3.4. Cross-functional teams gained an
project? Why? appreciation of various business unit
1.1. Many parts of the enterprise seem to requirements not easily understood in
work in isolation. The project offered the past.
an opportunity for many cross-func- 4. What was not successful?
tional teams to work together. 4.1. End-users are still running parallel
1.2. Learning more about the needs and systems for product specification in
concerns of other business units was some units. Full acceptance and usage
beneficial in understanding the context of the new processes and procedures
of the project in contributing to the for specification approval have not
success of the business. I have a greater been implemented in all units.
sensitivity to the challenges encoun- 5. What was not achieved?
tered in the various departments.
5.1. Not all end-users implemented the
2. What did you find frustrating during system.
the project? Why?
5.2. Not all database definitions (entities
2.1. Decisions did not always seem to be and attributes) were defined and
made in the most expedient manner. signed off. Additional work is required
2.2. Assumptions about other functions in this area.
and business unit processes and pro- 6. If asked to be on another project team,
cedures should have been uncovered what one thing would you make sure
earlier in the scope definition phase of was in place?
the project and not been left until the
6.1. Stakeholders need to be clearly identi-
project was well into execution.
fied along with their particular con-
2.3. There were times the project seemed cerns and project perspective.
to be stalled by the seeming inability
to make a decision quickly.
7. What could have been done differently
(hindsight)?
3. What was successful?
7.1. Decision-making was done by consen-
3.1. The software was successfully sus. Most times it was very effective as
installed and implemented on 85% of team members felt they had an oppor-
the end-user systems. tunity to voice their concerns. Con-
3.2. Database definitions were clearly sensus decision-making can take
documented and agreed to by all longer than other methods for coming
stakeholders and members of the to a decision. It may have been more
business units effected by the process appropriate at times for the project
and software change. manager and executive team to make
3.3. Business processes were clearly the decisions independent of the con-
defined and shared throughout the sensus process.
organization for the first time in the 7.2. Identify stakeholders earlier in the
history of the company. process.

Appendix B
 Sample Documentation: Lessons Learned Document (cont.)
7.3. Validate assumptions about business 7.9. Not all meetings had a formal agenda.
unit process and procedures. 60% of the team meetings were run
7.4. Schedule more time for software efficiently. The remaining 40% could
implementation and end-user training. have benefited from a meeting facilita-
tor and a formal agenda.
7.5. Co-locate more members of the
development and project team. 7.10. Certain assumptions were made about
database entity and attribute defini-
7.6. The role of the project manager was tions. Definitions were understood at
not clearly defined at the beginning of one level by the technical staff and
the project in the scope document. differently by end-users and stake-
The role evolved and changed as the holders.
project progressed. Documentation of
the project manager’s role was created 7.11. Preliminary planning underestimated
during the planning phase. Stakehold- the amount of time required by end-
ers were required to sign-off on the users to approve and sign-off on data-
project manager’s role definition. base definitions and changing work
process.
7.7. Initially the project team did not
include all stakeholders. Administra- 7.12. Changes in the plan were communi-
tive staff, who are primarily responsi- cated when the project was 10% over
ble for the input of the data, were not the scheduled timeframes. Changes to
included in the first round of entity the plan were communicated to mem-
definitions by the database administra- bers of the project team weekly and
tors. This caused a delay in the accept- to stakeholders as a part of the
ance of the entity and attribute biweekly project status meetings.
definitions and caused a schedule slip- Changes to the project plan could
page in the end-user acceptance phase have been communicated earlier to
of the project. project stakeholders.
7.8. The organizational hierarchy of the 7.13. The planning process could have been
project worked well. However, addi- improved if the additional stakehold-
tional resources were required during ers were identified earlier in the plan-
the end-user acceptance phase. Rec- ning process.
ommend a more thorough evaluation
of the project stakeholders during the
project planning phase to be certain
all stakeholders are included.

IT Professional’s Guide to Project Management

 DOCUMENTATION TOOLS

T
his section contains a group of sample templates and forms for your use. These
worksheets may be reproduced for their intended purposes within your organiza-
tion only.

Stakeholder Identification
Project: System:

Project Manager: Project Owner:

Stakeholder Interest Role Requirement

Appendix B
Balanced Scorecard
Project: System:

Project Manager: Project Owner:

Perspective Objective Measures Targets

Financial

Customer

Internal business

Learning and growth

IT Professional’s Guide to Project Management

Project Concept
Project: System:

Project Manager: Project Owner:

To create a project concept definition:

1. Describe the end product. Include:

An evaluation of the project proposed

A preliminary analysis of risk

Resulting impact on the time, cost, and system performance requirements

A discussion of the potential impact on company resources

An evaluation of alternative strategies

2. Answer the following questions:

What is the strategic direction of the organization?

What business needs does the development of the system satisfy?

What are the existing organizational needs or the potential deficiencies of the
existing system?

Are there alternative ways of accomplishing the same goal?

What enterprise resources will be required to support the system development?

What technical, environmental, and economic considerations must be taken into account
for the project to be considered successful?

Appendix B
Scope Document
Project: System:

Project Manager: Project Owner:

Project Activities Details

Project goals
Problem/Opportunity
Business Requirements
Project Charter

Boundaries
Needs Assessment
Ownership
Deliverables
Size
Stakeholders

Quality
Success Criteria
Functional
Technical

Priorities
End Date

Overall Budget
Effort and Cost Estimate

Risks and Assumptions

Business Risks / Assumptions
IT Risks / Assumptions

Milestones

IT Professional’s Guide to Project Management

Risk Management
Project: System:

Project Manager: Project Owner:

Risk Probability Severity Mitigation Approach

Resource
Staffing
Hardware
Software
Customer availability
Project team experience
Budget
Time

Delivery
Equipment available
Software available
Reviews happen on time

Appendix B
 Risk Management Issues
Scope and Requirements Definition
1. Are the project objectives clearly identified and defined?

2. Is the project scope complete and defined in detail?

3. Does the scope document include performance requirements?

4. Can the estimates for time and cost be validated with historical information?

5. Is the project completion criteria well understood and clearly defined in the scope document?

6. Does the project have a fixed completion date with no contingencies?

7. Have project funds been fully budgeted and allocated?

8. Can the project be justified in business terms?

9. Does the project have the support of senior management?

10. Is the project critical to the business of the enterprise?

IT Professional’s Guide to Project Management

System Complexity
1. Is there a standardized development methodology?

2. What is the expected operational life of the new system?

3. Is there current documentation for the existing system?

4. Is there an available system prototype or model that can be used for training and usability
testing?

5. What is the availability of required additional hardware resources?

6. Does the system have logical (user driven) complexity as measured by:

Logical input types

Logical output types

Logical user views of data

Automated transfer of input/output files to another system

Logical query types

1. Is data element editing a complex process?

2. How much data will be transferred into the new system from legacy systems?
3. What is the quality of the data to be transferred from legacy systems?
4. What is the required number of interfaces to existing systems for the new
software/system being developed?

5. Have the quality requirements been fully documented and understood?

6. Is there a quality assurance function that will monitor the system development
and outcome?

Appendix B
 User Environment Issues
1. Is the user committed to the change control process?
2. Is senior user management committed to the system changes?
3. What priority does this project have within the user area?
4. Will the system be critical to users continuing operations when the project is completed?
5. What is the number of outside organizations involved in approvals and other decisions
regarding the system?
6. How many different user areas are involved in confirmations, approvals, and other system
decisions? How many different user areas and sub-areas?
7. How many user sites and installations are involved in the system implementation?
8. How severe are the procedural changes/disruptions caused by the proposed system
in user departments?
9. How will the user organization change structurally to accommodate
the new system changes?
10. How stable are the system requirements?
11. What is the status of the current system documentation?
12. What percent of present functions will be replaced one-to-one?
13. Are the project deadlines:

Flexible—established in conjunction with the project team

Firm—established internally, but missed dates may impact user functions/operations

Fixed—established by specific operations, legal requirements, direction beyond
organization control
1. At what level will users participate in the design and development process?
— Fully committed—expert users are allocated to undertake a significant amount of
project work
— Significant responsibilities—less than full-time commitment
— Some responsibilities—limited to review and approvals
14. Is the user representative knowledgeable in the proposed application area?
15. Is the user representative knowledgeable in information systems development?
16. Rate the communications between the user area and information systems on a scale of
1 to 5, with 1 being low and 5 being high.
17. Are new user-controlled technologies required for the successful use of the new system?
18. Is the project dependent on government legislation or regulations, vendors or outside con-
sultants to meet its deadlines?

IT Professional’s Guide to Project Management

Team Environment Issues
1. Will a standard project management methodology be followed throughout the life
of the project?
2. Is the project priority in the Information Systems function high or low?
3. Is senior IS management committed to the success of the project?
4. What is the project team size, including full-time user professionals?
5. What are the total development person hours for the project?
6. What is the estimated project development time?
7. What is the project manager’s availability for the project, experience, and training in
project management?
8. Can key project skills and staffing level requirements be met within the scope, cost, and
timeframes for the project?
9. What is the number of project team members who have worked successfully together on
previous projects?
10. Are members of the IS project team knowledgeable in:

The proposed application area

The programming languages to be used

The database system used

The data communications system used

The software packages used

The hardware used
11. Is a new operations system installation required for the project?
12. Does the project require coordination with outside vendors and contractors?
13. Have additional resource costs been included in the project budget
(travel, per diem, lodging)?

Appendix B
Project Estimating Components Worksheet
Project: System:

Project Manager: Project Owner:

Cost Category Effort (FTE) Duration Cost

1. System development labor cost
1.1. Define system requirements
1.2. Design system
1.3. Design system infrastructure
1.4. Coding, unit testing, integration, system test
1.5. Development of documentation, training material
2. Hardware costs
2.1. Define scope, configuration, order hardware
2.2. Capital costs to purchase hardware
2.3. Hardware installation costs
2.4. Hardware maintenance costs
3. Software costs
3.1. Define scope, configuration, order software
3.2. Purchase costs for operating systems software
3.3. Purchase costs for infrastructure software
3.4. Purchase costs for applications software
3.5. Purchase costs for development software
3.6. Software installation costs
4. Project execution costs
4.1. Travel and living
4.2. External consulting
4.3. Training
4.4. Supplies and materials
4.5. Incentive costs
5. Project client costs
5.1. Operating cost for staff attendance at training programs
5.2. Operating cost for user participation on project team
5.3. Operating cost for client involvement
6. Implementation costs
6.1. Operating cost for additional staff effort during implementation
6.2. Travel and living during implementation
7. System operation costs
7.1. Staff labor during payback period
7.2. Materials and supplies during payback period
7.3. Hardware and software maintenance contracts
7.4. Hardware leasing
7.5. Project costs for hardware and software upgrades

IT Professional’s Guide to Project Management

Project Scheduling Components Worksheet
Project: System:

Project Manager: Project Owner:

Cost Category Level of Effort Hours to Completion Date

(FTE) Complete Task
1. System development
1.1. Define system requirements
1.2. Design system
1.3. Design system infrastructure
1.4. Coding, unit testing, integration, system test
1.5. Development of documentation, training material
2. Hardware
2.1. Define scope
2.2. Define configuration
2.3. Order hardware
2.4. Obtain capital costs to purchase hardware
2.5. Schedule hardware installation
2.6. Notify users of hardware change and scheduling
2.7. Support
3. Software
3.1. Define scope and software performance requirements
3.2. Define software configuration including security levels
3.3. Obtain sign-off on software requirements
3.4. Purchase operating systems software
3.5. Purchase infrastructure software
3.6. Purchase applications software
3.7. Purchase development software
4. Software installation
4.1. Server installation
4.2. Client installation
5. Project execution
5.1. Code software to match requirements
5.2. Develop training materials

Appendix B
Project Scheduling Components Worksheet (cont.)
Cost Category Level of Effort Hours to Completion Date
(FTE) Complete Task
6. Quality assurance and testing
6.1. Unit test and debugging
6.2. Data file format and layout testing
6.3. User documentation and training testing
6.4. Report layout testing
6.5. On-line inquiry requests and response testing
6.6. Security access and authorization testing
6.7. Communication protocol testing
6.8. Hardware compatibility testing
6.9. Rework and re-testing
6.10.User acceptance testing
7. Implementation
7.1. Software accessible to end-users
7.2. End-user training completed
7.3. Software support turned over to maintenance and support group

IT Professional’s Guide to Project Management

Communication Plan
Project: System:

Project Manager: Project Owner:

Report Description Recipient Frequency

Preliminary project
concept
Scope definition

Balanced scorecard

Risk management report

Project effort estimate

Project time estimate

Project cost estimate

Work Breakdown
Structure (WBS)
Project schedule –
project plan
Project resource
assignment matrix
Project status report

Project variance report

Change request form

Project review
document
Lessons learned
document

Appendix B
Project Responsibility Matrix
Project: System:

Project Manager: Project Owner:

WBS Elements Resource Code

Initials/

Code: A—Assigned resource I—Input R—Reviewer

B—Backup person P—Person accountable S—Signature required

IT Professional’s Guide to Project Management

Project Status Report
Project: System:

Project Manager: Project Owner:

Activity Status (Red, Scheduled Projected

Yellow, Green) Completion Completion

Issues:

Plans for next reporting period:

Appendix B
Change Request Form
Project: System:

Project Manager: Project Owner:

Control Number:
Request Date:
Requestor:
Telephone:
Fax:
E-Mail:

Nature of Change: (Include information on the problem, cause(s) for the change, reason for the request—
R
attach additional documentation as necessary.)
E
Q
U
E
S Impact Assessment: (Include estimates on impact, task duration, scheduling, project team members,
T work loads, facilities, equipment, quality, cost, and related tasks – attach additional documentation as necessary.)

O
R

Suggested Solution(s) / Alternative(s):

Recipient:
P Date Received:
R
O
J
Disposition: (Include information on how decision was reached, adjust estimated impact of the change on the
E project—attach additional documentation as necessary.)
C
T

M
A
N
A Approved By:
G
E Date Approved:
R

IT Professional’s Guide to Project Management

Project Review Document
Project: System:

Project Manager: Project Owner:

Project Area Questions

Project definition scope • Was the role of the project manager clearly defined?
and team building • Did the project team include the right members? Were additional members needed?
• What changes would you recommend to the organizational structure?
• Did customers and stakeholders participate? Should they?
• Did the team have adequate management support?
• Were the project/product objectives clearly defined?
• Were the product definition and requirements clear?
• What caused product definition and requirement changes?
• Was the necessary documentation available?
Planning • Was planning done adequately?
• Was the plan tracked adequately?
• Were changes to the plan adequately communicated?
• Did you have adequate input into planning?
• Suggestions for improving the planning process.
• What caused deviation from the plan?
Cost • Were costs adequately anticipated?
• Were there costs that were not anticipated? Why?
• What caused cost growth?
Resources • Were resources available when needed?
• Were the tools used in the project adequate?
Communications • Were communications timely and adequate? What about other
and meetings means to communicate?
• Were meetings useful, necessary?
• Were meetings held too often, not often enough?
• Were meetings run efficiently?
• Were team members prepared for meetings?
• Were the results of meetings delivered to all team members
in a timely fashion?
• Did the process of decision making work? Improvement?
• Were conflicts resolved adequately?
Reflection • What did you enjoy the most during the project?
• What did you find frustrating during the project?
• What was successful?
• What was not successful?
• What was not achieved?
• If asked to be on another project team, what one thing would you make sure was in place?
• What could have been done differently (hindsight)?

Appendix B
Lessons Learned Document
Project: System:

Project Manager: Project Owner:

Question Lessons Learned

1. What did you enjoy the most

during the project? Why?

2. What did you find frustrating

during the project? Why?

3. What was successful?

4. What was not successful?

5. What was not achieved?

6. If asked to be on another
project team, what one
thing would you make sure
was in place?

7. What could have been done

differently (hindsight)?

IT Professional’s Guide to Project Management