Learn iT!

Project Management for IT Participant Workbook

33 New Montgomery Street - Suite 300 | San Francisco | CA | 94105 | 415.693.0250

2025 Gateway Place - Suite 390 | San Jose | CA | 95011 | 855.838.5028 www.learnit.com

2

Copyright © 2013 LearniT! All Rights Reserved. This book or any portion thereof may not be reproduced or used in any manner whatsoever without the expressed written permission of the publisher. Printed in the United States of America LearniT! Printing, 2013

3

The Project Management Institute (PMI)

PMI is the leading membership association for the project management profession.

Founded in 1969 by working Project Managers 420,000 members and credential holders 250 chapters in over 70 countries

A Guide to the Project Management Body of Knowledge®

A Guide to the Project Management Body of Knowledge® (“The PMBOK “) is a book which presents a set of standard terminology and guidelines for project management.

The PMBOK® Guide is meant to offer a general guide to manage most projects most of the time.

4

Common Project Management Tasks

Establishing objectives

Breaking work into well-defined tasks

Charting the sequence of tasks

SchedulingBudgeting

Coordinating a team

Reporting

Project Management Functions Managing a project consists of executing defined activities that are more or less similar for almost all projects.

5

PMI’s Five Process Groups Project Management activities are grouped into five different categories called Process Groups.

Enter Phase/Start Project

Closing Processes

Exit Phase/End Project

Initiating Processes

Monitoring & Controlling Processes

Planning Processes

Executing Processes

Initiating Process Group

Planning Process Group

Executing Process Group

Monitoring and Controlling

Process Group

Closing Process Group

6

Global IT and Business Management Best Practices Prince2® Projects in Controlled Environments® (version 2) is a project management best-practice framework conceived and owned by the government of the United Kingdom. One of the main best practices in the Prince2® framework is constantly balancing the needs of the business with the needs of projects. Adaptive Case Management/Knowledge Work. Resource Managers are constantly balancing the work of employees in three areas: Operations, Knowledge Management, and Project Work. These three “types” of work are discussed later in this class. For now, consider them as “defined task work,” “figure it out work,” and “official project work.” Agile (as a management framework) Agile as a management framework means that work teams are created and disbanded as needed to do whatever kind of work needs to be done. Workers might be assigned to a department but they will be called on to work together on many cross-departmental, corporate, or even business lines. Some people call these teams “tiger teams” or “virtual teams.” Functional managers may lead these teams or the teams may be self-building, distribute work internally, manage progress, and declare when the work is done. Once the work is done, the “team” disbands. Control Objectives for Information and related Technology (COBIT®) COBIT’s intention is to help businesses create optimal value from IT by maintaining a balance between beneficial outcomes (values of work) and optimizing risk levels and resource use. COBIT addresses both business and IT functional areas across an enterprise. IT-related interests of internal and external stakeholders are discovered, assessed, and business plans are created to address them. COBIT has five key principles for governance and management of enterprise IT: Meeting Stakeholder Needs, Covering the Enterprise End-to- End, Applying a Single, Integrated Framework, Enabling a Holistic Approach, Separating Governance from Management. Information Technology Infrastructure Library (ITIL®) ITIL® is a collection of five books that comprise the best practice framework of utilizing IT in an organization. It was created by a group of departments in the United Kingdom government and currently sponsored by an organization named Axelos. There are five components (thus five books) within ITI: Service Strategy, Service Design, Service

7

Transition, Service Operations, and Continual Service Improvement. ITIL asks the organization to have a mature portfolio of services (products) that they offer, make conscious business decisions (some based on COBIT principles), and have thorough and mature business plans to accommodate every service/product throughout their lifecycles. In other words, complete business plans that cover everything from strategy to actual provision of the service or product.

8

Project Integration IT projects are usually part of a larger organizational project or program. There is a current argument that is made that there is no such thing as a totally “standalone” IT project that only affects or benefits IT. Since IT is “owned” and paid for by the income from the larger business, IT is naturally a part of the business. Past practices that may have treated IT as a separate “cost center” from the typical financial and management systems are now seen to be short-sighted and financially skewed. The costs of ramping up IT systems are not just “administrative overhead” but an actual, direct cost to the business. The ease of adopting new or changed IT technology is also a cost to human resource production (often referred to Organizational Change Management or OCM). Today’s view is that all projects affect the larger organization. All projects must be governed by conscious business practices; all projects must be managed as a part of the overall business plan. All project costs, risks, goals, and deliverables are part of the business’s costs, risks, goals, etc. There are many best practices that state all projects or programs are in service to the business; therefore, IT is part of the program or project. IT projects that are managed within the IT “silo” are now considered suspect of mismanagement to some degree. In organizations that do have projects with IT components, IT is often removed from the Sponsorship and Initiation Phases. The business may start a project, get it underway, and address the IT portions only when the business “needs” IT to perform a portion of the work. This means that IT is involved during the implementation phases. This does not allow a lot of learning to take place for the technical participants. Often the greater Visions, Missions, and Goals for the project are fuzzy to the IT staff (at best). IT is then caught by surprise: resource, purchasing, training, etc., needs then become rushed. It is not uncommon for some businesses that approach IT in this way to also underestimate the amount of work it takes to implement IT portions of projects. It is assumed that IT just “plugs and plays” its basic skills and resources into the project. Many projects that require IT participation are covering new ground. IT needs a portion of time for self-training, trial runs, prototyping, etc., before a “final” IT solution can be added to the project. Some organizations also “hand over” the project to the IT department if there is any IT component at all. IT can then be inappropriately seen as the owner of the entire project. It is important to have clearly defined and transparent roles and responsibilities for all artifacts of success for a project.

9

Roles of Project Practitioners

KEY STAKEHOLDERS AND THEIR CONTRIBUTIONS

Sponsor

Provides authority for project to proceed; guides and monitors the project together with the project manager; key organizational advocate for the project. Typically, the sponsor will approve the project charter.

Core Project Team Provides skills, expertise, and effort to perform the tasks defined for the project; assists with planning and estimating project tasks.

Customer (Internal and External)

The individual or organization that will pay for the product created by the project. Establishes the requirements for the project; provides funding; reviews the project as milestones and deliverables are met. Ultimately accepts the finished product.

Functional Managers Establish company policy; provide human resources; some will provide review and approval authority.

Project Team

Project Expediter The Project Expediter monitors and reports on the status of the project to senior management. This role typically has no authority to make and enforce decisions. Project Coordinator The Project Coordinator performs the same functions as the Project Expediter, but has more authority, and is more involved in the decision making process. Project Manager The Project Manager is in charge of the project, and has full authority to direct and execute the project as well as make project decisions.

10

Many people who find themselves labeled “Project Manager” on an IT-component project are actually Expediters or Coordinators. They have very little, or no, discretion on managing the project proactively. Their main role is simply to get the work done and the deliverables produced by the scheduled dates and costs. It is extremely important to have all the roles defined for all stakeholders and practitioners (resources) on a project. Whoever is assigned to be on a project, regardless of their role, needs to be able to understand the goals and objectives of a project, where and how the work they are doing fits into the “greater picture,” and help keep the project’s momentum. What follows is a list of personal characteristics and behaviors that “good” project managers should exhibit. Which of these characteristics do you think all of the project participants should share, as well?

Level of Authority and Responsibility

Project Expediter

Project Coordinator

Project Manager

11

Attributes of Effective Project Managers

Charismatic and Enthusiastic

• They know that they are vital to keeping the project team motivated and involved.

Excellent Networkers

• The best PMs understand that relationships are the key to making cross-functional projects run smoothly.

Excellent Communicators and Listeners

• The ability to communicate with people at all levels is imperative. Successful projects require clear communication about project goals, responsibilities, performance, and expectations.

Detail-Oriented

• The best PMs use systems and technology to keep track of the project details so that red flags are dealt with immediately.

Customer-Focused

• The ultimate measure of a project's success is the customers' satisfaction with the results.

Understand the Big Picture

• The best PMs know how to align and present the goals of the project with the overall goals of the organization

Possess Industry Knowledge

• Industry knowledge, as well as Project Management knowledge, is crucial to the overall success of the project.

12

10 Knowledge Areas (From the PMBOK® 5th Edition) The discipline of Project Management is essentially a series of related processes that fall under the “umbrella” of these 10 Project Management Knowledge Areas. Keeping attention to these 10 areas will help a project stay aligned to the Vision-Mission-Goals-Objectives chain.

What follows is a matrix of the responsibilities of a project manager across the life of a project within the Knowledge Areas (PMBOK® 4). You can think of them as the “comprehensive deliverables list of a project manager” for project management planning and execution.

Integration Management

Scope Management

Time Management

Cost Management

Quality Management

Human Resource Management

Communication Management

Risk Management

Procurement Management

Stakeholder Management

13

Project Management Framework Matrix (From the PMBOK® 4th Edition)

14

A Framework for Becoming Part of the Project Understand the:

An example Vision – Mission – Goals – Objectives chain is: Vision: The Caldecott family of transportation companies enables the citizens of the State of California to travel safely and efficiently throughout the State. Mission: The Caldecott Tunnel Division imagines, designs, and builds tunnels through hillsides and mountains within the State of California. Goal: – The Caldecott Tunnel Division will enhance highway travel between Alameda and Contra Costa Counties in the State of California. Objective: The Caldecott Tunnel Division will drill a fifth bore to the existing Caldecott Tunnel system. This project will start October 1, 2020 and end by July 30, 2025. To turn the Objective into a more concrete Project Plan you should be able to answer the following questions.

Vision

Mission

Goals

Objectives

•What the owning organization wishes to bring to the world as value to customers.

•How the Line of Business (or Enterprise) intends to bring value to the world.

•What specific ways value will be described as the Mission is implemented

•What specific products, services, or conditions the Enterprise will produce to enable the goals to be met

15

Project Effectiveness Questions

These are a series of questions that should be asked at the beginning, during execution, and at the end of the project. The final report that is published at the end of Project Closing should address these questions to ensure the project was initialized properly and will ultimately meet the business need the project was intended to address.

What business situation is being addressed?

What will you do?

How will you do it?

How will you know you did it?

How well did you do ?

16

Starting off “right” The Initiating Process is when you: 1) Define the project, and 2) Get formal authorization to begin. These processes fall in two PM knowledge areas –

Integration Management

Communication Management

The deliverables from these processes are the:

Project Charter

Stakeholder Registry

Enter Phase/Start Project

Closing Processes

Exit Phase/End Project

Initiating Processes

Monitoring & Controlling Processes

Planning Processes

Executing Processes

17

IT Project Integration Getting involved “soon enough” by interfacing with organizational entities: Certain constituencies will give you information about the Vision to Objective Chain. The sooner you can learn about the expectations and concerns these groups have about a specific project, the better: this will help avoid “zombie” or ineffective projects. CEO/COO/CIO (Executive Board) – This group can give you insights about the vision, missions, and goals of the organization. They select and prioritize projects at a strategic level. They also set policies for Human Resource, Financial, Marketing, New vs. Maintenance Initiatives, etc. Executive Steering Committee – This kind of group can be formed for Major Missions, or Strategic Goal Setting. They can also be formed to oversee a specific Program to ensure that the objectives of the Program’s Projects will obtain the goals of the enterprise. Program/Project Management Office – This can be a department or workgroup at the executive operations level of an organization or a PMO that is within IT only. PMO’s can have 3 basic roles, as policy and standard creators, as project advisors and trainers, or can actually take over the project management of projects for an organization. Organizational Change Control Board – This is a cross-department team of executives and managers empowered to allow changes to how an organization is run or does business. This is the “gatekeeper” group who ensures that the organization is managed with a consistent policy and practice set. The purview of this group can range from human resources, budgeting, to approvals to improving a sellable product. This function may be handled by a body of managers known at “The Executive Tem.” Project Change Control Board – This is a collection of members from the various stakeholder groups involved in, or affected by, a project. This group is intended to consider proposed changes to a project plan, approve and disapprove proposed changes to schedule, resources, costs, work processes, or deliverables. No change to the project is allowed unless the appropriate responsible parties assess, process, and approve changes. For some changes the Project Manager may be empowered to act alone. In other situations it could be the PM and the Sponsor/customer, etc. Each level of authority should be detailed in the RACI, project charter, or other official document. An Emergency Change Board should also be created for highly urgent or risky modification to the plan. Continuous Service Improvement Boards and Taskforces – These organizational groups may exist in an organization that has adopted COBIT, ITIL, TOGAF, or other IT integration frameworks. These groups are responsible to ensure all business operations and projects are working at maximum efficiency and cost-effectiveness while improving products and services to end-users. These are very often the same, or tightly connected to, Organizational Change Boards and the like.

18

As there are so many factors and stakeholders that can affect any project, here is a list of things an IT Project Lead/PM should know before committing to any firm project plans. What to require before committing to a project.

Understanding the “corporate project type.” Understanding the role of Internal IT in the project/program. Understanding the role of the Internal Business Department IT in the

project/program. Understanding the roles in a Multi-departmental project/program. Understanding the roles of a Multi-agency project/program.

19

Understanding the differences between the Project/Program Management Processes and the IT Development Lifecycles Project Management is concerned with:

Using skills and tools to create an entire “business plan” for the creation, forming, planning, execution, and feedback of a project in an organization.

Some widely-used project methodologies are:

Project Management Institute’s 5-Process Groups/10 Knowledge Areas Prince2® (Projects IN Controlled Environments ver. 2) Projects Integrating Sustainable Methods (PRiSM) Critical Chain Management Event Chain Methodology Agile Project Management 7-Step Project Management 13-Step Project Management

There are many names for other types of project management. Some would classify certain “methodologies” as a “style” under another method. The basic theory is to thoughtfully determine the overarching project management method or style that fits best for your business’s strategic needs. This class approaches projects from the Project Management Institute’s point-of-view. Systems Development (Product Development) is concerned with.

Using the “best” operational and technical methodologies to create, modify, and/or release technical systems into the business environment. This is where the “technical” requirements of the “product” are built, tested, and delivered. (A development method should be chosen in the project planning stage and utilized in the “execution” stages.)

Some examples of Systems Development/Product Development frameworks follow. These often get confused with Project Management Methodologies. Some of the methods listed below will be discussed in further detail later in this course.

Systems/Software Development Lifecycle - SDLC Scrum/Sprint (Within Agile) Prototyping Spiral Waterfall Joint Applications Development

20

Rapid Applications Development As with project management methodologies, some authorities in the field see certain SDLC’s as “styles” of overarching “methodologies” rather than discreet methods in-and-of-themselves.

21

The Project-to-Operations Continuum of Work In a project life cycle, the majority of money and time is spent during the execution phase of the project. Project Life Cycle

Co

st

Definition Planning Execution &

Control Closing

Time

On the other hand, in a Product Life Cycle, there is a natural progression from the introduction of a new product as it goes through growth and maturity and into decline. Multiple projects may be involved in carrying a product or service throughout it’s expected lifespan. A series of projects like this is called a “Program.” Project 1 Project 2 Project 3 Project 4 Project 5

Sale

s

Introduction Growth Maturity Decline

Time

It is considered to be a “best practice” for the stakeholders involved in project planning and execution to take a “Product Lifecycle Approach” before finally approving a project. This way the organization takes into consideration, not just the costs and impacts it takes to successfully complete a project, but also, the costs and impacts of turning the project’s outcomes to the ongoing operations of the business. The “total costs of startup and lifetime operations” may not be a project manager’s main focus, but they should be involved in helping the organization project the “Total Cost of Ownership” of a project’s outcomes.

22

Formal Definition of Projects A project:

Has a deadline or a target date for when the activities to produce the product, service, or result must be completed; and

Has a budget that limits the amount of resources that can be used to produce the unique product, service, or result.

Is a temporary endeavor undertaken to create a unique product, service, or result.1 Temporary

In this context, temporary indicates something with a defined beginning and end. The project ends when: Objectives are reached. It is determined that the objectives cannot be reached. Business needs change.

Unique

Something is unique when the organization has not done it before, which makes it difficult to accurately estimate what the activities are, as well as the costs, duration, or resources needed.

A project may be unique even if similar projects have happened before. Project Work can be defined as:

Ends Not-routine. Work that has not been performed before. Effort is unknown and must be estimated. Confidence can vary greatly. Past history

may be a guide, but fresh estimation is the best practice. Formal Definition of Operational Work (PMI – Adaptive Case Management)

Ongoing Regular or easily-performed work. Effort is known or easily determined.

Formal Definition of Knowledge Work (Adaptive Case Management)

Ongoing Not-routine. Work that has not been performed before. Effort is known or estimated with some level of confidence that varies on the

context of the work/issue at hand. There may be reliable guidelines based on past performance.

1 (Project Management Institute 2008)

23

Before you should approach an initiative as a project, you must be able to answer YES to all of the following questions.

Is it clear who the Project Manager is?

Is it clear who the requestor (sponsor) is?

Does it have a clearly defined goal?

Does it require a planned sequence of activities?

Does it have a measurable end?

Does it have a measurable beginning?

Does it have a clearly defined deliverable?

Is the initiative unique?

24

Group Exercise: Will it Be a Successful Project?

Break into small groups and use the tool to decide if each scenario is ready for official project initiation.

SCENARIO #1

Your team needs to: Encourage employees to take more pride in working conditions.

Ensure employees are safe.

Motivate employees to keep the work space clean.

Does this fit the definition of a project? If not, how can it become one?

SCENARIO #2

Your team has been tasked by the CEO to create the software for a system that will allow your customers to log into a web site and transfer money from their bank accounts to their investment accounts. This needs to be complete by December 15th so there will be time for customers to move funds for the current tax year. Does this fit the definition of a project? If not, how can it become one? SCENARIO #3 You have been asked by the CIO to create a migration plan to upgrade the company’s operating system from Windows XP to Windows 7. Does this fit the definition of a project? If not, how can it become one?

25

SCENARIO #4

HR asked your team to rewrite the employee handbook. The rewrite will start October 1st, and needs to be done in time for the Thanksgiving holiday. Does this fit the definition of a project? If not, how can it become one?

26

Self-Discovery Think of a project you are currently (or, soon to be) working on. See how many answers you know in the following table. Break into small groups and discuss your answers. Was/is the initiative unique? Did/Does it have a clearly defined deliverable? Did/Does it have a measureable beginning? Will/Does it have a measurable end? Will/Does it require planning steps to achieve the goals and deliverable? Did/Does it have a clearly defined goal/business case? Is it clear who the requestor/sponsor is/was? Is it clear who the Project Manager is/was? If you are not the Project Manager, is it clear what your role is/was?

27

Scoping the Work of the Endeavor Scope is defined as the sum of the products, services and results to be provided as a project. In project management, the term scope has two distinct uses – Project Scope and Product Scope. Project Scope – The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions. Product Scope – The features and functions that characterize a product, service, or result.

28

Project Priorities and Constraints The Universal Project Pyramid demonstrates the balance between quality, resources, time and customer satisfaction that is required to conclude a project. Assuming the project has been planned correctly, the scope of the project is changed if you change any of these elements. Each of these factors should be discussed and agreed as to which one has the greatest priority to protect, then the second, etc. This ensures everyone involved in the project will have a clear understanding of the possible adjustments/negotiations that will be most acceptable if the project needs to be modified during further planning or during execution.

Scope

Time

Quality

Customer Satisfaction

Resources

Scope and Quality

29

Initial Statement of Work / Project Charter One of the first shared documents to start to build is the Initial Statement of Work (SOW) and/or the Project Charter. The Project Charter is a document that formally establishes, recognizes and authorizes the project.

It titles the project.

It describes the project.

It provides the high-level requirements for the project.

It links the project to the ongoing work of the organization.

It gives the Project Manager the authority to spend money and commit corporate resources.

Project Charter

Titles the Project

Describes the Project

Provides High-Level

Requirements

Links Project to Business

Purpose

Provides Project

Manager Authority

30

Sample Charter Project Name Project Manager Authorization

Initiating Authority Project Manager

Business Need the Project Addresses Project Priorities

Time Cost Quality

Scope Statement

Deliverables Boundaries/Non Deliverables

Project Assumptions Initial Project Risks Cost Estimates Schedule Estimates List of Stakeholders Success Criteria

31

Stakeholder Management Process The Stakeholder Management process is used to identify upfront all the people/teams/organizations that may be impacted by or have an impact on a project. When project planning processes exclude some of the stakeholders, it can often have unexpected and undesirable outcomes. Currently, it is thought that what looks like “Scope Creek” in most projects is actually caused by “Stakeholder Discovery.” Determining stakeholders before they get involved with a project will keep “ramp-up” and “requirements surprise” contained to a major degree. A key output of the Stakeholder Identification process is the Stakeholder Management Plan, which lists the project’s stakeholders and relevant information and strategies for each stakeholder or stakeholder group.

Steps to Develop a Stakeholder Management Plan

Step 1--Identify Stakeholders

Step 2 --Anticipate Influence

Step 3 --Prioritize Impact

Step 4 --Develop Strategy

Step 5 --Stakeholder Management Plan

32

Identify Stakeholders and Anticipate Influence The following questions serve as a tool that allows us to identify and anticipate stakeholder influence.

Who are the key people who care about the work affected by the project?

What do they know about the project already?

Who knows about the project and can help me understand the situation?

Who doesn’t know about the project, but should?

Who might oppose the project?

What will they dislike about the project?

Might any stakeholders have hidden or additional agendas?

Should I consider any bias factors with the stakeholders?

How can I best manage stakeholder expectations for the project?

33

Stakeholder Questionnaire Exercise 1. Who are the key people who care about the project?

a. What do they know about the project already?

2. Who knows about the project and can help me understand the situation?

3. Who doesn't know about the project, but should?

4. Who might oppose the project?

a. What will they dislike about the project?

5. Might any stakeholders have hidden or additional agendas?

6. Should I consider any bias factors with the stakeholders? 7. How can I best manage stakeholder expectations for the project?

34

Stakeholder Registry First time – Identify your project stakeholders and their interest in the project Second time – Prioritize their impact and consider a management strategy Stakeholder Interest(s) in

the Project Prioritization of

Impact Initial Strategies for obtaining

support or minimizing opposition

35

Prioritize Impact of Stakeholders After identifying project stakeholders and their connection to the project, we then want to prioritize them based upon:

A) The impact the project will have on them (Interest Level), and B) The level of influence they have on the success of the project (Power Level).

Medium Priority

Highest Priority

Lowest Priority

Medium Priority

High

High Low

Inte

rest

Le

ve

l

Th

e im

pac

t th

e p

roje

ct w

ill h

ave

on

th

e st

akeh

old

er

Power Level The impact the stakeholder can have on

the project

36

Develop Strategy for Stakeholders By determining the impact of the project on the stakeholder as well as the power they have to influence the project, we can then begin to determine the most effective ways to obtain stakeholder support or minimize opposition.

Medium Priority

(Address Concerns)

Highest Priority (Involve

Extensively)

Lowest Priority (Keep

Informed)

Medium Priority

(Involve as Needed)

High

High Low

Inte

rest

Le

ve

l T

he

imp

act

the

pro

ject

wil

l hav

e o

n t

he

stak

eho

lder

Power Level The impact the stakeholder can have

on the project

37

Group Exercise Use the Stakeholder Registry to create your Stakeholder Management Plan.

38

RACI for the Project As you identify stakeholders, some of them will be needed to fulfill certain functions within the project. A very common best practice for this is to use a form called a “RACI.” RACI is an acronym that stands for:

Responsible- the resources that will be/are assigned to perform the actual work. Accountable – the stakeholder that will be overseeing that the work is completed

and to specifications. Consult – stakeholders that may be needed to give information/input to the project

management processes. May also be seen as Subject Matter Experts (SME’s). Inform – stakeholders who need to stay informed on the project management

processes and status of execution. In the Initiation Process Group, the RACI form may simply identify Departments, Vendors, Teams, or Skill designations. This is usually used as part of the Feasibility and Skill-Set Requirements functions.

Resource Needs for Database Upgrade Project Resource/Skill Needed Responsible Accountable Consult Inform SQL Programmer X DB Architect X HR Manager X Once/if the project is planned to the Phase level, a version of the RACI form may be used to identify the parties to be invoked during the lifetime of the project. This may be in the Initiation or the Planning processes. Phase Responsible Accountable Consult Inform Phase 1 Design IT, HR, Project

Manager, Project Team

Project Manager

Sponsor Sponsor, HR

Phase 2 Design Confirmation

IT, HR, Project Manager, Project Team

Project Manager

Human Resources

Sponsor, HR

Phase 3 Prototype IT Development Team

IT Department Manager

Human Resources

Sponsor, HR

Phase 4 Build Alpha IT Development Team

Project Manager

Human Resources

Sponsor, HR

Phase 5 Build Production

IT Development Team

Project Manager

Human Resources

Sponsor, HR

39

Once the project is decomposed to a level of assignability, the format may alter to reflect the following style. Responsible Accountable Consult Inform Write SQL DB Update Module

SQL Programmer

Project Team Lead

DB Architect HR Manager, Sponsor, EEO Reporting Officer

Test SQL Module

SQL Programmer

Project Manager DB R Us, Consultant,

HR Manager, Sponsor, EEO Reporting Officer

Design DB Table DB Architect Project Manager DB R Us, Consultant,

HR Manager, Sponsor, EEO Reporting Officer

Confirm Table Normalization Plan

DB Architect Project Manager

IT Department Director

DB R Us, Consultant,

HR Manager, Sponsor, EEO Reporting Officer

Identify Custom Fields

HR Manager HR Manager HR EEO Reporting Officer

HR Manager, Sponsor, EEO Reporting Officer

Verify Custom Fields

DB Architect HR Manager

Project Manager HR EEO Reporting Officer

HR Manager, Sponsor, EEO Reporting Officer

Test Custom Fields added to current reports

HR Manager HR EEO Reporting Officer

Project Manager HR EEO Reporting Officer

HR Manager, Sponsor, EEO Reporting Officer

The Graphical Work Breakdown Structure may be used to identify the RACI form in early stages. Once the WBS has been decomposed to the task/activity level, team members are given direct responsibility through a formal assignment process.

40

DB Upgrade Project

Project Manager

Human Resource Requirements

HR Department

DB Specification Documents

IT Department

DB Architecture

DB Architect

DB R Us

A Graphical Resource Breakdown Structure may be used to identify the RACI form in early stages. Once the WBS has been decomposed to the task/activity level, team members are given direct responsibility through a formal assignment process.

41

Communications Management Plan The purpose of the Communications Management Plan is to define the communication requirements for the project and how information will be distributed. The Communications Management Plan outlines the following:

Communcation Management Plan

What information

will be communicated

How the information

will be communicated

When the information

will be communicated

Who will communicate

the information

Who needs to receive the information

42

Communication Plan: Exercise Use your Stakeholder Matrix data to begin your Communication Management Plan.

Stakeholder Objective of Communication

Type of Communication

Frequency Owner Deliverable

43

Planning the Technical Part of a Project Get a clear delineation of the Deliverables (or Requirements) of the project.

Requirements are deliverables – these are not optional Attributes are qualities about deliverables – these have discretion Where the project sits in the Project Portfolio Documentation of how the initial budgets for cost and time were developed What kind of contracts have been evaluated or put into place? Documents that support any work to date about build/buy, etc. Anything else you can get your hands on

Documenting the Products of the Project Requirements

The Requirements Gathering activity (or activities) may be the most important task in the discipline of Project Management.

Stakeholders must have a clear understanding of the project requirements, constraints, and risks before the project is initiated.

Requirements Gathering answers the questions:

What do we need

to do?

How will we know when we

did it?

Requirements Gathering

44

Determining Business Requirements Business Requirements are the envisioned outcomes and benefits of the project from the larger, strategic perspective. This might include language such as “increase revenue in the local metropolitan area, increase customer satisfaction over the next business quarter, or any such business rationale that the organization’s management wishes to pursue. Business requirements are usually phrased in adjective and adverb-rich terms (e.g. profitable, accessible, and user-friendly). Upper business management is often the source of these requirements. Business requirements are the “executive overview/business case” in a Pre-Project Definition, Project Charter, and Project Scope documents. They will be used at some time after the project (this could be years) to evaluate if the project had the “final” intended business benefits first envisioned. The timeframe for the business benefits to manifest after the technical completion of the project is sometimes called the “management horizon.”

Determining Functional Requirements Functional requirements are how the system interacts with proposed end-users. This would include such things as use cases and functional descriptions. These will be used by the project resources to ensure that the product/system they create interact and function appropriately for the business’s functional needs. Actual end-users should be used as much as feasible to gather, interpret, and determine quality metrics for these requirements. One of the most useful places these will be used is as the basis for test scripts and procedures.

Determining Technical Requirements Technical requirements are how the project/system needs to be built “behind the scenes” to operate to the performance standards the users expect/demand. These are more typically created by the resource technical team and not of much interest to customers. Deeper, architectural designs, transmission protocols, etc. are examples of technical requirements. The team typically uses these for quality testing before user testing is performed.

45

Documenting Requirements All requirements should be documented and reviewed by any and all stakeholders who may need to be aware of them. Each requirement, from the business requirements, through the functional requirements, to the technical requirements should be cross-indexed in some method to show how they all fit together or roll-up into a system known as a Requirement Traceability Matrix. A very simple matrix might look like the following: Business Requirement Functional Requirement Technical Requirement Increase speed of viewing form A-1 to enable increased data throughput.

The user presses the F5 key to retrieve form A-1.

The F5 Key is re-mapped with the hotkey application to the application module that retrieves form A-1.

Another version that might be used for larger requirement sets (where the requirements are in different documents) might be like the following: Business Requirements 1.0 Increase speed of retrieving forms to enable increased data throughput. Functional Requirements Functional Requirements Requirements Supported 2.1 Replace manual search entry with keyboard hotkey – Supports BR 1.0

Supports BR 1.0

2.1.1 The user presses the F5 key to Retrieve form A-1

Supports FR 2.1

Technical Requirements Requirements Supported 3.1 Map the F5 key to the form retrieval subroutine.

Supports FR 2.1.1

3.1.1 Current mapping of the F5 key is cleared

Supports FR 3.1, FR, 2.1.1

3.1.2 F5 key function is linked to the forms retrieval subroutine and points to form A-1

Supports FR 3.1, FR, 2.1.1

46

Requirements Gathering Exercise On the following pages: Use the Requirements Gathering Tool to consider the High-Level information you will need in order to successfully initiate a project. If you do not know or have access to certain information, consider:

A) Is this information crucial to project success? B) How you might be able to get this information?

47

What are the goals for this project? How do the project goals map to business goals? What are the project deliverables? What problems should this project solve? What problems should this project NOT address?

48

What do we specifically need to accomplish to make this project successful? Are we lacking any critical elements such as budget, resource allocation, or support? What are training considerations for team members and users? What are the high-level assumptions? What are the known issues?

49

What additional questions would be helpful, or what else do you need to know in order to execute the project successfully? Capture those questions in the space provided below.

50

Risk Assessment Begins as Soon as Possible in the Process Risk identification, assessment, and management are some of the most important duties of a project manager. There are basically two “styles” of risk identification – proactive and reactive. It is considered best practice to be as proactive and thorough as possible in risk identification to keep “figuring things out in the heat of battle” later. Some practitioners define a “risk” as a proactively foreseeable event and an “issue” as a risk or problem that arises in the execution of a project. In other words, we plan for “risks” and are surprised by “issues.” It is considered best practice to keep Risk/Issue log that notes the risk/issue, the date it was identified, the date it was closed, and other notes of interest. The assessment is another document with more details. Here is a basic example:

Risk Impact Probability Index Trigger Trigger Monitor Action Server not delivered on time

4 2 8 Not delivered to loading dock by 12/5

Loading dock manager

Call PM on 12/5 by noon.

Resource not skilled 3 4 12 DB architecture draft not complete by 6/30

PM Check with resource and functional manager June 20.

In the above example, the Impact and Probability are ranges of 1 to 5, with 1 as low impact or probability and 5 being major impact/stop and 5 as 95%-100% likely to happen. The two numbers are multiplied together to get a score for the combined “weight” in the list. This can help prioritize which risks to track more diligently and which risks might go on the “watch list.” Highly risky activities on the “critical path” (discussed later) might need to be prioritized over all the rest, regardless of the indexes. Class Exercise: Break into small groups and brainstorm a Risk Assessment form that would be useful to you/your organization. Discuss how you would define Impact and Urgency in your projects.

52

Function of the Work Breakdown Structure (WBS) A Work Breakdown Structure (WBS) is a hierarchical chart used to organize all of the project’s required activities into related areas. A WBS should help you organize and summarize the work necessary to complete the project. The WBS is used to:

The WBS is iterative:

As you progress through the project, you will gather more information and learn more which should allow you to refine your plan to greater accuracy and predictability.

Create an overview/summary of the entire project.

Break the project into smaller sub-projects.

Determine how project tasks are related to and affect one another.

Plan the schedule, define milestones and measure project progress.

53

WBS: Key Terms What to build? Deliverable: Any unique and verifiable product, result or capability to perform a service that must be produced to complete a process, phase, or project. (Project Management Institute, 2008) Sub-Deliverable: A component of a Deliverable

Work Package/Terminal Element: A deliverable or project work component at the lowest level of each “branch” of the work breakdown structure. It is not further decomposed. (Project Management Institute, 2008) How to build it? Activity/Task: A component of work performed to produce a deliverable. (Project Management Institute, 2008) Element of Work: an activity required to complete a project that is too small to be elevated to the rank of work package. Elements of work are NOT included on a WBS. (G. Michael Campbell, 2007)

54

Four Keys to a Successful WBS

Follow the 100% rule -- The WBS should capture 100% of the work defined by the project scope and should not include ANY work that falls outside of the project scope.

A narrative should accompany the WBS. To provide more detail, label each box in the WBS with a reference number citing the narrative document.

Deliverables should be measurable.

The WBS should be created with the input of those doing the work.

55

Sample Work Breakdown Structure

http://www.successful-project-management.com/work-breakdown-structure.html

Rock Concert

1. Marketing

2. Venue Preparation

2.1 Site Location

2.2 Auditorium

2.3 Stage

2.31 Power

2.31 Staging

2.33 Pyrotechnics

2.34 Rigging

2.35 Graphics

2.36 Sound

2.37 Filming

2.38 Lighting

2.4 Amenities

2.5 Access/Egress

2.6 Media Facilities

2.7 Power and Utility Infrastructure

3. Event Management

4. Performance

56

Group Exercise: Deliverables & Work Packages 1. Which is the more clearly stated work package?

A. A User-Friendly button layout on the hand-held remote control

B. A TV control system

2. What is wrong with these activity descriptions for a bathroom remodeling project?

A. Frame and install plumbing

B. Finish the remodel

3. What is wrong with these activities for a car-washing project?

A. Get soapy water and polish the car

B. Hook the hose up to the faucet

57

Decomposition and Criteria for Completion Decomposition is the subdivision of project deliverables into smaller, more manageable components (or sub-deliverables) until the work and deliverables are defined to the work package level. Criteria for Completion A deliverable is decomposed to the work package level when:

A. It forms a unique and measurable deliverable

B. Once begun, it has no external dependencies – the activities that make up the work

package can continue until completion

C. Effort and cost can be confidently estimated

D. It doesn’t make sense to break it down any further

The 100% Rule One of the most important decomposition principles is called the 100% Rule. It states that the WBS includes 100% of the work defined by the project scope and captures all deliverables – internal and external – in terms of the work to be completed. The sum of the work at the “child” (work package) level must equal 100% of the work represented by the “parent” (project). The WBS should not include any work that falls outside the actual scope of the project.

58

Decomposition Approaches: Noun First, Verb First and Hybrids Noun First Decomposition Approach What it is

Works best for Product-oriented projects Can be effective for:

o Planning strategy o Showing to non-technical people o Easier to read and understand

Technique:

Identify the goal.

Break down the goal into high-level deliverables.

Identify activities that must be performed from the beginning to the completion of each

deliverable.

Decompose activities into smaller deliverables until the work is defined at a sufficient level

of detail to allow for time, cost, and resource estimates.

Mountain Bike

Management and Planning

Wheel System

Hubs

Rims and Spokes

Gear SystemFrame System

Seat System Brake System Test

59

Sample WBS: Work Package Level Models (Noun First)

Sample Work Breakdown Structure with Some Branches Decomposed Down Through Work Packages2

2 (Project Management Institute, 2008)

60

Verb First Decomposition Approach

What it is: Works best for Process-oriented projects, or projects that are similar to previous projects

and the deliverables are well-understood. Lists work actions/activities/tasks with the outcome at the end

o Can be effective for:

Determining actual work (time and resources) required

Understanding project workflow

Assigning work

Estimating costs

Technique: Identify the goal.

Break down the goal into high-level phases.

Identify the activities that must be performed from the beginning to the completion of each

phase.

Sequence necessary activities until the task is defined at a sufficient level of detail to allow

for time, cost, and resource estimates.

Mountain Bike

Management and Planning

Design

Design Frame

Design Components

Purchasing Frabrication Painting Assembly Testing

61

Sample WBS: Verb First Approach with Activity List

3

3 Image taken from http://www.projectcrash.com/2011/05/9-create-work-breakdown-structure-wbs.html

1. Feasibility Phase 1.1 Do literature search 1.2 Do market research 1.3 Locate a publisher 2. Planning Phase 2.1 Collect data 2.2 Plan approach 2.3 Do chapter summaries 2.4 Engage the publisher 3. Writing Phase 3.1 Sort data 3.2 Write draft 3.3 Write introduction 3.4 Write conclusion 3.5 Edit final draft 4. Publishing Phase 4.1 Submit copy 4.2 Desktop publish 4.3 Complete final edits 4.4 Submit for final approval 4.5 Print 5. Marketing Phase 5.1 Arrange for a distributor 5.2 Arrange publicity 5.3 Launch!

62

Sample WBS: Major Deliverable Decomposition (Hybrid Approach)

Figure 1: Sample WBS for a Newsletter Project4

4 (G. Michael Campbell, 2007)

63

Group Exercise: Deliverables & Work Packages Consider a project you have coming up or would like to begin, are currently working on, or have worked on in the past. Title the Project: Part I. Choose a type of WBS (Function, Phases, or Deliverables) that will help your sponsor understand what the project will entail. Part II. Create your WBS on the next page (or on a separate sheet of paper), and be prepared to present it to the class. Remember, there is no one correct way to do a WBS.

64

WBS Exercise #2 Your team is on the Fundraising Committee for a local nonprofit organization, and has been tasked by the Board of Directors with planning a new fundraiser. The initial scope of the project calls for a cocktail party and dinner – with live entertainment and both a live and silent auction. Your team should work with the following high level assumptions:

The goal is to raise $30,000 (gross revenue).

Your initial budget (what you can spend) is $10,000.

The event will be held roughly six months from today.

If successful, the Board hopes to make this an annual fundraising event.

Changes or additions to project scope are permissible if agreed upon by the

committee.

Part I. Choose a type of WBS (Function, Phases, or Deliverables) that will help your Board of Directors understand what the event will entail. Part II. Create your WBS on the next page (or on a separate sheet of paper), and be prepared to present it to the class. Remember, there is no one correct way to do a WBS.

65

Choosing a Development Framework – When and Why to Use Each Once the list of requirements and deliverables has been documented in the WBS and Resource Traceability Matrices, the next step is deciding what method of planning and execution will best deliver the project outcomes in the most time-, cost-, and effort-efficient ways. Two of the most well-known styles are “Waterfall” and “Agile” development. Please note that these two styles are Development Styles not Project Management methods. Remember, building the “product of the project” is within the Execution Process Group; therefore, so are the use of the development styles. Managing the entire “business endeavor” to Initiate, Plan, Execute, Control/Manage, and Close the endeavor is the “Project.” Here are some short descriptions of “Waterfall” and “Agile.” Waterfall - SDLC – Software/System Development Lifecycle “Waterfall” means that you plan to use a sequential development process model. Some of the most common “steps” in this model are: Conception Initiation Analysis Design/Build Construction Testing Production/Implementation Maintenance Using steps like these in a software development life cycle (SDLC) means the project’s execution only moves to the next step after the previous step/phase is completed. It is seen as a level of “failure” to go back to previous steps in this model. Since the waterfall model expects to move progressively in a straight-line path to completion, this style lends its use to certain types of industries in which the progress is “mechanically” progressive. Most projects with this pattern of sequencing fall into construction and manufacturing. The production of the deliverables follows a natural, linear process. (You can’t put the roof on a building until the walls are up, for example.) Certain “new” industries, such as software development, have not found the waterfall style very effective or easy to manage. User/customers change their minds often while in the execution mode of a project. Sometimes, users/customers have no discrete idea of what they want until they see a prototype. (“I don’t know what I want but I’ll know it when I see it.”) This has led to some problems with “going back

66

to the drawing board.” “Rewinding” a waterfall technical project can often be problematic. Agile - Scrums and Sprints “Agile” styles of planning and execution intend to create short-term deliverables that can be tested/approved by customers/users at a fairly rapid rate. This means that if a version or prototype is not acceptable to the customer/user, this is discovered quickly and early in the process and there is less “re-work” to do with making adjustments Three basic roles in scrum methodology are product owner, scrum master and team member. Product owners communicate product vision to the development team and represent customer interests via prioritization and requirements. Scrum masters act as a liaison between the product owner and the team. Their main role is to remove any barriers that may prevent the team from achieving its goals. Scrum masters help the team to remain productive, creative, and motivated. Multiple technical roles are often members of an agile “team:” software engineers, architects, analysts, programmers, QA experts, UI designers, and tester. Two of the major characteristics of scrum methodology are the Product Backlog (or simply, “The Backlog”) and the “Burn Down.” The Backlog is a high-level list of deliverables and requirements for the project. Each development session or “Sprint” has a Sprint Backlog which contains the list of work the team needs to address during each sprint. The requirements are then broken down into tasks with expected hours of work to accomplish them. The “Burn-Down Chart” shows the remaining work in the sprint backlog. It provides a simple view of sprint progress and can be updated every day. It is assumed that as hours are used up in “burn-down,” progress is concurrently made at the production level.

67

Exercise and Discussion Break into small groups and discuss the benefits and difficulties using these styles of development in your current business projects. Which projects (that you may or may not be involved in) benefit (or could) from the “Waterfall” method? Which projects have benefited (or could have) from an “Agile” method? Try to be specific and fair as you discuss the pros and cons of each. Every organization has a mix of “manufacturing/construction” as well as “experimental development.” Attempt to hone your skills on determining these types of projects in your world.

68

Determining the order of operations of the activities of a project Once you have an idea of the magnitude of the Initiative/Project that your organization has in mind, it is a good idea to take a “big-picture” look at what is finally expected and ask a few questions: Can we produce this in one small or large project? Is this better broken down into smaller projects? Should we take an overall Waterfall approach? Should we take an overall Agile approach? Should we use a “Hybrid” approach?

(Waterfall for the PM level; Agile for the Execution activities?

A suggested order of planning a business initiative works best in the following order:

Planning at the Program Level – Determine if your business outcomes are better delivered by forming multiple projects (sequential or simultaneous) that, as a collection, support the final business outcomes.

Planning at the Project Level – Determine the Sponsor, Project Manager,

Stakeholders, and Requirements for the/each project.

Planning at the Phase Level – Estimating activities, work, and costs by creating “bundles” of work related by some factor: timeframe, resource group, technical similarity, etc. Phases are also a common way to sequence the “backbone” of the project’s schedule.

Planning at the Activity/Task Level – Create activities/tasks that will produce

each outcome/deliverable in the project. Estimation of Effort (work hours), Duration, Dates, and task sequencing happen at this level.

Evaluating the Critical Path – Once tasks/phases have been sequenced, a

process is used to determine the “Critical Path.” This is the longest sequence of events in the project and determines the current end date for the project at any time within the project’s progress. Critical path tasks can change during execution if actual durations exceed baselines. This means that evaluation of the Critical Path is iterative and should be reviewed as frequently as needed.

Creating a project plan that all stakeholders find useful – Use tools that make

it easy for all stakeholders to understand. Create graphical methods of demonstrating the plans (WBS, charts in Excel); numeric reports based on dates, costs, and progress; and text-based reports as necessary.

69

Network Diagram: A Map for Your Project Now that we’ve discussed Project Strategies, Requirements, and Deliverables (as documented in the WBS), the next step is to begin sequencing the work in the project. This can begin as a simple sequencing of Phases within a project. If you use a tool such as Microsoft Project, this will be done at the task level. One of the first sequencing tools to use is a “Network Diagram.” What it is

A Network Diagram is a flow chart used by Project Managers. It is a graphical

representation of project activities that displays the sequence of work in a

project.

It is always drawn from left to right and reflects the chronological order of

the activities, based upon certain dependencies.

What it does

Shows the project activity sequence, and relationships between project

activities necessary to complete the project.

Identifies milestones in the project that can be used for monitoring progress

and completion.

Shows the relationship(s) between activities in the Work Breakdown

Structure.

Establishes a vehicle to plan and schedule activities.

Why we need it

Project work often happens in parallel because people may work on different

activities simultaneously. These activities may have complex relationships

and dependencies that are easier to see and understand with a Network

Diagram. The Network Diagram helps us plan our project schedule most

efficiently.

70

WBS v. Network Diagram

WBS Network Diagram

Identifies all of the deliverables

involved in a project.

WBS shows hierarchical

relationships between deliverables

on the projects.

WBS shows how many deliverables

have to be built.

Network Diagrams reveal the

workflow.

Network Diagrams show

chronological dependencies between

work being done on the projects.

Network Diagrams show the order

these activities need to happen.

Since we cannot schedule a hierarchy until we know the necessary sequence, we need both the WBS and the Network Diagram to best plan our projects.

Start Project

Activity A

Activity C

Finish ProjectActivity D

Activity B Activity E

71

Network Diagram – Key Concepts Precedence: Defines the sequencing order and how activities are related to

one another in the plan. When one activity in the project must be completed before another activity can begin, the first activity has precedence over the other.

Concurrent (Parallel) Activities:

These activities happen simultaneously and are identified by drawing them in parallel to each other in the same plane.

Lead: A period of time added in order to start an activity before the

predecessor activity is completed. Ex: Coding might be able to start five days before the design is finished.

Lag: The amount of time inserted after one activity is started or

finished before the next activity can be started or finished. Ex: We need to wait three days after pouring concrete before constructing the frame for the house.

Free Float/Slack: The amount of time that a scheduled activity can be delayed

without delaying the early start date of any immediately following scheduled activities.

Total Float/Slack: The total amount of time that a schedule activity may be

delayed from its early start date without delaying the project finish date, or violating a schedule constraint.

Milestone: A milestone is a special event or important deliverable in the project cycle that is used as a “checkpoint” to validate how a project is progressing. A milestone has no effort, duration or tasks associated with it.

Activity Box/Node: A box on a Network Diagram used to represent a project activity.

Dependency: Signifies the relationship between activities. Can be either predecessor or successor dependency based upon which activity needs to happen first.

72

Effort and Duration In order to calculate the eventual schedule and Critical Path, durations need to be determined for each phase/task in the plan. Duration is a function of the “Effort” or workload that is needed to accomplish an objective/deliverable. Effort: The actual number of labor units needed to complete an

activity, phase, or project. Duration: The total amount of elapsed time from initiation to

completion of an activity, phase, or project.

• Actual Number of Labor UnitsEffort

• Total Amount of Elapsed Time from Start to FinishDuration

Exercise: Painting the interior of a new office building is estimated to take 80 hours of effort. Estimate the effort and duration using the following: If there is one worker committed to 40 hours per week: E_____, D_____ If there are two workers each committed to 40 hours per week: E_____, D_____ If there are two workers committed to 10 hours per week each: E_____, D_____

73

Estimating Activity Duration – PERT PERT stands for Program (or Project) Evaluation Review Technique. This three-point estimation method is used to lower risk through statistical means when you have no reliable historical data to use. It was first developed by the United States Navy’s Special Project Office. According to PMI, “…the accuracy of activity duration estimates can be improved by considering estimation uncertainty and risk.”5 When applying PERT to estimate activity duration, we use the following estimates: Most likely (t m):

Estimated activity duration bases analysis of realistic expectations of

resources, productivity, availability, dependencies and interruptions

Optimistic (t o): Estimated activity duration based on analysis of best-case scenario

Pessimistic (t p): Estimated activity duration based on analysis of worst-case scenario

PERT analysis calculates an Expected (t E) activity duration (weighted average) using the following formula

(Optimistic Estimate + (4 times Most Likely Estimate) + Pessimistic Estimate)

divided by 6

5 (Project Management Institute, 2008)

74

Group Exercise: PERT If you were installing a new web portal infrastructure, you might have a request to make sure that portal is secure from hackers. Your problem is estimating the duration to complete the activity called "conduct security testing and resolve any findings on a ten-server Solaris cluster.” You or your system architect determines:

Most likely you need 40 hours.

At best, you need 32 hours.

Worst case scenario – the task will take 120 hours.

Use PERT to estimate the duration of this activity.

75

Estimating Activity Duration – Additional Methods Parametric Estimating With this method, you estimate the time required for one deliverable or activity and then multiply it by the number of deliverables or activities required. Ex: If you need to create pages for a website, you'd estimate how much time it would take to do one page, and you'd then multiply this time by the total number of pages to be produced. Base and Contingency Estimation The base is the minimum expected time required, (i.e. when everything goes well). The contingency is the amount of trust placed on the base when risks are taken into account and is generally expressed as a percentage of the base. The formula for Base and Contingency Estimation is E=B + (B*C) Ex: Writing the code for the software will normally take 40 hours, but there is a 50% chance that we’ll have to redo a lot of it. The estimate would then be 60 hours. Historical Data Historical records from previous projects can and should be used to estimate activity duration. Expert Advice Vendors, colleagues and the internet can be great sources of expert advice. Heuristics A Heuristic is simply a rule of thumb. Ex: A good rule of thumb states that up to 30% of the project life cycle should be spent in the planning phase.

76

How to Build a Network Diagram 1. Create a list of activities.

2. Estimate the duration for each activity.

3. Identify each activity’s dependency. (For Critical Path calculations, only the “Finish-to-Start” type of dependency is used.

4. Identify activities that can be run simultaneously.

5. Turn the list of activities into a network diagram:

a. Begin with a “Start” milestone.

b. In the first column, draw a box for each activity that has no predecessor – activities that can start immediately.

c. In the next column create boxes for activities that are dependent on activities in the first column.

d. Draw arrows to connect all activities from their predecessors.

e. Continue in the same way with the remaining activities.

f. Give each box an individual ID#.

g. Fill in Task Name and Duration data.

h. Finish with an “End” milestone.

77

Exercise: Build a Network Diagram Using the sample data, create a network diagram here (or use a separate sheet if you need more space):

ID # Task Name Duration Sequence / Relationships

1 Complete Project Plan 5 days 1st task

2 Audit Cable Plant 1 day Can start when #1 finishes

3 Train Network Engineers 10 days Can start when #1 finishes

4 Arrange Travel to Retail Locations

5 days Can start when #1 finishes

5 Install ATM Backbone 45 days Can start when #1 finishes

6 Install LAN / WAN for Locations

150 days Can start when #2, 3, & 4 have all finished

7 Cut Entire Network over to ATM Cloud

15 days Can start when #6 & 5 have both finished

78

Your Network Diagram should look something like this: Complete Project Plan Audit Cable Plant Install LAN/WAN for Retail Cut Entire Network Over

Location #1 to ATM Cloud

1 5 days 2 1 day 6 150 days 7 15 days

Train Network Engineers

3 10 days

Arrange Travel to

Retail Locations

4 5 days

Install ATM Backbone

For NOC

5 45 days

79

Determining the Critical Path Critical Path Methodology The Critical Path is the sequence of activities that must be completed on schedule in order for the project to be completed on schedule. The Critical Path Method calculates the longest “path” of planned activities to the end of the project, and the earliest and latest that each activity can start and finish without making the project longer. Critical Path Methodology (CPM) allows us to:

Predict the duration of the entire project.

Identify which activities are “critical” to maintaining the project schedule.

Identify which activities have free float/slack and total float/slack.

A delay in the critical path delays the project. Similarly, to accelerate the

project it is necessary to reduce the total time required for the activities in

the critical path.

Critical Path Methodology (CPM): Constructing a project schedule network diagram that uses boxes or rectangles referred to as nodes, to represent activities, and connects them with arrows that show the logical relationships that exist between them.6 CPM models the activities and events of a project as a network. Activities are depicted as nodes on the network and events that signify the beginning or ending of activities are depicted as arcs or lines between the nodes.

6 (Project Management Institute, 2008)

80

How the Critical Path Fits in Project Planning

Specify the individual activities.

Determine the

sequence of those

activities.

Draw a network diagram.

Estimate the completion

time for each

activity.

Identify the critical path

(longest path

through the network).

Update the CPM

diagram as the project progresses.

81

Critical Path Methodology in Detail 1. Identify the Critical Path

a. The critical path is the longest-duration path through the network. The

significance of the critical path is that the activities deemed on the path

cannot be delayed without delaying the project.

b. The critical path can be identified by determining the following four

parameters for each activity:

i. ES - earliest start time: the earliest time at which the activity can

start given that its precedent activities must be completed first.

ii. EF - earliest finish time, equal to the earliest start time for the

activity plus the time required to complete the activity.

iii. LF - latest finish time: the latest time at which the activity can be

completed without delaying the project.

iv. LS - latest start time, equal to the latest finish time minus the time

required to complete the activity.

The slack time7 for an activity is the time between its earliest and latest start time, or between its earliest and latest finish time. The critical path is the path through the project network where none of the activities have slack, that is, the path for which ES=LS and EF=LF for all activities in the path.

Activities are on the critical path when ES=LS and EF=LF

7 Slack is the amount of time that an activity can be delayed past its earliest start or earliest finish without delaying the project.

82

In the network diagram below:

Arrows: Represent finish-to-start relationship

Boxes: Represent individual activities

Task Name

ID #. Duration

One fast way to visualize the Critical Path (if you don’t need to determine discrete slack/float) is to count up the duration on each of the paths or “networks” and determine the path with the longest timeframe. For example, the paths in the diagram above are: 1,2,5 1,3,5 1,4,5 Which path has the longest duration? The following pages take you through the full “Forward Pass” and “Backward Pass” to help you understand discovering Slack and Float.

83

CPM: Steps to Calculate Early Start and Early Finish Steps to Calculate Early Start and Early Finish

For each task, calculate the early start and early end (progress from left to right)

1. Early Start = the latest “Early Finish” from all predecessors (previous column tasks)

2. Early Finish = Early Start + Task Duration

Note early starts & finishes on the diagram shown below:

84

CPM: Steps to Calculate Late Start and Late Finish

Steps to Calculate Late Start and Late Finish

1. Late Finish = the earliest “Late Start” from the column to the right (Late Finish for the last activity is the same as it’s Early Finish time)

2. Late Start = Its Late Finish (minus) Its Duration

85

CPM: Steps to Determine Critical Path To Determine Critical Path: Trace path of tasks with zero slack

Critical Path: Sequence of tasks that do not have any slack

86

Determining the Critical Path Here are more formal instructions for calculating the critical path. Use the Network diagram you used before to do a forward and backward pass. Forward Pass: Start with the first activity in the sequence and assign the Early Start (ES) and Early Finish (EF) for each subsequent activity.

ES for the first activity is zero.

EF for the first activity is its duration.

Assume that any subsequent activity starts as soon as all its predecessors are finished; for all those subsequent activities:

ES equals the latest EF of any of its predecessor activities.

EF equals the latest EF of any of its predecessor activities plus duration.

Move forward through all the activities until you have an ES and EF for each activity. Backward Pass: Start at the last activity in the sequence and assign a Late Start (LS) and Late Finish (LF) for each subsequent activity.

LF for the last activity equals its EF time.

LS for the last activity equals its EF minus its duration.

Assume that any predecessor activity finishes just before its earliest successor(s) start. For all those predecessor activities:

LF for any predecessor activity equals the earliest LS of any of its successors.

LS for any predecessor activity equals its LF minus duration.

Move backward through all the activities until you have the LF and LS for each one.

87

Float Calculate Float by subtracting all the LF-EF or LS-ES. If there are two or more activities with float in a path, the total float for that string of activities is shared by all the activities in the string. Critical Path The tasks with Zero Float are on the critical path. You must monitor and manage them carefully.

88

Complete Project Plan Audit Cable Plant Install LAN/WAN for Retail Cut Entire Network Over

Location #1 to ATM Cloud

1 5 days 2 1 day 6 150 days 7 15 days

Train Network Engineers

3 10 days

Arrange Travel to

Retail Locations

4 5 days

Install ATM Backbone

For NOC

5 45 days

89

Sample Gantt Chart

Gantt Charts are defined by PMI as a graphic display of schedule-related information. In the typical bar chart, scheduled activities or work breakdown components are listed down the left side of the chart, dates are shown across the top, and activity durations are shown as date-placed horizontal bars. (Project Management Institute, 2008) The examples below are screenshots from Microsoft Project.

Figure 2: Sample Gantt Chart

90

Where are we?

Where did we plan to

be?

How do we get

back on track?

Monitoring and Controlling Monitor – Measuring project performance against the project plan. The agreed-upon plan is captured and now called the baseline. Baselines can be set for dates, effort, duration, costs, quality, etc. Any aspect of the project that you want to measure and control should have a baseline. Control – The act of reducing the difference between the plan and reality.

91

What Should You Monitor and Control? As a Project Manager, you need to monitor the project activities as they relate to scope, schedule, costs, quality and human resources.

Project Activities

Scope

Schedule

CostsQuality

Human Resources

92

Inputs and Outputs – Monitor and Control Project Work

Inputs

Project Management Plan

(Baseline)

Performance Reports

(Status)

Enterprise Environmental Factors

(Internal and external factors that influence a project’s success)

Organizational Process Assets

(Records of previously executed projects)

Outputs

Change Requests

Project Management Plan Updates

Project Document Updates

93

Determine Project Status

Earned Value Analysis (EVA) Earned Value Analysis (EVA) is a tool that measures performance. It integrates cost, schedule and scope (progress) measurements to provide a consistent, numerical indicator – so you can evaluate where you are versus where you should be.

Project's EarnedValue

Cost

Schedule

Scope

94

Earned Value as a Tool As a tool, EVA allows us to:

A. Measure a project’s progress and

B. Easily compare project progress to baseline projections

C. Forecast future cost and effort needed.

Three quantities form the basis of Earned Value Analysis: 1. Planned Value (PV)8: The sum of the budgets for all work packages

scheduled to be accomplished within a given time period. (As of today, what is the value of the work planned to be done?)

2. Actual Cost (AC)9: Cost incurred to accomplish the work that has

been done to date. (As of today, what is the actual cost incurred for the work accomplished?)

3. Earned Value (EV)10: The sum of the budgets for completed work

packages and completed portions of open work packages. (As of today, what is the estimated value of the work actually accomplished?)

Additional terms define how we record cost and schedule performance and program budget: 1. Budget at Completion (BAC): The total Planned Value at the end of the

project. (How much did we budget for the total project effort?)

2. Estimate at Completion (EAC): Current ESTIMATE of total cost of project at completion. (As of today, what do we currently expect the total project to cost?)

3. Estimate to Complete (ETC): ESTIMATE to complete the remaining project work. (From this point on, how much MORE do we expect it to cost to finish the project?)

4. Variance at Completion (VAC): An ESTIMATE of the difference between the BAC and the expected total costs of the project based on current trends. (As of today, how much over or under budget do we expect to be at the end of the project?)

8 Also referred to as Budgeted Cost of Work Scheduled (BCWS) 9 Also referred to as Actual Cost of Work Performed (ACWP) 10 Also referred to as the Budgeted Cost of Work Performed (BCWP)

95

The following table provides a graphical representation of the EVA terms:

96

Acronym Term Formula Description

CV Cost Variance EV - AC Negative is over budget; positive is under budget. Shows actual amounts.

SV Schedule Variance

EV - PV Negative is behind schedule; positive is ahead of schedule. Shows actual amounts.

CPI Cost Performance Index

EV / AC We are getting $____ worth of work out of every $1 spent. Funds are or are not being used efficiently. Shows performance as an index. CPI>1, the project is under budget. CPI<1, project is over budget.

SPI Schedule Performance Index

EV / PV We are progressing at ____% of the rate originally planned. Shows performance as an index. SPI>1, the project is ahead of schedule. SPI<1, project is behind schedule.

EAC Estimate at Completion

AC + ETC (Bottom-up)

BAC / CPI

AC + (BAC – EV/CPI)

As of now, how much do we expect the total project to cost? *There are many ways to calculate EAC. Actual Cost + ETC (bottom-up) is most common.

ETC Estimate to Complete

EAC – AC or Bottom-up re-estimate

As of now, how much more will the project cost?

VAC Variance at Completion

BAC - EAC VAC forecasts the difference between the Budget-at-Completion and the expected total costs to be accrued over the life of the project based on current trends.

In the following four days, we expected to complete $400 of work: Day 1 2 3 4 Total Planned Value

$100 $100 $100 $100 $400

97

What actually happened was: Day 1 2 3 4 Total Planned Value

$100 $100 $100 $100 $400

Actual Cost $88 $80 $100 $100 $368 Variance $12 $20 $0 $0 $32 or 8% From an accounting sense, it appears that this project is under budget by $32. It was expected to cost $400, and has actually cost $368. What is missing from this equation is the value of how much work actually was completed or “performed.”

98

Day 1 2 3 4 Total Planned Value

$100 $100 $100 $100 $400

Earned Value

$80 $80 $80 $80 $320

Actual Cost $88 $80 $100 $100 $368 Schedule Variance (EV-PV)

$-20 $-20 $-20 $-20 $-80 20%

Cost Variance (EV-AC)

$-8 $0 $-20 $-20 $-48 15%

We now have a clearer picture of the actual status of the work. We currently have a schedule variance of $-80 and an SPI of .8. We were scheduled to complete $400 of work, and have only completed $320. In addition, the work that was completed ($320) has cost more than we had planned ($368), creating a cost variance of $-48 and a CPI of .87. The actual cost variance is not 8% as calculated by the traditional approach (PV/CV) but it is 15% (EV/CV) which is more accurate as it also considers the work accomplished.

99

Exercise: Earned Value Analysis

You are a Project Manager of a project scoped to paint a 4 story office building:

Each floor should take one day to paint and should be completed one after the other.

You have $1,000 per day budgeted for the project. Today is the end of Day 3.

Using the Project status chart below, calculate EV, etc.

Task Day 1 Day 2 Day 3 Day 4 Status at end of Day 3 Floor #1 S-------F Complete, Spent $1,000

Floor #2 S----PF --F Complete, Spent $1,200

Floor #3 PS-S-PF 50% done, Spent $600

Floor#4 PS---PF Not yet started

What is Calculation Answer Interpretation of the answer PV

EV

AC

BAC

CV

CPI

SV

SPI

EAC

ETC

VAC

100

Schedule Management

Types of Progress Reports Progress Reports are the tools we use to identify problems when they are small and there is still time to catch up. The Project Manager should determine what type of information will be collected from the task owners. The type of information depends on the task type, task importance, or level of detail needed for documentation.

This information can:

Be compared to the project estimates to determine project progress or

performance.

Warn of pending problems by visually depicting trends.

Create a valuable historical record for future projects.

Data Collected from Task Owners

Date EffortPhysical

% Complete

101

Date-Based Progress Measuring

Date-Based Progress Measuring: Checking actual start/finish dates against the baseline (estimated dates).

Good for quick, “on schedule” report to management

Can be used for almost any project

Date-Based Reporting Worksheet

ID Task Name Assignment Owner

Baseline Start

Actual Start

Start Variance

Baseline Finish

Actual Finish

Finish Variance Notes

1 Build the widget Sam 1-Jan 6-Jan 5 20-Feb 22-Feb 2

102

Self-Exercise: Date-Based Progress Measuring Tom and Jeff are working on a project for you. Use the empty cells on the Date-Based Reporting Worksheet on the previous page for the following situations:

Tom is revising the training plan for Tracy, the Human Resource

Manager. He was supposed to start Jan 5th, but didn’t actually start

until Jan 8th because Tracy asked him to do something else. It

looks like he will finish the training plan on Jan 12th; two days

after the original deadline.

Jeff is scheduled to update the company web site. He is supposed

to start the morning after Tom finished with the training plan, but

not before. It should take Jeff two days to update the site.

103

Effort-Based Progress Measuring Effort-Based Tracking: Checking actual effort against the baseline, usually tracked in day or hour increments

Good for rough cost estimates

More accurate than date tracking

Calculations for variance and percent complete:

Baseline Effort: Original estimated effort

Current Estimate: Most current estimated time to complete a

task. Actual + Remaining

Actual Effort: Duration of time that has already been spent on a task

Percent Complete: Actual Effort / Current Estimate

104

Effort-Based Tracking Worksheet Exercise *Actual and Remaining Effort data comes from Outside Data Inputs.

Fill in the empty fields on the Effort-Based Tracking Worksheet.

ID Task Name Assignment Owner

Baseline Estimate

Current Estimate

*Actual Effort

Effort Variance

Percent Complete

*Remaining Effort

Notes

1 Build the widget Sam 6 days 7 days 7 days 0 days 100% 0 Finished 2 Sell the widget Jeff 2 days 2 days 1 day ----- 50% 1 In progress

3 Collect the money Harlan 4 days 3 days -1 days 100% Finished early

4 De-brief team Jeff 6 days 6 days 2 days 100% 0 Finished late 5 Task 5 Biff 4 days 5 days 5 days 100% 6 Task 6 Marty 4 days 4 3 day ----- 75% 1

7 Task 7 Professor Brown 4 days 3 days 100% 0

8 Task 8 George 8 days 10 2 days ----- 8

105

Physical Percent Complete Physical Percent Complete is a progress measurement, where work is inspected against some measure of physical evidence. This technique allows for qualitative or subjective data to be measured and reported. Completeness should be

a pre-set value -- not estimated during task progress.

Percent complete measures accomplishment -not just effort, time and cost.

Measurement should be auditable -- Others should be able to view work and come to the same Physical Percent Complete value.

106

Physical Percent Complete (cont.)

• Report is 100 pages; 50 pages are finished: 50% Physical Percent Complete.

• Four walls need to be painted, three are finished: 75% Physical Percent Complete

Obvious Physical Percent Complete Breakdown

• An arbitrary scale should be determined in advance by the project team or project manager.

• Progress is then defined using the same scale.

Arbitrary Physical Percent Complete Breakdown

107

Exercise: Physical Percent Complete

Determine a Physical Percent Complete Scale for the following tasks:

1. 25 chairs must be refinished.

2. 1000 lines of code must be created for a piece of software

designed to count how many times people use the ATM. The

software must be finished by December 3rd. The task start date is

September 22nd.

3. The graphic design department must create a PowerPoint

presentation for a big meeting. Management wants them to be as

detailed as possible and create as many slides as they need. When

each step listed below is completed by the team, what physical

percent of a PowerPoint presentation will then have:

_____% interviewing management _____% creating an outline for the slides _____% creating copy _____% creating custom designs for each slide _____% presenting the presentation to management _____% making revisions

108

Quality and Quality Control For Project Management purposes, quality is defined as “the degree to which the project fulfills customer requirements.” There are a series of very important meetings between the project team and the customers/users of the deliverables of the project. These meetings are named “Validate Scope” meetings in which the customer/user approves of the deliverables created up to any point in the project. Any major deliverables that have critical effects on the progress of the project are sometimes called “Milestones.” Quality Control is the process of ensuring a defined level of quality in a product or service as defined in the Requirements Documents.

"Are we meeting the standards?"

"What changes

should be considered?"

Quality Control

109

Pareto Analysis Many times, when performing quality control, there are so many small issues that need attention you may not be sure where to start. A Pareto Analysis is a statistical technique that has us focus on problems that happen most often. It is based on the Pareto principle (80/20 rule) – the idea that a large majority of problems (80%) are produced by a few key causes (20%).

110

Pareto Chart What Is a Pareto Chart?

Bar chart arranged in descending order of height from left to right Vertical axis on left is the raw data you are measuring (frequency, cost,

severity, etc.) Vertical axis on right is the raw data converted to a cumulative percentage Horizontal axis is the categories of data

111

Pareto Chart Exercise The following technique allows you to identify and focus on the key causes that are causing a majority of the errors.

1. Create an issues log that records problem incidents and their frequency.

2. Rank the trouble incidents by frequency and determine their percentage

compared to the overall project issues.

Issue Frequency Rank Percentage Cumulative Percentage

TOTAL

112

Exercise: Pareto Technique Use the Pareto Technique to decide which problems you should focus on first:

Rank the trouble incidents by frequency

Determine each percentage of the whole

*Percentage = number of occurrences / total incidents

Starting from the most frequently occurring problem, add percentages until

you reach or near 80%

Issue Frequency Rank Percentage Cumulative Percentage

Deliverables are late

57

Requirements change

26

Client is slow to respond

156

Costs are higher than estimated

89

Research is limited

22

TOTAL

Which problem(s) should you focus on first?

113

Cause and Effect Diagrams Cause and Effect Diagrams, or Fishbone Diagrams, are a Quality Control tool that allow us to get to the root causes of defects.

114

How To Do a Cause and Effect Diagram:

1. Identify the problem.

2. Brainstorm the reasons why the problem is occuring.

3. Group the causes by relationship.

4. Analyze the diagram and further investigate the most likely causes.

115

Cause and Effect Diagram: Example

116

Cause and Effect Diagram: Exercise Cooking rice is very similar to a production process in a factory. The rice (raw material) is washed (pretreatment), then placed in a pot (equipment) to be heated and steamed (second treatment). Your instructor’s current rice process is producing bland tasting rice. The Process Steps he/she uses are:

Raw Material - receiving and storage

Pretreatment - rinsing and drying of the rice

Cooking - equipment, pots, time vs. temperature, etc.

Second Treatment - steaming and precooking the rice

Cooling and Packaging - time, temperature and storage

Create a Cause and Effect Diagram below or on a separate page to diagnose what could be the problem behind the bland rice.

117

Status Meetings One of the most valuable tools you have as a Project Manager is a Project Status Meeting. A status meeting is a standardized way for project team members to report on project performance, problems, issues and expectations. Benefits of regular Status Meetings include:

Teambuilding

Accountability

Receive Project

Feedback

Make Timely Decisions

Reinforce Key Points

Provide Coaching

New Team Member

Orientation

118

Effective Status Meetings Tips for planning and running status meetings:

Have meetings about once a week

Should be at same time/place to avoid confusion

Should include one representative from each project group/team

Send out the agenda before the meeting

Meeting notes/minutes are part of formal documentation and circulated for comments and archived

Control meeting by assigning additional meetings for topics that aren’t part of information gathering and aren’t relevant to everyone

119

Managing Project Variances If you determine that some factor of the project is getting “out of control” your first goal is to decide what the “root cause” of the problem is. For example, having cost overruns may be a factor of resources working more time on some task set than the items in the budget have become “more expensive” (in the context of price). Gold plating (making the deliverable “better” than the customer’s stated needs) can lead to cost overruns or schedule slippage due to increased use of time. It can also be a factor in “scope creep” where the number of and/or quality of the deliverables have increased over the project’s life. Having “stakeholder discovery,” once the project is in execution mode, can lead to all types of overruns, and most especially, “scope creep.” It should be obvious that very diligent planning can help avoid these risks; however, even with the most diligent planning, something will not go as expected. Here are some common issues that arise during project execution and some of the techniques you can use to cope. Issues Mitigation Scope Creep due to requirements change

A group of “advisors” known as the Change Advisory Board acts to evaluate changes to the deliverables and the processes used in the project. Changes should be formally addressed, the CAB makes its decisions, and the PM carries out the changes to the plan. All relevant documents that are affected should be updated to reflect the change, and new baseline is set (as appropriate and approved) and the project continues with the integrated change.

Scope Creep due to Stakeholder Discovery

Consultation with the Sponsor and CAB could result in a new Project Charter (thus re-starting the project anew), addressing the changes (as above) or putting the “new” requests into a version series (where the changes will be accomplished in a following project). If the newly-discovered stakeholders are actual users of the product of the project, a total review and update to requirements documents may have to be performed. If the new stakeholder requirements are integrated into the current project, baselines should be reset and the plan managed to the new baselines.

120

Schedule variances (early)

When this does (rarely) occur, check to see if the original estimates were overly pessimistic, the work was under scoped, the resource was more skilled than estimated, and/or if the actual deliverable meets all standards. Sometimes resources complete a deliverable as they understand the scope and quality to be; however, something is missing in their assignment orders or their understanding. In other words, the deliverable may not be complete. Since many organizations favor early over late performance, if the root cause is not remarkable, little intervention may be required in this regard.

Schedule variances (late)

If this situation has occurred, it is important to determine the root cause and see how it can be mitigated in future work. Possibilities to explore are: honest underestimation of the work/duration, the resource was unclear about the deliverable, the resource was not skilled as thought, the activity was not “independent” and other resources were pulled in to assist, and the resource did not have sufficient availability to work at the rate expected, among many others. Mitigation strategies can be fast-tracking, moving discretionary-sequenced activities to parallel; crashing, adding new resources to assist in completing work faster; and scope contraction, taking deliverables out of the scope of the project to ensure timeliness.

Cost variances These can be generated from any of the sources of schedule variance. One specific factor may be price increases or decreases after the baseline has been agreed. Value analysis can be used as a process to determine if there are options of completing work with less expenditure.

121

Closing the Project By definition, a project has a start and an end. Remember – a project is not complete when the final product scope is done – it is complete ONLY when closure is completed.

Enter Phase/Start Project

Closing Processes

Exit Phase/End project

Initiating Processes

Monitoring & Controlling Processes

Planning Processes

Executing Processes

Closing Processes

Project Scope

Complete

Project Terminated

Project Complete

122

Key Elements of Project Closure There are a number of key elements to project closure. The level of detail and sophistication of each depends on the organization’s size and the project’s complexity. Below is a sample Project Closing Checklist: Action Date Confirm that requirements have been met. Obtain formal "sign-off" and final acceptance/ termination from customer.

Make final payments and complete cost records.

Gather final lessons learned. Update project records and corporate documents. Analyze and document effectiveness of the project. Recognize outstanding achievement. Create and distribute a final report of project performance. Index and archive project records. Hand off project deliverables. Release resources. Celebrate!

123

Sample Project Closure Report Outline 1 PROJECT PURPOSE 2 PROJECT GOALS 3 PROJECT SUMMARY

3.1 Project Background Overview 3.2 Project Highlights and Best Practices 3.3 Project Closure Synopsis

4 PROJECT METRICS PERFORMANCE 4.1 Goals and Objectives Performance 4.2 Schedule Performance 4.3 Budget Performance 4.4 Quality Performance 4.5 Metrics Performance Recommendations

5 PROJECT CLOSURE TASKS

5.1 Resource Management 5.2 Issue Management 5.3 Risk Management 5.4 Quality Management 5.5 Communication Management 5.6 Customer Expectation Management 5.7 Asset Management 5.8 Lessons Learned 5.9 Post-Project Tasks 5.10 Project Closure Recommendations

6 PROJECT CLOSURE REPORT APPROVALS 7 APPENDICES 7.1 Project Closure Report Sections Omitted

124

Works Cited

Allen R. Cohen, David Bradford. Influence Without Authority. Hobokey:

Wiley, 2005.

Elder, Richard Paul and Linda. The Miniature Guide to Critical Thinking

Concepts and Tools. NY: Foundation for Critical Thinking Press, 2008.

G. Michael Campbell, PMP and Sunny Baker, Ph.D. The Complete Idiot's

Guide to Project Management. New York: Alpha Books: The Penguin

Group, 2007.

Hurson, Tim. Think Better: An Innovator's Guide to Productive Thinking. New

York: McGraw-Hill, 2007.

Michalko, Michael. "Creative Thinking." Creative Thinking. 2008.

http://www.creativethinking.net (accessed February, Tuesday,

2008).

Neil Browne, Stuart M. Keeley. Asking the Right Questions: A Guide to

Critical Thinking . New York: Prentice Hall, 2006.

Peter M. Senge, Art Kleiner, Charlotte Roberts, Richard B. Ross, and Bryan

J. Smith. The Fifth Discipline Fieldbook: Strategies and Tools for

Building A Learning Organization. New York: Doubleday, 1994.

Project Management Institute. Project Management Institute, A Guide to

the Project Management Body of Knowledge, (PMBOK® Guide) –

Fourth Edition. Newtown Square: Project Management Institute,

Inc., 2008.

Reid, David W. Merrill & Roger H. Personal Styles & Effective Performance.

Florida: CRC Press, 1999.

The Project Management Institute. www.pmi.org. October 25, 2009.

http://www.pmi.org/AboutUs/Pages/Credentials.aspx (accessed

October 25, 2009).

125

Further Reading

Managing Projects Large and Small: The Fundamental Skills for Delivering on Budget and on Time. Boston: Harvard Business School Press, 2004.

Adams, Tammy, Jan Means and Michael S. Spivey. The Project Meeting Facilitator: Facilitation Skills to Make the Most of Project Meetings. San Francisco: Jossey-Bass, 2007.

Carroll, Tim. Project Delivery in Business-as-Usual Organizations. Burlington: Gower, 2006.

Davis, Tony. The Relationship Manager: The Next Generation of Project Management. Burlington: Gower Publishing Company, 2003.

Heerkens, Gary R. Project Management. New York: McGraw-Hill, 2002.

Levine, Harvey A. Practical Project Management: Tips, Tactics, and Tools. New York: John Wiley & Sons Inc., 2002.

Levine, Harvey A. Project Portfolio Management: A Practical Guide to Selecting Projects, Managing Portfolios, and Maximizing Benefits. San Francisco: John Wiley & Sons, 2005.

Lewis, James P. Project Planning, Scheduling and Control: A Hands-On Guide to Bringing Projects in on Time on Budget. 3rd ed. Toronto: McGraw-Hill, 2001.

Loch, Christopher, Arnoud De Meyer and Michael T. Pich. Managing the Unknown: A New Approach to Managing High Uncertainty and Risk in Projects. Hoboken: John Wiley & Sons, 2006.

Wysocki, Robert K. Effective Project Management: Traditional, Agile, Extreme. 5th Edition. Hoboken: John Wiley & Sons, 2009.