1. lecture. introduction to the course information · pdf file1. lecture. introduction to the...

IS PM lectures, 2014 idu3390

© Karin Rava 1

1. Lecture. Introduction to the Course

Topics of Lecture

Concepts regarding project and project management especially information system and its project and management

Look inside reality of IT project management

Goals for the Course and benefits for You

Topics what I plan to cover in following lectures

Information System Definition Information system is a work system what comprises of organizational information and system work with respective IT infrastructure, methods and techniques. A work system is a system in which human participants and/or machines perform work using information, technology, and other resources to produce products and services for internal or external customers.

Information Work

Under information work we can understand processes what organization people perform daily with data and information (procurement, selling, planning etc) and information processing processes supporting IT systems in organization (user support – helpdesk, in ITIL incident, events management etc)

System Work

We can define system work as processes what build or change information and system work processes in organization with respective IT infrastructure, methods and techniques. To these processes belong introduction of development frameworks, methodologies and arrangement of those implementation processes with corresponding resource management processes etc. These processes bound up with organizing and managing of projects. Following picture illustrates information system consisting of information and system work:

Figure 1 Information System Model

Information system in an enterprise must reflect with data all aspects in that enterprise: inputs, outputs and work processes. The overall goal of the information system with its information and system work and corresponding management is to satisfy organizations and its environment needs for quality information and knowledge.


© Karin Rava 2

Project If we wish something purposefully (systematically) achieve, then main method is to use projects. This applies to any kind of problem solving, especially making changes. In the context of enterprise projects are means to implement strategic changes and organize corresponding activities. These activities are not possible to perform in frames of everyday work. In the context of organizations information system projects are means to manage changes concerning organizations information work and system work

Project Definitions

Here are some project definitions from different sources. They are formulated differently, but the meaning is the same:

A temporary organization to which resources are assigned to do work to bring about beneficial change. (The resources may be human, material or financial (J. Rodney Turner)

a work system designed to produce a product and then go out of existence (Steven Alter)

a temporary endeavor undertaken to create a unique product, service, or result (Project Management Institute)

Characteristics of a Project

a project is a temporary endeavor (has definite starting and ending point)

that is progressively (in incremental refinements) planned, controlled, and executed by people,

working within some constraints on resources (time, money, etc),

that results in a unique product, service, or result

that isn’ t possible for the organization to achieve through its normal operations

Comparison of Project Work and Operational (Every Day) Work

This is illustrated in the next table: Tabel 1. Comparison of Project and Operations

Projects Operations

Differences

temporary ongoing

Output: unique Output: repetitive

Purpose: attain its (strategic) objective and then terminate Purpose: sustain the business

Concludes when its specific objectives have been attained Adopt new set of objectives and the work continues

Similarities

Performed by people Performed by people

Constrained by limited resources Constrained by limited resources

Planned, executed, and controlled Planned, executed, and controlled

Information Systems Project

Proposed Definition

A temporary endeavor (organization) designed to give to organization a beneficial information or system work change. Following picture illustrates project as means to manage information systems change:

Figure 2. Project Location in Information Systems Development


© Karin Rava 3

Examples of Information Systems Development Projects

building and introduction of new application systems (software) in organization

modifying already existing application systems in organization

transition to new technologies and business

reorganizing work processes in organization

adjusting and introduction information systems development framework

Changing Information System with Projects when 1 or More Following Criteria are Satisfied:

2 or more people are needed

undertaking needs work coordination from 2 or more departments

must collaborate with outside partners – subcontractors

work is beyond everyday operating scope

requires more than 2 weeks effort or 1 month time usage

includes essential risks

succeed or failure has great impact

includes introduction of new technology

includes creation or change of information system architecture (logical and/or technical) In other situations we can handle information systems change as routine work process

Project Management

Definitions

Here are some definition to project management The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. (PMI) Tools and methods by which the work of the resources assigned to the temporary organization is managed and controlled to deliver the beneficial change desired by the owner.(Turner) Project requirements = beneficial change desired by the owner Project management includes:

planning – planning of temporary organizations work,

organizing – defining resources needed by work,

performance – work assigning to resources

control – performance monitoring, making corrective actions to insure that required outcome (change) is achieved and this is capable to bring benefit to the owner

It includes among other things:

understanding the project

specifying clear and achievable goals

balancing mutually competing requirements related with quality, scope, time and costs

adapting definitions, plans and approaches to meet interests of several stakeholders . This is most difficult part

risk management Project management provides better possibilities to communicate (share information) and adapt to changing circumstances (concerning every aspect in project) Project management part in information systems project expresses following picture:


© Karin Rava 4

Figure 3 Location of Information Systems Project Management

We can consider project management process as one instance of general management process having special methods and techniques inherent only to project management. Following figure gives overview of general management process:

Figure 4. General Management Process

Main Roles or Parties in Project Management

These roles are presented on the following figure:

Figure 5. Main Roles in Project Management

The role of the customer is to give right and complete requirements of desired result to the executor (through project manager); to give appropriate preconditions to fill these requirements and to accept created result. The role of the project manager is to manage executor´s work of fulfilling these requirements under customer´s preconditions. The role of executor is to create the result under given predonditions.


© Karin Rava 5

Project Manager

Project Manager is as manager of little (temporary) company. He is responsive of everything what is needed to be project successful. Project success lies in bringing benefit to the owner. Full success lies in bringing optimal benefit to the owner. Project manager must be capable of listening, producing administrative documents, manage meetings, acquire information, build and hold team performing, communicate and manage his time

Reality Statistics The Standish Group CHAOS Report 2010 (2008 - 2006 - 2004), USA

Successful IT projects – 33% (32% - 35% - 29%)

Challenged projects– 41% (44% - 46% - 53%)

Failed projects – 26% (24% - 19% - 18%) Successful project meets time, scope and costs requirements. In challenged projects, one, two, or all three requirements were not meet. Failed means project was terminated and no results were gained or attained change was not introduced.

Some Failure Reasons

lack of user input

lack of executive support

unclear objectives

project management incompetence

technology incompetence

Some Conclusions

Individuals who participate on projects do not have mutual understanding of to where they must reach and why and how to reach to there. They do not have mutual agreements at all or they are unrealistic and therefore it is not possible to follow them. These agreements are subject to uncontrolled changes

Proposed Solution

Introduce and follow Project management methodologies, standards and best practices. First have healthy mind, logical thinking and willingness and skills to work with people to insure satisfaction of all projects participants. The main goal of project management is doing right projects right!

Information System Project Management Course

Goals are to Give Knowledge

about information systems development project and it management

about initiation and starting a project and associated problems

about project performance and closing and associated problems

about expressing project life cycle in project management tool, especially in MS Project 2007

The Benefit to the Student

The opportunity to increase student’s competency level by creating or enhancing understanding in follows:

What are responsibilities of information systems owner in information system change project

What are responsibilities of project manager in managing information systems change project

What are responsibilities of executor in information system change project

Topics in Lectures

project management frameworks, methodologies, standards

project initiation and justification


© Karin Rava 6

project planning – nature, processes and objects

project performance, tracking, control and project information system

project quality, change and risk management

people management principles, team work and collaboration

project closing

Some Literature

PMI Guide to the Project Management Body of Knowledge (PMBOK® Guide) (5th Edition)

Jolyon E. Hallows, Information Systems Project Management, 2th. Ed., 2005

Albert Lester, Project Management - Planning and Control, 5th Ed, 2007

Editid by: Paul C. Dinsmore, PMP; Jeannette Cabanis-Brewin, The AMA (American Management Association) Handbook of Project Management)

Articles from Internet

Used Literature in the Lecture J. Rodney Turner, Towards a theory of project management: The nature of the project,

http://www.sciencedirect.com/science/article/pii/S0263786305001237

Steven Alter, Work Systems Theory, http://istheory.byu.edu/wiki/Work_systems_theory

David F. Rico, Lean & Agile Project Management for Large Programs & Projects, http://davidfrico.com/rico11a.pdf

Project Vs Operational Work, http://leadershipchamps.wordpress.com/2008/02/19/project-vs-operational-work/

Jolyon E. Hallows: Information Systems Project Management, 2. Ed., http://atoz.ebsco.com/Titles/SearchResults/1201?SearchType=Contains&Find=Information+Systems+Project+Management&GetResourcesBy=QuickSearch&resourceTypeName=booksOnly&resourceType=8%2C9%2C14&radioButtonChanged= (available through TTU network)

PMI Guide to the Project Management Body of Knowledge (PMBOK® Guide) (5th Edition), http://app.knovel.com/hotlink/toc/id:kpGPMBKPM1/guide-project-management/guide-project-management?b-q=PMBOK&b-group-by=true (available through TTU network)

Albert Lester, Project Management - Planning and Control, 5th Ed, 2007, http://app.knovel.com/web/toc.v/cid:kpPMPCE008/viewerType:toc/root_slug:project-management-planning/url_slug:project-management-planning/?

Paul Sanghera: PMP in Depth : Project Management Professional Study Guide for PMP and CAPM Exams, 2006, http://site.ebrary.com/lib/ttul/docDetail.action?docID=10146622

How Projects Really Work (version 1.5), http://www.projectcartoon.com/pdf.php?CartoonID=2&PaperSize=A4

2. Lecture. System and Project Work Approaches

Topics of the lecture

project management vs system engineering methodology

project and project management life cycle

Remark: in lecture notes is used concept “project” instead of “information system project” to emphasize the fact that all

activities concerning project initiation is applicable to any domain project. Particularity to IT project and more

specifically information systems project is in the text highlighted.

http://www.sciencedirect.com/science/article/pii/S0263786305001237

http://istheory.byu.edu/wiki/Work_systems_theory

http://davidfrico.com/rico11a.pdf

http://leadershipchamps.wordpress.com/2008/02/19/project-vs-operational-work/



http://atoz.ebsco.com/Titles/SearchResults/1201?SearchType=Contains&Find=Information+Systems+Project+Management&GetResourcesBy=QuickSearch&resourceTypeName=booksOnly&resourceType=8%2C9%2C14&radioButtonChanged



http://app.knovel.com/hotlink/toc/id:kpGPMBKPM1/guide-project-management/guide-project-management?b-q=PMBOK&b-group-by=true


http://app.knovel.com/web/toc.v/cid:kpPMPCE008/viewerType:toc/root_slug:project-management-planning/url_slug:project-management-planning/

http://app.knovel.com/web/toc.v/cid:kpPMPCE008/viewerType:toc/root_slug:project-management-planning/url_slug:project-management-planning/

http://site.ebrary.com/lib/ttul/docDetail.action?docID=10146622

http://www.projectcartoon.com/pdf.php?CartoonID=2&PaperSize=A4


© Karin Rava 7

(Information) System Development Methodology

Framework is general; methodology is specific giving concrete values to framework elements. Information system

development methodology can be defined as a set of recommended steps, approaches, rules, processes, documents,

control procedures, methods, techniques, and tools for the developers, which covers whole life cycle of an information

system. Defines who, when, what, and why should do during the development of the IS. Methodology covers all

substantial elements of the IS:

People

Organization procedures

Data

SW / HW

Organization influences

Economic aspects of IS development and operation

Documents and control procedures for particular IS development stages

Elements of the framework are effective to all team-based undertakings and are presented on the next figure:

Figure 6. Elements of the Development Framework

Examples of System Development Methodologies:

Waterfall

Spiral

RAD

RUP

XP

Scrum

OpenUP

Kanban System development methodology deals with system and its creation determining principles for system development. Project management methodology deals with work to be done determining management processes for work outputs and outcomes. Project manager is responsible to ensure that project meets its objectives appropriate system development methodology will help it. Project management doesn´t depend on specific system development methodology but may be restricted from it.


© Karin Rava 8

Project Management Framework (PMF)

PMF gives bases for determination of project management methodology and directions to project management activities. Using analogy from Zachman Architecture Framework, PMF is logical structure for categorizing and organizing project management important aspects enabling various parties associated with project to communicate and understand each other. PMF enables get answers to following questions: what? how? where? who? when? why?

While in context of IS project management is directed to IS change management, PMF helps define management aspects

- goals, inputs, outputs and processes for system development and its monitoring and control.

Examples of Project Management Frameworks and Methodologies:

PMI (USA) Project Management Body of Knowledge (PMBOK)

Association for Project Management (UK) BOK

Projects IN a Controlled Environment (UK) (Prince2)

Unified Project Management Methodology (UPMM™)

Project and Project Management Life Cycle Related to project 2 different life cycles exist: project and project management life cycle.

Project Life Cycle Project life cycle defines project start and end and various milestones between them. Project is divided into small time

periods (phases, iterations, sprints etc.) and by the end of each time period project status is checked out and decided to

continue or not. By each time period an outcome (deliverable) is created - “tangible” and verifiable work “product”. It is

input to the next time period or another project or to the custom usage. Chosen system engineering or development

methodology defines project life cycle.

Differences in Project/Product Life Cycle

Differences are presented in the next table. As shown from the table, project is aimed to creation of product (or result)

and after project end product starts its life cycle.

Table 1. Differences in Project and Product Life Cycle

Project Life Cycle Product Life Cycle Owner/Actions

Stage 1 Project conception Product feasibility The client organization, assisted by specialists

Milestone 1

Project commitment High level product requirement produced

The client commits to the project and appoints a project team

Stage 2 Project execution Design, development or acquisition

The project team (the prime contractor assisted by subcontractors)

Milestone 2 Project closure Product created The project team delivers the created product to the client

Stage 3 N/A Product operation The client organization, possibly transferred to a customer/user

Project Management Life Cycle

Project management life cycle is logical sequence of project management processes. One possible example of project

management life cycle is presented on the following figure:


© Karin Rava 9

Figure 7. Project Management Life Cycle

We can divide this life cycle in 4 phases or sub processes:

Starting with the project

Organizing and preparing the project

Performing project work

Closing the project

These 4 phases can be applied to project as a whole or to every smaller time period in project. In PMBOK are these

phases called as process groups consisting of processes. These process groups are:

initiating process group

planning process group

executing process group

monitoring and controlling process group

closing process group

These process groups and mutual relationships are presented on the following figure:

Figure 8. Project Management Process Groups in PMBOK

Every process group is in each project time period more or less repeated, pictorially expressing:


© Karin Rava 10

Figure 9. Iteration of PMBOK Process Groups

In the context of System development / change this principle is illustrated on the next figure:

Figure 10. Iteration of PM Processes in the Context of System Development Life Cycle

One more illustration is presented on the next figure:


© Karin Rava 11

Figure 11. Iterative Nature of Project Management Processes in the Project

Used Literature

System Development Methodology,

http://encyclopedia2.thefreedictionary.com/system+development+methodology

System Development Methodology, http://en.wikipedia.org/wiki/System_development_methodology

P. Fitsilis, Comparing PMBOK and Agile Project Management Software Development Processes,

http://www.springerlink.com/content/j52npr0157v26386/

William J. Brown, Hays W. McCormick III, Scott W. Thomas: Antipatterns in Project Management, 2000

Alistair Cockburn, Methodology per project, http://alistair.cockburn.us/Methodology+per+project

Mike Griffiths, “Agile Suitability Filters”,

http://leadinganswers.typepad.com/leading_answers/files/agile_suitability_filters.pdf

Henrik Kniberg and Mattias Skarin, „Kanban and Scrum – making the most of both“, 2009,

http://www.infoq.com/minibooks/kanban-scrum-minibook

Glen B. Alleman, Agile Project Management Methods for IT Projects,

http://www.niwotridge.com/PDFs/PM%20Chapter%20(short%20no%20email)%20Update%202.pdf

Alistair Cockburn, Methodology per project, http://alistair.cockburn.us/Methodology+per+project

Association for Project Management , http://www.apm.org.uk/

Prince 2, http://en.wikipedia.org/wiki/Prince2

Unified Project Management Methodology, https://www.iil.com/upmm/

PMI Guide to the Project Management Body of Knowledge (PMBOK® Guide) (5th Edition),

http://app.knovel.com/hotlink/toc/id:kpGPMBKPM1/guide-project-management/guide-project-management?b-

q=PMBOK&b-group-by=true (available through TTU network)

Brian Denis Egan, An Introduction to PMI’s Project Management Life Cycle,

http://images.globalknowledge.com/wwwimages/whitepaperpdf/WP2_PMI_LifeCycle_Egan1.pdf

http://encyclopedia2.thefreedictionary.com/system+development+methodology

http://en.wikipedia.org/wiki/System_development_methodology

http://www.infoq.com/author/Henrik-Kniberg-and-Mattias-Skarin

http://leadinganswers.typepad.com/leading_answers/files/agile_suitability_filters.pdf







http://www.infoq.com/minibooks/kanban-scrum-minibook

http://www.niwotridge.com/PDFs/PM%20Chapter%20(short%20no%20email)%20Update%202.pdf

http://alistair.cockburn.us/Methodology+per+project

http://www.apm.org.uk/

http://en.wikipedia.org/wiki/Prince2



http://images.globalknowledge.com/wwwimages/whitepaperpdf/WP2_PMI_LifeCycle_Egan1.pdf


© Karin Rava 12

3. Lecture. Project Initiation

Topics of the current lecture

project initiating in PMBOK

Project Initiation Background In order to explain project initiation context in the organization, I give a short overview of

project connections with implementation of organizations strategic plans;

their location in composition of portfolios and/or programs and

Various stakeholders related to project and its management. Projects are often utilized as a means of achieving an organization’s strategic plan. They are originated when the need

for change in organization is acknowledged. Projects are typically authorized as a result of one or more of the following

strategic considerations:

market demand

strategic opportunity/business need

customer request

technological advance

legal requirements

Projects, within programs or portfolios, are means of achieving organizational goals and objectives (often in the context

of a strategic plan). Although a group of projects within a program can have discrete benefits, they can also contribute:

to the benefits of the program

to the objectives of the portfolio

to the strategic plan of the organization One possible example of relationships between enterprise strategy, architecture and project management is illustrated on the next figure:

Figure 12. Relationships between Enterprise Strategy, Architecture and Project Management


© Karin Rava 13

Project Initiation It is a first phase of projects management life cycle and is a process which starts with idea or proposal to change

implementation (due internal business needs or external factors) and ends in positive case with approval to start

formally with project. In negative case, project will be rejected and will wait better times.

The purpose of the initiation phase of a project is to identify scope and gain initial approval for a project or projects that

will deliver tangible benefit to the business. Once it is approved, it is time to move on to the planning phase of the

project. Initiating is committing the organization’s resources to a project or project phases.

By PMBOK the objective of project initiation is to obtain authorization to start a new project or new phase. This is done

by defining the project or the phase of an existing project. During the initiation following sub processes are performed:

identifying project sponsor

appointing the project manager if no already assigned. The project manager is given the authority to apply organizational resources to the subsequent project activities

defining the project (developing project charter) (substantial initiation sub process) consisting of: o development of clear descriptions of the project objectives, including the reasons why a specific project

is the best alternative to satisfy the requirements o definition of initial scope and committing initial financial resources

identification of internal and external stakeholders who will interact and influence the overall outcome of the project (substantial initiation sub process)

Initiating processes may be performed by organizational, program, or portfolio processes external to the project’s scope

of control (by project initiator or sponsor). The information is captured in the project charter and stakeholder register.

When the project charter is approved, the project becomes officially authorized.

Initiation in the middle of the project is invoking the initiating processes at the start of each project phase. It helps keep

the project focused in the business need the project was undertaken to address. In the middle of the project the success

criteria are verfied, and the influence and objectives of the project stakeholders are reviewed. A decision is then made

as to whether the project should be continued, delayed, or discontinued

Identifying the Project Sponsor

Organizations attempt to accomplish many things at the same time with limited resources. Competing demands make it difficult for project teams to get management attention and commitment of resources needed for their projects to succeed. The role of the project sponsor is to:

Ensure timely decision making Advocate for needed resources Overcome organizational conflicts and barriers to project performance Responsible for appointing and coaching the project manager.

This requires that the sponsor be a member of the top management team of the performing organization with the ability to make key decisions and influence key stakeholder groups. Sub steps of this process are as follows:

Identify the member of management, in the performing organization, with the greatest stake in the project outcome

http://www.pmhut.com/project-management-process-phase-1-initiating-identify-project-sponsor


© Karin Rava 14

Make sure the candidate has a track record of success sponsoring similar projects Check with candidate to ensure availability and commitment to the project Get concurrence among members of the management team Announce sponsorship to key project stakeholders.

Owner of this sub process is corporate governance committee or other corporate/divisional/department management and other resources as necessary.

Appointing the Project Manager

The business partner, other corporate/divisional/department management, and project sponsor will appoint the project manager for the project as the date to start the project draws near. Key considerations in the decision include the candidates’:

technical and integration skills

leadership ability

project management experience

knowledge of the organization

ability to gain the cooperation of key stakeholders The project manager is held accountable for ensuring project success, leading the project team to achieve its objectives, ensuring effective communications with management and other non-project organizations, and ensuring that project problems are identified and resolved in a timely manner. Sub steps are as follows:

determine the qualifications needed to manage the project identify potential candidates that meet the qualifications check for potential availability with candidates’ management (if within the performing organization) evaluate potential candidates based on their suitability check for interest and commitment of the most suitable candidate confirm selection with the candidate’s manager (if within the performing organization) announce project

manager appointment to project stakeholders

In the least effective companies, project manager is assigned at random. The reverse of this is companies that determine

who will be the project manager well in advance, and involve that person in the initial planning and scoping. If the

project arises from a request for proposal, the project manager will be in preparing the proposal and making any

presentations to the client. The effect on project managers is that when a project actually starts, they are familiar with

the background and many of the key players

Substantial Initiation Sub Processes

Substantial sub processes of project initiation are project charter development and identification of internal and

external stakeholders. These processes with according inputs and outputs are presented on the next figure:

http://www.pmhut.com/project-management-process-phase-1-initiating-appoint-project-manager


© Karin Rava 15

Organization Project Initiator or Sponsor Project Manager

Identify

stakeholders

Planning

Processes

Organizational

process

assets

Enterprise

environmental

factors

Project

statement

of work

Business

case

Contract

Procurement

documents

Project

charter

Stakeholder

register

Stakeholder

management

strategy

Develop

project

charter

Figure 13. Project Initiation Processes with Inputs and Outputs

Developing Project Charter

This is the process of developing a document that formally authorizes a project or a phase and documenting initial

requirements that satisfy the stakeholder’s needs and expectations. It establishes a partnership between the performing

organization and the requesting organization (or customer, in the case of external projects). The approved project

charter formally initiates the project. In multiphase projects, this process is used to validate or refine the decisions made

during the previous iteration of “Develop Project Charter”. It is recommended that the project manager participate in

the development of the project charter, as the project charter provides the project manager with the authority to apply

resources to project activities.

Projects are authorized due to the internal business needs or external influences. This usually triggers the creation of a

needs analysis, business case, or description of the situation the project will address. Projects are authorized by

someone external to the project such as a sponsor, PMO, or portfolio steering committee. The project initiator or

sponsor should be at a level that is appropriate to funding the project. They will either create the project charter or

delegate that duty to the project manager. The initiator’s signature on the charter authorizes the project. Chartering a

project links the project to the strategy and ongoing work of the organization.

Inputs for development of project charter are:

Project Statement of Work (SOW) Business Case Contract Enterprise Environmental Factors Organizational Process Assets

Project statement of work is a narrative description of products or services to be delivered by the project. For internal

projects, the project initiator or sponsor provides the SOW based on business needs, product, or service requirements.


© Karin Rava 16

For external projects, the SOW can be received from customer as part of a bid document, for example, request for

proposal, request for information, request for bid, or as part of a contract

Business case provides the necessary information from a business standpoint to determine whether or not the project is

worth the required investment. Typically contains business need and the cost-benefit analysis to justify the project. In

the case of multi-phase projects, the BC may be periodically reviewed to ensure that the project is on track to deliver the

business benefits. In the early stages of the project life cycle, periodic review of the BC by the sponsoring organization

also helps to confirm that the project is still required.

Contract is an input if the project is being done for an external customer

Enterprise environmental factors are as follows:

governmental or industrial standards organization infrastructure marketplace conditions etc

Organizational Process Assets are for example:

organizational standard processes, policies, and standardized process definitions for use in the organization templates historical information and lessons learned knowledge base

The output from developing project charter is project charter what documents the business needs, current

understanding of the customer’s needs and the new product, service, or result that is intended to satisfy. Project charter

can consist of following parts:

project purpose or justification measurable project objectives and related success criteria high-level requirements high-level project description high-level risks summary milestone schedule summary budget project approval requirements (what constitutes project success, who decides the project is successful, and who

signs off on the project) assigned project manager, responsibility, and authority level name and authority of the sponsor or other person(s) authorizing the project charter

Identifying Project Stakeholders

It is the process of identifying all people or organizations impacted by the project, and documenting relevant

information regarding their interests, involvement, and impact on project success. It is critical for project success to

identify the stakeholders early in the project, and analyze their levels of interest, expectations, importance and

influence. A strategy can then be developed for approaching each stakeholder and determining the level and timing of

stakeholder’s involvement to maximize positive influences and mitigate potential negative impacts. The assessment and

corresponding strategy should be periodically reviewed during project execution to adjust for potential changes. These

stakeholders should be classified according to their interest, influence, and involvement in the project. This enables the

project manager to focus on the relationships necessary to ensure the success of the project.


© Karin Rava 17

Inputs for identifying project stakeholders are as follows:

project charter

procurement documents

enterprise environmental factors o organizational or company culture and structure o governmental or industry standards

organizational Process Assets o stakeholder register templates o lessons learned from previous projects o stakeholder registers from previous projects

The outputs from identifying project stakeholders are:

Stakeholder register consisting of following data: o identification information: name, org. position, role in the project, contact information o assessment information - major requirements, main expectations, potential influence in the project,

phase in the life cycle with the most interest o stakeholder classification - internal/external; supporter/neutral/resistor etc

Stakeholder Management Strategy - defines an approach to increase the support and minimize negative impacts of stakeholders throughout the entire project life cycle. Management strategy is generally presented with stakeholder analysis matrix.

One example of the stakeholder management matrix is presented on the next figure:

Figure 14. Stakeholder Analysis Matrix Example

Project Stakeholders

Project stakeholders according PMBOK are presented on the next figure:


© Karin Rava 18

Figure 15. Project Stakeholders

Because of the belonging to constitution of portfolio(s) or program(s) are direct stakeholders correspondingly portfolio

manager and program manager. If in organization exists central project management unit then the stakeholder of the

project can be so called project management office (PMO).

One stakeholder related with project is operational management as beneficiary organization, who orders project

outcome and will use it in everyday operations. Functional managers are those who are related with project by giving

necessary resources to project work. Customers/users are those stakeholders who will directly use the outcome of the

project work. In the context of information systems project these are organizations people or people connected with

organization whose information work will be changed. Sellers/business partners are those stakeholders from whom

some kind of resources (technology, tools) or special services (analysis, testing etc) are bought.

Project management team consists of members of the project team who are directly involved in project management

activities. On some smaller projects, the project management team may include virtually all of the project team

members. One of the project management team members is also the project sponsor.

All mentioned stakeholders are more closely described as follows.

Project sponsor is the person or group that provides the financial resources, in cash or in kind, for project. When project

is first conceived, the sponsor champions the project; gathers support throughout the organization and promotes the

benefits that the project will bring. Sponsor leads the project through the engagement or selection process until formally

authorized and plays significant role in the development of the initial scope and charter. He/she/it may also be involved

in

authorizing changes in scope

phase-end reviews

go/no-go decisions when risks are particularly high Portfolio managers/portfolio review board (steering committee) is responsible for the high-level governance of a collection of projects or programs. Portfolio review boards are committees usually made up of the organization’s


© Karin Rava 19

executives who act as a project selection panel. They review each project for its ROI, the value of the project, risks associated with taking on the project. Program managers are responsible for managing related projects in coordinated way to obtain benefits and control not

available from managing them individually. They interact with each project manager to provide support and guidance on

individual projects

Project Management Office (PMO) is an organizational body or entity assigned various responsibilities related to the centralized and coordinated management of those projects under its domain. It can provide project management support functions or actually be responsible for the direct management of a project:

administrative support services such as policies, methodologies, templates

training, mentoring, and coaching of project managers

project support, guidance, and training on how to manage projects and the use of tools

resource alignment of project staff

centralized communication among project managers, project sponsors, managers, and other stakeholders Functional managers are key individuals who play a management role within an administrative or functional area of the

business - human resources; finance; accounting; procurement. They are assigned their own permanent staff to carry

out the ongoing work. They have a clear directive to manage all tasks within their functional area of responsibility. They

may provide subject matter expertise or their function may provide services to the project

Operations management consists of individuals who have a management role in a core business area - research and

development; design; manufacturing; provisioning, testing, or maintenance. These managers deal directly with

producing and maintaining the saleable products or services of the enterprise. Depending on the type of project, a

formal handoff occurs upon completion to pass technical project documentation into the hands of the appropriate

operations management group. Operations management would then incorporate the handed off project into normal

operations and provider long term support.

Customers/users are persons or organizations that will use the project’s product or service or result

Sellers/business partners. Sellers (vendors, suppliers, or contractors) are external companies that enter into a

contractual agreement to provide components or services necessary for the project. Business partners are also external

companies that provide specialized expertise or fill a specified role - installation, customization, training, or support.

Project Manager´s Tasks in Initiating a New Project

In generally we can divide these tasks in 2 broad categories: understand the project environment and justify it.

Understand Project Environment

Project manager must understand the project environment, background, and people. In other words, he/she must

understand the cultural and political context of project. To manage a project, project manager must understand 4

things:

1. Why is this project being done? What does the client expect to get from it?

2. What is the background to this project? How did we get to where we are?

3. Who are the players? Who has fought for this project? Who has fought against it? Who is the executive

sponsor?


© Karin Rava 20

4. What is the client´s priority for this project?

To understand the background to this project, project manager must ask the following questions:

What were the business conditions that prompted someone to propose the project in the first place?

How was the project presented to management, and how was it evaluated and approved?

What were the alternatives to the project that the client considered?

What were (and are) the arguments against the project?

What is the visibility of the project in the client-s company or department? How important is it seen to be?

What are the attitudes toward the project? Specifically:

o Is it welcomed as desirable, accepted as necessary, or condemned as wrongheaded?

o Is it regarded as easy, difficult, or impossible?

o Is it viewed with enthusiasm, resignation, or trepidation?

With the answers to these questions, project manager is equipped to become an advocate: to sell the project to the

users and to create positive expectations for it. Project manager can now build an atmosphere that will make it easier to

gain cooperation, to resolve issues, and to help the client achieve the expected benefits. Until these questions are

answered, project manager is a passenger, unable to influence, much less dictate, the direction of the project.

Justification and Feasibility

Some project managers will argue that justifying projects is not their concern – that once a project has been approved,

their job is simply to deliver results. But delivering results means ensuring that the client enjoys the benefits used o

justify the project. It also means being able to defend the project against cutbacks and to reevaluate the numbers when

the scope or costs change.

There is only one valid reason to spend money on a project: it will generate or save more money than it costs. The

purpose of a project is a general statement about why the project is being carried out. A purpose statement may be:

“the purpose of this project is to create a state-of-the-art, on-line, real-time inventory system that will allow us to

manage our inventory more closely while continuing to meet the demands of our customers”. This purpose statement is

clear: we are going to build a system that will manage inventory. What it does not tell us is whether the project is

justified – that is, whether it will save or earn more than it will cost.

A justification is an analysis of the costs versus the benefits showing that the benefits are greater. If the analysis shows

that the costs are greater, then it is a justification for scrapping the project, not to proceeding.

A true justification has 2 necessary characteristics: it is dollar quantified, and it is treated as a target or goal.

A project is executed because the client expects some benefit, such as reducing inventory, cutting staff, or increasing

annual sales. The project may be executed perfectly: on time, on budget, and doing what is supposed to. But if the

company does not actually reduce inventory, cut staff, or increase sales at least enough to cover the cost of the project,

then the money the client spent is wasted. But if the client does implement the system and cuts inventory as expected,

it will recover the cost of the overrun. The benefits from a system normally exceed even devastating overruns. The catch

is that the system must be implemented and the benefits realized. Project manager ´s role includes helping the client

realize the benefits that justify the project. Project manager must be as concerned with the delivery of benefits as

he/she is concerned with the delivery of the system.


© Karin Rava 21

Lecture Summary

System engineering (development) methodology defines project life cycle; project management methodology defines

project management processes in project life cycle with their inputs and outputs and usable techniques

Usable system development methodology depends on system nature under development, project criticality and usable

resources (people, money etc.). It is project manager task to agree with stakeholders what kind of project management

and system development methodology to apply.

With project initiation decision is done, to go forward with project or it phase, delay it or not. Project manager must

make clear what is the real benefit to the customer.

Used Literature

Champa Hewagamage, K. P. Hewagamage, Redesigned Framework and Approach for IT Project Management,

http://www.sersc.org/journals/IJSEIA/vol5_no3_2011/8.pdf

Inspired Architecture Frameworks http://www.inspired.org/InspiredFrameworksWhitePaper.pdf




Stakeholder Analysis (Stakeholder Matrix), http://www.dse.vic.gov.au/effective-engagement/toolkit/tool-

stakeholder-analysis-stakeholder-matrix

John F. Filicetti, „Project Management Process“, http://www.pmhut.com/project-management-process (project

initiation part)

Jolyon E. Hallows: Information Systems Project Management, 2. Ed.,

http://atoz.ebsco.com/Titles/SearchResults/1201?SearchType=Contains&Find=Information+Systems+Project+Mana

gement&GetResourcesBy=QuickSearch&resourceTypeName=booksOnly&resourceType=8%2C9%2C14&radioButton

Changed (available through TTU network)

Project initiation document template, http://www.projectmanagementdocs.com/project-initiation-templates.html

Project Initiation Checklists:

o http://office.microsoft.com/en-us/templates/TC011414121033.aspx

o http://dijest.com/tools/pmworkbench/pmtemplates/PICHK.html

o http://www.scribd.com/doc/2218603/Project-Initiation-Checklist-for-Small-Projects

Business Case Templates:

o http://www.ogc.gov.uk/documentation_and_templates_business_case.asp

o www.exinfm.com/project_files/Business_Case_Template.doc

Project Charter Templates:

o http://www.pmhut.com/wp-content/uploads/2008/01/project_charter.pdf

o http://office.microsoft.com/en-us/templates/TC011414181033.aspx

o www.projectinitiation.com/process_assets/Project Charter Template.doc

http://www.sersc.org/journals/IJSEIA/vol5_no3_2011/8.pdf

http://www.inspired.org/InspiredFrameworksWhitePaper.pdf



http://www.dse.vic.gov.au/effective-engagement/toolkit/tool-stakeholder-analysis-stakeholder-matrix

http://www.dse.vic.gov.au/effective-engagement/toolkit/tool-stakeholder-analysis-stakeholder-matrix

http://www.pmhut.com/project-management-process




http://www.projectmanagementdocs.com/project-initiation-templates.html

http://office.microsoft.com/en-us/templates/TC011414121033.aspx

http://dijest.com/tools/pmworkbench/pmtemplates/PICHK.html

http://www.scribd.com/doc/2218603/Project-Initiation-Checklist-for-Small-Projects

http://www.ogc.gov.uk/documentation_and_templates_business_case.asp

http://www.exinfm.com/project_files/Business_Case_Template.doc

http://www.pmhut.com/wp-content/uploads/2008/01/project_charter.pdf

http://office.microsoft.com/en-us/templates/TC011414181033.aspx

http://www.projectinitiation.com/process_assets/Project%20Charter%20Template.doc


© Karin Rava 22

4. Lecture. Project and Scope Planning

Topics of the Lecture

Knowledge areas in PMBOK

Project planning preconditions

Project managers activities before project planning

Project planning processes in PMBOK

Knowledge Areas in PMBOK

PMBOK knowledge areas and their management processes in process groups are presented in the next table (this table

mirrors PMBOK 4.th version knowledge areas, in 5.th version is stakeholder management knowledge area added):

Table 2. PMBOK Knowledge Areas and Their Management Processes

Project Planning Preconditions To start with project planning following preconditions should be met:

Project sponsor is determined and to the project and its manager available;

Project manager is assigned to its role;

Business needs, current understanding of the customer’s needs and the new product, service, or result that is

intended to satisfy are documented in project charter or in some other corresponding document;

Project charter is signed – project is formally authorized;

Project management team (or steering committee) may be assigned. The members of the project team who are

directly involved in project management activities.


© Karin Rava 23

Preparation of Project Planning Preparation of project planning consists of choosing and assigning of project (management) team and holding of project

kick-off meeting. Objectives of this meeting are as follows:

to allow project manager to introduce team members,

to discuss the project overview,

to discuss project roles and responsibilities,

to review any documentation created or collected to date

to identify any training needs

Project Planning Nature and Context

Project planning is in its nature definition of project work and its arrangement (performance/business). In the context of

information system change is project planning organizing of change processes and their control. Project planning

location in project life cycle illustrates the following figure:

Figure 16. Project Planning Context

Project planning is not one-time action, done in the in the beginning of the project, but it is periodically performed

through the entire project. Assuming that project timeline is divided by milestones and phases between them, then in

any time when remained project work must be planned 3 things must be done:

refine validity of commitments agreed in project charter or corresponding document (this activity belongs to

project initiation process preceding planning process);

refine general framework (or roadmap) of remaining project work (major milestones to product owner and how

to reach them);

arrange work of following time period (phase, iteration, spring) taking into consideration the nearest major

milestone to product owner).

Project Planning Processes in PMBOK Are divided in 2 parts:

developing the project management plan

planning processes of concrete aspects (objects, areas) of the project

These processes are required to:

establish the total scope of the effort,

define and refine the objectives, and

develop the course of action required to attain the objectives that the project was undertaken to achieve

Project

initiation

Project

planning

Project

execution

Project

charter

Project plan


© Karin Rava 24

The planning processes develop the project management plan and the project documents that will be used to carry out

the project. The multi-dimensional nature of project management creates repeated feedback loops for additional

analysis – so called „rolling wave planning” indicating that planning and documentation are iterative and ongoing

processes.

Planning processes consist of aspect planning processes and their outputs integration process named “develop project

management plan”. The output from latter process is the project management plan consisting of different project

aspects management plans integrating all aspect management plans into one whole. These plans are presented on the

next figure:

Project Manager

Develop

project

management

plan

Organizational

process

assets

Enterprise

environmental

factors

Procurement

management

plan

Project

scope

statementScope

baseline

Requirements

management

plan

Cost

performance

baseline

Schedule

baseline

Requirements

documentation

Project

management

plan

Quality

management

plan

Human

resource

management

planProcess

improvement

plan

Communications

management

plan

Risk

management

planProject

Charter

Aspects

planning

processes

Figure 17. Project Aspects Management Plans

Aspects planning processes and their relationships are presented on the following figure representing logical sequence:

Figure 18. Planning Processes and Their Relationships


© Karin Rava 25

Develop Project Management Plan

It is the process of documenting the actions necessary to define, prepare, integrate, and coordinate all subsidiary plans.

The project management plan becomes the primary source of information for how the project will be planned,

executed, monitored and controlled, and closed. Inputs for project management plan developing process are:

project charter

outputs from planning processes

enterprise environmental factors

organizational process assets

Corresponding enterprise environmental factors are:

Configuration management system; information collection and distribution system

Organizational structure and culture

Existing facilities

Personnel administration (hiring and firing guidelines etc)

Corresponding organizational process assets are:

Standardized guidelines, work instructions, proposal evaluation criteria, and performance measurement criteria,

Project management plan template — elements of the project management plan that may be updated include,

but are not limited to:

o guidelines and criteria for tailoring the organization’s set of standard processes to satisfy the specific needs

of the project, and

o project closure guidelines or requirements like the product validation and acceptance criteria,

Change control procedures including the steps

o by which official company standards, policies, plans, and procedures, or any project documents will be

modified and

o how any changes will be approved and validated,

Project files from past projects

o (e.g., scope, cost, schedule and performance measurement baselines, project calendars, project schedule

network diagrams, risk registers, planned response actions, and defined risk impact),

Historical information and lessons learned knowledge base

Configuration management knowledge base containing

o the versions and baselines of all official company standards, policies, procedures, and any project

documents.

Project Management Plan

Project management plan integrates and consolidates all of the subsidiary management plans and baselines from the

planning processes and includes but is not limited to:

The life cycle selected for the project and the processes that will be applied to each phase

Results of the tailoring by the project management team

How work will be executed to accomplish the project objectives

A change management plan that documents how changes will be monitored and controlled,

A configuration management plan that documents how configuration management will be performed,


© Karin Rava 26

How integrity of the performance measurement baselines will be maintained,

Need and techniques for communication among stakeholders,

Key management reviews for content, extent, and timing to facilitate addressing open issues and pending

decisions

Results of the tailoring by the project management team are as follows:

Project management processes selected by the project management team

Level of implementation of each selected process

Descriptions of the tools and techniques to be used for accomplishing those processes

How the selected processes will be used to manage the specific project, including the dependencies and

interactions among those processes and the essential inputs and outputs

Project baselines include, but are not limited to:

Schedule baseline

Cost performance baseline

Scope baseline

Often the scope, schedule, and cost baseline will be combined into a performance measurement baseline that is used as

an overall project baseline against which integrated performance can be measured. The performance measurement

baseline is used for earned value measurements.

Project subsidiary plans and documents are presented in the next table:

Table 3. Project Subsidiary Plans and Documents


© Karin Rava 27

Remark! In the table presented plans and documents are not related. These are only presented in sorted way.

Scope Planning Background Project success is determined by its usefulness or profitability:

in increase of revenue

in savings of costs

The main reason to change existent information system is to get more benefits to organization, to help more to achieve

its strategic goals obtainable benefits must be expressed in information system (new, changed) goals. After the project

completion developed information system must meet these requirements what implement information system goals.

Here raises a question: “what are these requirements to what developed information system must meet?” More

precisely:

What are the projects deliverables?

o What kind of must be the constitution of changed (future) information system to achieve goals

expressing information system value?

What customer really wants?


© Karin Rava 28

What are formalities to take into account?

In the context of project management with expected outcome and its requirements deals scope management. In the

context of information system we can take scope as all requirements what developed information system can meet. This

concept is illustrated on the next figure:

Figure 19. Scope Context in the Information System Development

Scope Definition

Scope is the sum of the products, services, and results to be provided as a project (PMBOK). In the context of project

management we must define, write down and get products owner agreement for 2 things:

to “breadth” of expected deliverables – product (hereby system) scope

to “depth” of expected deliverables – project scope

Product scope - the features and functions that characterize a product, service, or result

Project scope - the work that needs to be accomplished to deliver a product, service, or result with the specified

features and functions. Project scope is handled in the following lecture,

Product Scope

In defining scope of project deliverables we must agree with project stakeholders (customer and performer) and write down unambiguously following aspects:

what product, service, or result will do

how the product, service, or result will be used

how the product, service, or result will function

what the product will look like, what the service is, or what the result will be

what impact the product, service, or result will have on the organization, customer, stakeholders, and business processes

any constraints, restrictions, standards, regulations, and other requirements related to the product

Scope of changeable information system– amount of aspects or range of IS architecture (what will be in and out of

borders) affected with change including:

quantity of IS goals

quantity of IS processes

quantity of actors in IS

quantity of functional/non-functional requirements


© Karin Rava 29

quantity of data entities

quantity of locations

Scope Planning Scope planning processes, inputs and outputs are presented on the next figure:

Figure 20. Scope Planning Processes, Inputs and Outputs

Scope planning processes are:

collecting requirements

defining scope

creating work breakdown structure – WBS

In current lecture I describe the first process – collecting requirements. Other processes are subject for following lecture.

Collecting Requirements

Collecting requirements is the process of defining and documenting stakeholders’ needs to meet the project objectives.

The project’s success is directly influenced by the care taken in capturing and managing project and product

requirements. Requirements include the quantified and documented needs and expectations of the sponsor, customer,

and other stakeholders. Collecting requirements is defining and managing customer expectations. Requirements

become the foundation of the WBS, cost, schedule, and quality planning.

Inputs for this process are project charter and stakeholder register and outputs are requirements documentation;

requirements management plan and requirements traceability matrix. Tools and techniques for collecting requirements

are system analysis methods and techniques. Remark: system development methodology used in the project must give

guidelines for requirements collecting, documenting and tracing their life cycle.


© Karin Rava 30

Requirements Documentation

Requirements documentation describes how individual requirements meet the business need for the project.

Requirements may start out at a high level and become progressively more detailed as more is known. Before being

baselined, requirements must be unambiguous (measurable and testable), traceable, complete, consistent, and

acceptable to key stakeholders – SMART. The format of a requirements document may range from a simple document

listing all the requirements categorized by stakeholder and priority, to more elaborate forms containing executive

summary, detailed descriptions, and attachments

Components of Requirements Documentation may be as follows:

Business need or opportunity to be seized, describing the limitations of the current situation and why the project has been undertaken;

Business and project objectives for traceability;

Functional requirements, describing business processes, information, and interaction with the product, as appropriate which can be documented textually in a requirements list, in models, or both;

Non-functional requirements, such as level of service, performance, safety, security, compliance, supportability, retention/purge, etc.;

Quality requirements;

Acceptance criteria;

Business rules stating the guiding principles of the organization;

Impacts to other organizational areas, such as the call center, sales force, technology groups;

Impacts to other entities inside or outside the performing organization;

Support and training requirements;

Requirements assumptions and constraints

Requirements Management Plan

Documents how requirements will be analyzed, documented, and managed throughout the project. Components of the

requirements management plan can include, but are not limited to:

How requirements activities will be planned, tracked, and reported;

Configuration management activities;

Requirements prioritization process;

Product metrics that will be used and the rationale for using them;

Traceability structure - which requirements attributes will be captured on the traceability matrix and to which other project documents requirements will be traced

Requirements Traceability Matrix

A table that links requirements to their origin and traces them throughout the project life cycle. The implementation of

that matrix helps ensure that each requirement adds business value by linking it to the business and project objectives.

It provides a means to track requirements throughout the project life cycle, helping to ensure that requirements

approved in the requirements documentation are delivered at the end of the project. It provides a structure for

managing changes to the product scope

This process includes, but is not limited to tracing:

Requirements to business needs, opportunities, goals, and objectives;

Requirements to project objectives;

Requirements to project scope/WBS deliverables;

Requirements to product design;

Requirements to product development;

Requirements to test strategy and test scenarios; and

High-level requirements to more detailed requirements


© Karin Rava 31

Requirements Attributes

Attributes associated with each requirement can be recorded in the requirements traceability matrix. These attributes

help to define key information about the requirement. Typical attributes used in the requirements traceability matrix

may include: a unique identifier, a textual description of the requirement, the rationale for inclusion, owner, source,

priority, version, current status (such as active, cancelled, deferred, added, approved) and date completed. Additional

attributes to ensure that the requirement has met stakeholders’ satisfaction may include stability, complexity, and

acceptance criteria.

Defining Scope

Defining scope is creating project scope statement. It is a process of developing a detailed description of the project and product. Inputs for this process are project charter, requirements documentation and organization process assets (templates for example). The output of this process is project scope statement. The preparation of a detailed project scope statement is critical to project success and builds upon the major deliverables, assumptions, and constraints that are documented during project initiation. During planning, the project scope is defined and described with greater specificity as more information about the project is known. Existing risks, assumptions, and constraints are analyzed for completeness; additional risks, assumptions, and constraints are added as necessary. If something isn’t described within the detailed project scope statement then the work should not be done or the scope statement needs revised to include the work

Project Scope Statement

Describes, in detail, the project’s deliverables and the work required to create those deliverables; provides a common understanding of the project scope among project stakeholders; may contain explicit scope exclusions that can assist in managing stakeholder expectations; enables the project team to perform more detailed planning, guides the project team’s work during execution, provides the baseline for evaluating whether requests for changes or additional work are contained within or outside the project’s boundaries. The degree and level of detail to which the project scope statement defines the work that will be performed and the work that is excluded can determine how well the project management team can control the overall project scope Project scope statement should consist at least following components (they may be written in separate documents:

Product scope: The characteristics of the product, service, or result for which the project was undertaken. In projects that are part of a larger program, the project itself may only be creating components of the product, but the product scope or product description is still necessary so that everyone knows what the overall objective is.

Project objectives: Objectives are the success metric for the project. Specifically, what will it take for the project to be considered successful? This includes the business, cost, schedule, technical, and quality objectives, and other specific targets should be included where applicable.

Project requirement: The capabilities that the product, service, or result must possess and meet. Requirements are the translated expectations and needs of the stakeholders into prioritized, descriptive requirements and work items.

Project exclusions: Nearly just as import as what IS in the project, the scope should include items that are excluded from the project. Doing this helps eliminate any confusion within the stakeholders or project team.

Project deliverables: The core product, service, or result should be fully described, as well as any ancillary deliverables. Any needed project artifacts, those documents not directly related to the deliverables, such as management, technical, or status reports, should also be described.

Product acceptance criteria: The process and criteria for product acceptance should be defined. This includes customer-specific requirements and any testing or other threshold limits.

Project constraints: Any limiting factors the project must work within, such as deadlines, budget, staffing, facilities, equipment, materials, or contractual restraints, should be described.

Project assumptions: Every project has assumptions, and these should be described because assumptions are risk factors.


© Karin Rava 32

Risks: Risks should be identified at least at a high level. The risk register is where all risks are logged, but having major risks explained in the scope statement helps make everyone aware and on the lookout for them.

Milestones: Any important dates, including deliverable- or artifact-oriented dates should be included in the project scope statement.

Approval requirements: Any specific approval requirements for items such as deliverables, documents, and work should be described.

Creating Work Breakdown Structure

Deliverables-oriented, graphical, hierarchical representation of the work required to fulfill the project scope statement. Purposes:

it subdivides the work into manageable components that can be scheduled, estimated, and assigned

through the process of creating and updating the WBS, it helps to identify needed work that might otherwise not have not been discovered until later

it can be used as a visual communication tool for the customer, stakeholders, and project team

the WBS is an input to activity definition, cost estimating, cost budgeting, resource planning, and risk management planning

Inputs for creating WBS are project scope statement; requirements documentation and organizational process assets (templates). Outputs are WBS, WBS dictionary, scope baseline and project documents updates. Tool and technique for that process is decomposition.

WBS Design Principles

Project scope is divided into manageable components in terms of size, duration, and responsibility (e.g., systems, subsystems, components, tasks, subtasks, and work packages) which include all steps necessary to achieve the objective – result is hierarchy or tree

WBS includes 100% of the work defined by the project scope and captures ALL deliverables – internal, external, interim – in terms of the work to be completed, including project management

The sum of the work at the “child” level must equal 100% of the work represented by the “parent”

WBS should not include any work that falls outside the actual scope of the project, that is, it cannot include more than 100% of the work…

It is important that there is no overlap in scope definition between two elements of a Work Breakdown Structure

Examples of creating WBS structure:

Using phases of the project life cycle as the first level of decomposition, with the product and project deliverables inserted at the second level;

Using major deliverables as the first level of decomposition;

Using subprojects which may be developed by organizations outside the project team, such as contracted work - the seller then develops the supporting contract work breakdown structure as part of the contracted work

Example of WBS pictorially:


© Karin Rava 33

Figure 21. Example of Bicycle Work Breakdown Structure

WBS Dictionary

Provides more detailed descriptions of the components in the WBS, including work packages and control accounts:

Code of account identifier

Description of work

Responsible organization

List of schedule milestones

Associated schedule activities

Resources required

Cost estimates

Quality requirements

Acceptance criteria

Technical references

Contract information

Scope Baseline

A component of the project management plan includes project scope statement; WBS and WBS dictionary.

Additional Material for Scope Planning

From Nick Jenkins “Project Management Primer”:

Scope planning 1. step – requirements gathering

Many projects start up with vague or ill-defined ideas of what they want to achieve. If to hope to deliver a successful

project in a finite amount of time, we must 1. set to project a concrete goal and 2. determine the final state our project

must achieve. If we have an infinite amount of time we can simply try one solution after another until we hit upon the

best solution for our problem. Most of us operate in an environment where we need to deliver a concrete solution in a

very finite period of time. Additionally we must select the best solution from a range of possible approaches. The first

and most important step in this process is defining what will actually constitute a success. Then we can evaluate all of

the possibilities against our definition of success and find the best fit. The more accurate we can be about defining our

objectives; the more likely we will be to succeed.


© Karin Rava 34

Scope is a general term to describe everything that our project encompasses – everything that must be achieved for the

project to be complete. This would encompass projects vision, goals and requirements. These would be embodied in

documents such as a “project proposal” and at a lower level “commercial specifications” and “technical specifications”.

Pictorially expressing:

Figure 1. Vision, goals and requirements related to each other

Project vision is bases for defining project goals. These in turn are as”filters” to determination of requirements

characterizing expected result (solution).

Project Vision

A single encapsulated idea which defines the aim of our project. It should be stated in a single sentence; it should be

inspiring, “visionary”. In additionally it don’t have to be formalized. The only important thing is that every interested

party of project know exactly what the vision is and agree on it. Examples of project visions:

“deliver the cheapest system, in the shortest time, that just about gets the job done” or

“deliver the best sales and marketing system on the market”

Which of these vision statements is inspiring, which of these motivates project team to do their job?

Project Goals

Project goals are slightly lower-level and more specific than the vision. They should directly support the overall vision of

the project but refine its definition. Typically goals are set out by customers or by a business and define how the success

of the project will be achieved.

Project proposal states the highest level goals in a project; it outlines the overall business goals and vision to the project

as decided by the customer or client. It is what gets signed off when a commercial deal is agreed. It may define what we

are legally committed to delivering.

While the vision encompasses the whole project, goals may refer only to the objectives of a particular segment of the

project.

Examples: “the project should deliver the best Customer, Sales and Marketing system on the market, it should:

reduce time taken to process sales orders by 50% (of manual process times)


© Karin Rava 35

provide detailed management reports on a quarterly basis

provide detailed market and customer analysis at request

link sales directly to marketing initiatives to measure marketing ROI

provide detailed client and prospect information to account managers

completely automate license renewals via a website

provide a zero-footprint client, accessible via the Internet

provide an upgrade path for users of other sales order systems” Some goals are more specific than others. More detail is the purpose of requirements specification. The goal is to spend

enough time to make sure project goals are accurate and succinct; it will be the yardstick against which senior

management will judge the success of our project.

Requirements to Expected Solution

One of the primary purposes of goals is to act as a filter for subsequent requirements. If a particular requirement cannot

be traced back through higher-level goals to the overall project vision then it should be dropped since it will be outside

the scope of the project

Requirements specification is the process of refining the goals of a project to decide what must be achieved to satisfy

the “customers”. Generally requirements divide into 2 types: functional and non-functional requirements.

Functional requirement typically states as “the system X must perform function Y”. It asserts or affirms a necessary or

desirable behavior for the system or product in the eyes of an end user.

Non-functional requirement specifies requirement associated with usability, security, performance, reliability etc.

Requirement definition must meet SMART requirements; they must be specific, measurable, achievable, relevant and

testable

Risks Associated with Deliverable Uncertainty

At first sight seems that definition of deliverables is simple. Customer wants amount of models, technological

architecture or application system, which consists of code and documentation. Creating these things may be difficult,

defining these things seems easy. Unfortunately in projects world simplicity leads to abyss. Problems rise from

seemingly safe requirements. For example: “new warehouse system will simplify financial data processing for accounting

system”. This can mean, that …

“new system will output reports where are shown summary data, what must be enter manually to account system” or

“new system will in the end of every month generate data file, which will transported to account system” or

“account systems database will be updated from warehouse system online” Work what must be carried out corresponding these interpretations is different. When project manager plans as

solution reports in the month end, but customer wants online updating, then trouble is in house.

Conclusion: before beginning development work we must understand not only what all these requirements mean, but

also, what customer thinks, what these requirements mean


© Karin Rava 36

Used Literature




Project Management Plan Template, http://www.projectmanagementdocs.com/templates/project-management-

plan.html

Scope Management Plan Template, http://www.projectmanagementdocs.com/project-planning-templates/scope-

management-plan.html

Nick Jenkins: “A Project Management Primer”, http://www.nickjenkins.net/prose/projectPrimer.pdf




Changed

Frank P. Saladis, Harold Kerzner: Bringing the PMBOK Guide to Life. A Companion for the Practicing Project

Manager“, http://www.scribd.com/doc/73643768/Bringing-the-PMBOK-Guide-to-Life-A-Companion-for-the-

Practicing-Project-Manager

Aaron J. Shenhar, “Optimizing Project Success by Matching PM Style with Project Type”,

http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=4e5de42748ff886e16f665baae9824ac?doi=10.1.1.129.31

48&rep=rep1&type=pdf

Mike Griffiths, “PMBOK v4 Process Mappings (large format)”,

http://leadinganswers.typepad.com/leading_answers/pmbok-v4-process-mappings-large-format.html

Scope Planning Templates, http://www.projectmanagementdocs.com/project-planning.html




Changed=

Simon Harris, The Breakdown Structure: 90% of how to manage projects safely,

http://www.asapm.org/asapmag/articles/TheBreakdownStructurePt1.pdf ja

http://www.asapm.org/asapmag/articles/TheBreakdownStructurePt2.pdf

WBS Examples

http://en.wikipedia.org/wiki/Work_breakdown_structure

http://www.pmhut.com/project-management-process-phase-2-planning-develop-project-schedule

WBS Review,

http://cvisn.fmcsa.dot.gov/downdocs/cvisndocs/plan99/2%20Day%200%20Sessions%20for%20update/P2%20Intro

%20to%20WBS%20Development_R26.ppt

5. Lecture. Planning of Project Work In the project context, planning of project work means planning of activities, time usage, required personnel and equipment, technology and costs to implement scope agreed with product owner. In the context of information system development means planning of project work planning of information system change processes and required inputs (resources) to accomplish these processes. Pictorially expressed on the next figure:



http://www.projectmanagementdocs.com/templates/project-management-plan.html

http://www.projectmanagementdocs.com/templates/project-management-plan.html

http://www.projectmanagementdocs.com/project-planning-templates/scope-management-plan.html

http://www.projectmanagementdocs.com/project-planning-templates/scope-management-plan.html

http://www.nickjenkins.net/prose/projectPrimer.pdf




http://www.scribd.com/doc/73643768/Bringing-the-PMBOK-Guide-to-Life-A-Companion-for-the-Practicing-Project-Manager

http://www.scribd.com/doc/73643768/Bringing-the-PMBOK-Guide-to-Life-A-Companion-for-the-Practicing-Project-Manager

http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=4e5de42748ff886e16f665baae9824ac?doi=10.1.1.129.3148&rep=rep1&type=pdf

http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=4e5de42748ff886e16f665baae9824ac?doi=10.1.1.129.3148&rep=rep1&type=pdf

http://leadinganswers.typepad.com/leading_answers/pmbok-v4-process-mappings-large-format.html

http://www.projectmanagementdocs.com/project-planning.html




http://www.asapm.org/asapmag/articles/TheBreakdownStructurePt1.pdf


http://cvisn.fmcsa.dot.gov/downdocs/cvisndocs/plan99/2%20Day%200%20Sessions%20for%20update/P2%20Intro%20to%20WBS%20Development_R26.ppt

http://cvisn.fmcsa.dot.gov/downdocs/cvisndocs/plan99/2%20Day%200%20Sessions%20for%20update/P2%20Intro%20to%20WBS%20Development_R26.ppt


© Karin Rava 37

Figure 22. Planning Project Work in the Context of Information System Development

Project Time (Usage) Planning in PMBOK Putting work on time axis including

1. defining activities 2. sequencing activities 3. estimating activity resources 4. estimating activity durations 5. developing schedule

The basis for time planning: o project scope –

product conceptual design + o requirements for achieving project objectives

work / deliverables breakdown structure

arrangement of work processes o methodology or development strategy

There can be different development strategies to choose amongst:

Incremental: Slow but steady approach (without attempting a leap) in which an already conceived end result is aimed for.

Evolutionary: Slow but steady approach (without attempting a leap) in which there is no pre-conceived end result but each successive design or product is a refinement of the previous one.

Grand design: Total transformation through a right-the-first-time approach.

Step 1 – defining activities

Decomposing the WBS work packages into activities where work packages are evaluated for how they can be broken down into manageable activities. The output of that process is the complete list of project activities - activity list - each activity should have a unique identifier that correlates it to the WBS work package An adequate level of activity decomposition is generally reached when the activities:

are assignable to one person

can have a level of effort determined for them

can have their resource needs estimated

can have their expected costs reasonably established

can have their progress determined and tracked Every activity must be fully described containing:

http://www.businessdictionary.com/definition/end-result.html

http://www.businessdictionary.com/definition/design.html

http://www.businessdictionary.com/definition/product.html

http://www.businessdictionary.com/definition/transformation.html

http://www.businessdictionary.com/definition/right-the-first-time.html


© Karin Rava 38

explanations of any special dependencies or relationships that exist

assumptions that were made

person responsible for the activity

special equipment or materials needed

information specific to the activity that will vary depending upon the project's application area and the type of activity

Activity types categorize how measurable the activity is and how it’s related to the project’s objectives:

discrete effort - a discrete effort activity is one whose work directly relates to a work package or deliverable on the work breakdown structure. These types of activities need to be measurable since they tie directly to the project’s core objectives.

level of effort (or LOE) - is usually an activity performed by a supporting role that is difficult to measure, but is still related to the project’s core objectives.

apportioned effort (or AE) - activity is one which is usually related to project management –it’s necessary for the efficient functioning of the project, but it isn’t directly related to the project’s final product, service, or result.

Another important output of activity definition is the milestone list which provides all significant events and dates on the project. Time periods between milestones are defined as phases or iterations Defining Milestones Milestones provide a very effective method for communicating the schedule progress to stakeholders. They are description of the states of the project at a certain point of time. They can be points at which major deliverables are completed, phases are reached, or other important dates. The last milestone in project is the point where project stakeholders formally decide to accept the ownership of project results Milestone describes what the project should achieve, not how. It should be neutrally formulated with regard to the solution - we must have freedom to choose the activities to reach the desired state, for example: “members have specified knowledge in a stated area” or “members have completed course X” There are major milestones – important events to customer and minor milestones – important events to project team(s) Examples of software development milestones are presented in the following table: Table 2. Example of Milestones in Software Development

Milestone Criteria

Feature freeze The date when all required features are known and the detailed design has uncovered no more. No more features are inserted into the product.

Code freeze Implementation of the design has stopped. Some testing of the features has occurred.

System test freeze Integration testing is complete. Code freeze for system test to start.

Beta ship The date the Beta software ships to Beta customers

Product ship The date the product ships to the general customer base

Defining Phases

The time between two major project milestones, during which a well-defined set of objectives is met and artifacts are completed – group of activities. They provide project stakeholders with the opportunity to make significant decisions about committing resources to the project, one step at a time. Each phase must be concluded with a formal milestone decision - the point at which stakeholders must decide to commit resources to achieve the objectives of the next phase (not the entire project!) Phases in turn are refined in smaller time periods (iterations) having same features than phases.


© Karin Rava 39

Step 2 – sequencing activities

Sequencing activities involves determining the dependencies and relationships between activities and applying leads and lags. The result is a project network - logical structure of successive project activities at the end of what must be achieved certain project objectives/results. Activity sequences are shown through project schedule network diagrams which schematics are showing the order and relationships of project activities. Dependences between activities may be

hard logic – we can perform an activity when preceding activity or activities are finished

related with resources availability – performing an activity is possible when needed resources are available Leads and lags are artificial effects on the timing of activities and are used in conjunction with activity relationships and dependencies. Leads and lags and the reasoning behind their use should be well documented because it may not be obvious to the casual observer why they were established Lags are delays or waiting time between activities - positive time added to an activity's duration Leads speed up activities without changing the relationships between the activities - “negative” time because they allow activities to occur in parallel that would normally be done sequentially

Task Link Types

They are presented in the following table: Table 3. Task Link Types

Name Semantics Pictorially

Finish – to – start (FS) A must finish before B starts

Start – to – start (SS) –

A must start before B can start

Finish – to – finish (FF) A must finish before B can

finish

Start – to – finish (SF) A must start before B can finish

Step 3 - Estimating Activity Resources

Identifying the quantities of resources needed for the project’s activities. Resources are anything having a monetary cost and include materials, equipment, licenses, fees, and personnel needed for the project’s activities. The quantity designations will depend upon the type of resource:

resource quantities for personnel may be expressed in hours, work days, or work weeks

the quantity designations for materials to be consumed will be expressed in whatever unit is applicable (cases, boxes, pounds, tons, kilograms, and so on)

quantity designations for equipment or facilities would likely be expressed as a unit of time (hours, weeks, or months)

Estimating Methods

Top-down estimating form of expert judgment through which an item is looked at broadly and a generalized estimate created


© Karin Rava 40

Bottom-up estimating provides estimates for each component activity, and then aggregates these into an overall estimate

Effort Estimation Methods in the Context of Software System Development

Calculating size - sizing by analogy or sizing by analysis where

sizing by analogy is based on experiences from previous projects.

sizing by analysis - Function Point Counting, Feature Points, Predictive Object Points, Use Case-s, Story Points etc.

Algorithmic software cost estimation model COnstructive COst MOdel (COCOMO) - program size is expressed in estimated thousands of lines of code (KLOC)

Estimating Accuracy

Rough order of magnitude estimate - these are usually top-down estimates made by expert judgment. The variance range for this type of estimate is expected to be -25% to +75% of the final actual figure

Budget estimate - these have less variance than rough order of magnitude, but they are still broad estimates. The variance range for this type of estimate is expected to be -10% to 25% of the final actual figure

Definitive estimate - this type is the most accurate estimate. The variance range for this type of estimate is expected to be -5% to 10%

Step 4 - Estimating Activity Duration

How long the activity will take expressed in a work period (day, hour). Usually number of days where 1 or more resources actually at the activity work The bases for duration estimation are size of effort, number of resources and work hours of every resource per work day

Estimation Methods

Using calculation method: duration = effort size/ resource quantity / resources work hours number per work day, for example: 10 hours effort / 2 people / 2 hours per work day = 2,5

Using PERT (Program Evaluation and Review Technique) method (calculating weighted average duration) - WAE = (OE+4*MLE+PE)/6

Step 5 - Schedule Development

Develop Schedule is the process of analyzing activity sequences, durations, resource requirements, and schedule constraints to create the acceptable (realistic) project schedule. An approved project schedule can serve as a baseline to track progress. Schedule development is an iterative process because project manager must periodically revise this schedule according real life corrections. Inputs for the schedule development are outputs from previous steps (activity definitions, sequencing etc); resource calendars (personnel and equipment availability times for the project; project scope statement; project calendar (available time to completion of project work). Tools and techniques for schedule development are for example:

critical path method

critical chain method

resource leveling

schedule compressing

Critical Path Method

The critical path method calculates the theoretical early start and finish dates, and late start and finish dates, for all activities without regard for any resource limitations, by performing a forward and backward pass analysis through the schedule network


© Karin Rava 41

Critical Chain Method

Critical chain is a schedule network analysis technique that modifi es the project schedule to account for limited resources. Initially, the project schedule network diagram is built using duration estimates with required dependencies and defi ned constraints as inputs. The critical path is then calculated. After the critical path is identifi ed, resource availability is entered and the resource-limited schedule result is determined. The resulting schedule often has an altered critical path. The critical chain method adds duration buffers that are non-work schedule activities to manage uncertainty

Resource Leveling

Resource leveling is a schedule network analysis technique applied to a schedule that has already been analyzed by the critical path method. Resource leveling can be used when shared or critical required resources are only available at certain times, are only available in limited quantities, or to keep resource usage at a constant level. Resource leveling is necessary when resources have been over-allocated, such as when a resource has been assigned to two or more activities during the same time period, when shared or critical required resources are only available at certain times or are only available in limited quantities. Resource leveling can often cause the original critical path to change

Schedule Compression

Schedule compression shortens the project schedule without changing the project scope, to meet schedule constraints, imposed dates, or other schedule objectives

Used Literature

Definition of Development Strategy, http://www.businessdictionary.com/definition/development-strategy.html


http://app.knovel.com/hotlink/toc/id:kpGPMBKPM1/guide-project-management/guide-project-

management?b-q=PMBOK&b-group-by=true (available through TTU network)

John Filicetti. Project Management Process - Phase 2 - Planning - Develop Project Schedule,


Plan and Schedule Development,

http://www.nehimss.org/070518_Project_Management/Chance_Reichel_Templ_TaskID_WBS_05_12_00.doc

COCOMO, http://en.wikipedia.org/wiki/COCOMO or

http://csse.usc.edu/csse/research/COCOMOII/cocomo_main.html

Schedule Management Template, http://www.projectmanagementdocs.com/project-planning-

templates/schedule-management-plan.html

Johanna Rothman, Iterative Software Project Planning and Tracking,

http://www.jrothman.com/Papers/7ICSQ97.html

6. Lecture. Planning of Human Resources Project human resource planning (HRP) is in other words establishing project organization having following objectives to

ensure that:

necessary people are for specific work time available

each work package has an unambiguous owner

each team member has clear understanding of his/her role and responsibility

HRP consists of following steps:

1. defining roles

http://www.businessdictionary.com/definition/development-strategy.html



http://www.pmhut.com/?s=%22John+Filicetti%22


http://www.nehimss.org/070518_Project_Management/Chance_Reichel_Templ_TaskID_WBS_05_12_00.doc

http://en.wikipedia.org/wiki/COCOMO

http://csse.usc.edu/csse/research/COCOMOII/cocomo_main.html

http://www.jrothman.com/Papers/7ICSQ97.html


© Karin Rava 42

2. defining reporting relationships and responsibilities

3. establishing staffing management plan

Step 1 - Defining Roles

With roles are defined responsibilities, inputs and outputs to implement them

Role – set of responsibilities, authorities and competencies Responsibilities – work what is expected from team member to get a result Authority - right to apply project resources, make decisions and sign approvals; right to choose work method, accept quality and respond to project disagreements Competency – skills and capabilities, what are needes to komplete tasks

Roles in Different Methodologies

RUP roles - analysts, developers, testers, managers, others; OpenUP roles - analysts, whatever role, architect, developer, project manager, stakeholder, tester; Scrum roles – product owner, scrum master, scrum team; XP roles - client, tester, programmer, tracker, coach

Project Manager Role in Different Methodologies

In RUP:

acquires resources

sets priorities

coordinates collaboration with project customer and system end users

tries to keep project team on the right course

creates procedures for project outcomes These responsibilities are illustrated on the next figure:

Figure 23. Responsibilities and Activities of Project Manager in RUP


© Karin Rava 43

In OpenUP

Project manager guides team to get successful result and customer to accept product an estimates project risks and controls them through mitigation strategies. Pictorially expressed on the next figure:

Figure 24. Project Manager Roles in OpenUP

Step 2 - Defining of Report Relationships and Responsibilities

Defining of report relationships and responsibilities is in other words putting in place project control and information

flow structure expressed in organization chart. These charts can be:

hierarchical-type charts – show positions and relationships in a graphic, top-down method

matrix-based charts – illustrate the connections between work that needs to be done and project team members

o RAM (Responsibility Assignment Matrix)

o RACI (Responsible, Approve/Accountable, Consult, Inform)

text-oriented formats – detailed description of team member responsibilities, authority, competencies and

qualifications

One example of hierarchical-type chart showing project organizational structure:

Figure 25. Example of Project Organization Structure

One example of responsibility assignment matrix: Table 4. Example of Responsibility Assignment Matrix


© Karin Rava 44

One example of RACI matrix:

Table 5. Example of RACI Matrix

Description of assignment roles:

Responsible

o Individual/s who perform a task/activity; the doer, responsible for action/implementation o The degree of responsibility is defined by the Accountable person o Responsibility can be shared o While Accountability can NOT be delegated, Responsibility can be delegated

Accountable

o The individual who has ultimate accountability and authority o There is only one accountable (A) to each task/activity o Accountability is assigned at the lowest level and implied at higher levels o Accountability cannot be delegated

Consulted

o The individuals to be consulted prior to a final decision or action is taken o Two-way communication

Informed

o The individuals that need to be informed after a decision or action is taken

Considerations about RACI

Accountable

o too many A’s? - Probably a sign of confusion - no one will be sure who really had the task and each individual will probably have a different approach and/or expectation(s).

o multiple “A”ccountable and unrelated resources can cause conflicts in differences of opinion o you should be sure the team members are co-chairs, co-leads, or at least in similar roles and will collaborate

well together. o many A’s - Is this person a bottleneck? Can these tasks be shared or segregated? o multiple A’s should be kept to a minimum or each vertical column should have only ONE Accountable

Responsible

o multiple “R”esponsible can cause unnecessary or duplicate work. o make one team member responsible for each task. o lots of R’s - The individual may have too much to do - can the activities be broken into small sections and

split out to others? o each vertical column should have one Responsible, but can have more in some situations of shared

responsibility. o with no R’s a gap occurs - Is the task being completed? Assign Responsibility.


© Karin Rava 45

Consult

o Form one side multiple “C”onsulted is desirable to collect input from all potential subject matter experts. o From other side - minimize the number of Consults - Make sure the consult is necessary and not just a ‘feel

good’ contact.

Inform

o Keeping multiple people “I”nformed helps develop capacity. o If a team member is absent or unable to carry out work for any reason, you have developed a successor for

that role. o Too many “I”s? Maybe some people only need to be informed if exceptional circumstances occur - Build the

appropriate criteria into the process

In general:

any team member should have only one role;

if any column is empty, consider if that resource is necessary for the project;

no empty spaces in a row - Does this person need to be involved in every step? Try to reduce C’s and I’s First’;

completely empty row - Why was this function included? Are we missing including them when they should be? Can the function be correctly eliminated from the process?

Step 3 - Defining Project Staffing Management Plan

Project staffing management plan describes when and how human resource requirements will be met and includes following consisting of following items:

staff acquisition - how and through what methods the people needed for the project will be acquired, which may include both personnel internal to the performing organization and external to it, such as consultants

resource calendars, timetables, and histograms - information on when resources will be needed and in what durations, shown through calendars, timetables, and histograms

training - formal plan for project team member training, though informal training will also occur

compliance and safety - any measures that will be taken to ensure that any safety, governmental, regulatory, organizational, or contractual obligations are followed that are applicable to human resource requirements

team performance assessments - include any team performance goals, and how the overall performance of the project team will be measured and evaluated

project performance appraisals - include the procedures, methods, and guidelines for the performance appraisal of individual project team members

recognition and rewards - details the approaches that will be taken for promoting and reinforcing desired behavior, including the costs associated with any recognition or reward program

staff release criteria - describes how team members will be released from the project; how payment for work completed will be handled for the departing team member

One example of staffing plan is shown in the next table:

Table 6. Example of Staffing Plan


© Karin Rava 46

One example of resource histogram is presented on the next figure:

Figure 26. Example of Resource Histogram

Limitations in Supplying with Personnel

project member location in main organization

team members preferences for composition, role allocation and fulfillment

dependence of personal skills and capabilities

availability of resources

team communication model conditioned by development methodology Being project team member depends on:

rules, on what projects in main organization are organized

management structure in customer and performer organization

project members subordination relationships in main organization

Management Structure in Organization

Organization management structure is an enterprise environmental factor which can affect the availability of resources

and influence how projects are conducted


© Karin Rava 47

Organizations business can be managed:

without projects - management of everyday life (business) in organization is done with no projects (performing only functions);

with projects - project management services are offered outside the company (IT companies for example) or project services are offered inside the company (IT department for example)

The result of bounding together main organization (customer side) with project organization (customer + project

manager + implementer) we can get functional, projectized, matrix or composed organization.

Functional organization

each employee has one clear superior

is based on departmental, specialty, or business lines, such as accounting, marketing, sales, customer service, information systems, and so on

the scope of the project is usually limited to the boundaries of the function

consultations are held by heads of different departments Pictorially:

Figure 27. Functional Organization

Projectized Organization

team members are often co-located

most of the organization’s resources are involved in project work

project managers have a great deal of independence and authority

projectized organizations often have organizational units called departments, but these groups either report directly to the project manager or provide support services to the various projects

Pictorially:

Figure 28. Projectized Organization


© Karin Rava 48

Matrix Organization

a blend of functional and projectized characteristics

Weak matrices maintain many of the characteristics of a functional organization, and the project manager role is more of a coordinator than that of a true project manager

Strong matrices have many of the characteristics of the projectized organization, and can have full-time project managers with considerable authority and full-time project administrative staff

Balanced matrix organization recognizes the need for a project manager, it does not provide the project manager with the full authority over the project and project funding

Composed Organization

Composed organization involves all previously described structures at various levels, pictorially:

Figure 29. Composed Organization

Determination of Project Manager

Project Manager is determined pending on his/her position in organization:

by resource manager – superior of project manager;

by project sponsor – project initiator;

by project manager him-/herself; Following table shows key project-related characteristics of the major types of organizational structures:

Table 7. Organizational Structure Influences on Projects


© Karin Rava 49

Used Literature


http://app.knovel.com/hotlink/toc/id:kpGPMBKPM1/guide-project-management/guide-project-

management?b-q=PMBOK&b-group-by=true (available through TTU network)

RUP Roles, http://sce.uhcl.edu/helm/rationalunifiedprocess/index.htm

OpenUP Roles, http://www.utm.mx/~caff/doc/OpenUPWeb/openup/rolesets/openup_roles_5CDDEEDA.html

Project Management Advisor , „Develop Project Staffing Plan“, http://pma.doit.wisc.edu/plan/2-2/tools.html

Project Open, „HR Project Staffing“, http://www.project-open.org/documentation/process_hr_project_staffing

Jolyon E. Hallows: Information Systems Project Management, 2. Ed., http://atoz.ebsco.com/Titles/SearchResults/1201?SearchType=Contains&Find=Information+Systems+Project+Management&GetResourcesBy=QuickSearch&resourceTypeName=booksOnly&resourceType=8%2C9%2C14&radioButtonChanged

Doreen Myers, „Project Communications and Human Resource Management, Unit #3 Project Human Resource Planning“, http://www.slideshare.net/Samuel90/slide-presentation-4397626

Ray W. Frohnhoefer, „RACI and RACI-VS“, http://www.pmhut.com/raci-and-raci-vs

Steven Bonacorsi, „RACI Diagram / RACI Matrix - A Complete Definition“, http://www.pmhut.com/raci-diagram-raci-matrix-a-complete-definition

7. Lecture. People Management in Project

Lecture Topics

Team definition and characteristics

Team management processes in PMBOK

Team development model

Leadership principles

Definition of Team A small number of people with complementary skills who are committed to a common purpose, performance goals, and

approach for which they hold themselves mutually accountable

Team Members:

operate with a high degree of interdependence,

share authority and responsibility for self-management,

are accountable for the collective performance, and

work toward a common goal and shared rewards(s). A team becomes more than just a collection of people when a strong sense of mutual commitment creates synergy, thus

generating performance greater than the sum of the performance of its individual members.

The purpose for project manager is to develop an average team to aligned team (by Alistair Cockburn). Pictorially:



http://sce.uhcl.edu/helm/rationalunifiedprocess/index.htm

http://www.utm.mx/~caff/doc/OpenUPWeb/openup/rolesets/openup_roles_5CDDEEDA.html

http://pma.doit.wisc.edu/plan/2-2/tools.html

http://www.project-open.org/documentation/process_hr_project_staffing




http://www.slideshare.net/Samuel90/slide-presentation-4397626

http://www.pmhut.com/raci-and-raci-vs

http://www.pmhut.com/?s=%22Steven+Bonacorsi%22

http://www.pmhut.com/raci-diagram-raci-matrix-a-complete-definition


http://www.businessdictionary.com/definition/operate.html

http://www.businessdictionary.com/definition/high.html

http://www.businessdictionary.com/definition/degree.html

http://www.businessdictionary.com/definition/interdependence.html

http://www.businessdictionary.com/definition/share.html

http://www.businessdictionary.com/definition/authority.html

http://www.businessdictionary.com/definition/responsibility.html

http://www.businessdictionary.com/definition/self-management.html

http://www.businessdictionary.com/definition/accountable.html

http://www.businessdictionary.com/definition/performance.html

http://www.businessdictionary.com/definition/work.html

http://www.businessdictionary.com/definition/common.html

http://www.businessdictionary.com/definition/goal.html


© Karin Rava 50

Figure 30. From Average Team to Aligned Team

Common Problems Teams Must Overcome

When teams fail, it´s usually because of one of five reasons: 1. members don´t understand the team´s mission; 2. members don´t understand their own roles or responsibilities; 3. members don´t understand how to do their tasks or how to work as part of a team; 4. members don´t buy into the team´s function, purpose, or goals; 5. members reject their roles or responsibilities

People Management Failures

Unformed development teams

Lack of clearly defined management roles

Poor motivation and unrealistic expectations

Uncontrolled corncobs and encouragement of heroes

Constant delivery pressure

Adding staff to speed up delivery

Lack of technical respect for developers

Lack of effective communication

Avoidance of Failure or Corrective Actions

Performing team development cycle

Understanding and applying management roles

Understanding and applying leadership principles

People Management Processes in PMBOK In PMBOK they are named „Human Resource Management Processes“ and are as follows:

Acquire Project Team

Develop Project Team

Manage Project Team These processes and mutual relationships by inputs and outputs are presented on the next figure:


© Karin Rava 51

Figure 31. Human Resource Management Processes in PMBOK

Acquire Project Team It is the process of confirming human resource availability and obtaining the team necessary to complete project assignments. The project management team may or may not have direct control over team member selection because of collective bargaining agreements, use of subcontractor personnel, matrix project environment, internal or external reporting relationships, or other various reasons Factors in acquiring project team are as follows:

The project manager or project management team should effectively negotiate and influence others who are in a position to provide the required human resources for the project

Failure to acquire the necessary human resources for the project may affect project schedules, budgets, customer satisfaction, quality, and risks. It could decrease the probability of success and ultimately result in project cancellation

If the human resources are not available due to constraints, economic factors, or previous assignments to other projects, the project manager or project team may be required to assign alternative resources, perhaps with lower competencies, provided there is no violation of legal, regulatory, mandatory, or other specific criteria

Acquire Project Team Inputs

Project management plan;

Enterprise environmental factors (existing information for human resources including who is available, their competency levels, their prior experience, their interest in working on the project and their cost rate; personnel administration policies such as those that affect outsourcing; organizational structure and location or multiple locations);

Organizational process assets (organization standard policies, processes, and procedures)

Acquire Project Team Outputs

Project staff assignments (The documentation of these assignments can include a project team directory, memos to team members, and names inserted into other parts of the project management plan, such as project organization charts and schedules)

Resource calendars (documented time periods showing that each project team member can work on the project)


© Karin Rava 52

Project management plan updates (specifically human resource plan)

Acquire Project Team Tools & Techniques

Pre-assignment

When project team members are selected in advance they are considered pre-assigned. This situation can occur if the project is the result of specific people being promised as part of a competitive proposal, if the project is dependent upon the expertise of particular persons, or if some staff assignments are defined within the project charter

Negotiation

Acquisition

When the performing organization lacks the in-house staff needed to complete a project, the required services may be acquired from outside sources. This can involve hiring individual consultants or subcontracting work to another organization

Develop Project Team Is the process (a process of change) - transforming a group of individuals who may have different interests, backgrounds, and expertise into an integrated and effective working unit and awareness building. It´s helping people to understand that they are greater collectively than individually; it is an understanding that all of our decisions will be better when some degree of collaboration is applied. Develop Project Team is a process which improves the competencies and interactions of team members to enhance project performance. Management of team development process is one of the primary duties for project manager. Project managers should:

create an environment that facilitates teamwork;

continually motivate their team by providing challenges and opportunities, by providing timely feedback and support as needed, and by recognizing and rewarding good performance

High team performance can be achieved by:

using open and effective communication,

developing trust among team members,

managing conflicts in a constructive manner, and

encouraging collaborative problem-solving and decision-making The project manager should request management support and/or influence the appropriate stakeholders to acquire the

resources needed to develop effective project teams.

Objectives of Developing a Project Team

Improve knowledge and skills of team members in order to increase their ability to complete project deliverables, while lowering costs, reducing schedules, and improving quality;

Improve feelings of trust and agreement among team members in order to raise morale, lower conflict, and increase team work; and

Create a dynamic and cohesive team culture to improve both individual and team productivity, team spirit, and cooperation, and to allow cross-training and mentoring between team members to share knowledge and expertise.

Develop Project Team Inputs

Project staff assignments


Resource calendars


© Karin Rava 53

Develop Project Team Outputs

Team perfromance assessments

The performance of a successful team is measured in terms of technical success according to agreed-upon project objectives, performance on project schedule (finished on time), and performance on budget (finished within financial constraints). High-performance teams are characterized by these task-oriented and results-oriented outcomes. They also exhibit specific job-related and people-related qualities that represent indirect measures of project performance

Enterprise environmental factors updates

Develop Project Team Tools & Techniques

Training

Team-building activities

Ground rules (clear expectations regarding acceptable behavior by project team members)

Recognition and rewards

Team Development Model (Team Building Model) B.W. Tuckmann ja M.A.C. Jensen, 1965. Teams are going through 5 phases: Forming; Storming; Norming; Performing; Adjourning

Forming

A stage of transition from individual to a team member. Team members are first brought together and check out the situation. Trying to form group goals and what role everyone plays in it – what is expected from everyone, what are everybody´s gains and losses. People are not committed to the team. Project manager must perform 3 tasks to move the team through this stage: Staff quickly, establish roles, in team meetings explain project background, client information; Share the vision, establish buy-in; Assign short-term deliverable that members have to produce together to monitor members collaboration ability

Storming

A conflict-filled stage in which the individuals try to form a group by resolving differences in goals and perspectives. The individuals struggle for status and power within the team. Member’s competencies are attacked. Cliques drive the team. Level of participation by members is at its highest (for some) and it’s lowest (for some). Project manager must solve conflicts: Support different working styles; Encourage members to mutual communication and collaboration; Create positive environment

Norming

Focus on the work at hand. Power boundaries have been set and trust between members emerges. Personal attacks die down and people adjust for individual strengths and weaknesses. Sometimes issues that should be addressed are avoided. When people overlook a good solution to a problem to avoid conflicts, project manager must reawaken their critical capabilities

Performing

The team has developed a clear identity with loyal team members. They have a clear understanding of how the team operates and how they will interact as individuals. As new tasks arise, each member knows who will complete it. Usually, if someone does forget his or her place, the team itself will discourage the disruptive behavior. Project manager’s day-to-day involvement is minimal. The team will be running itself, and project manager can focus on process improvement, customer relations, improved efficiency, and the like


© Karin Rava 54

Adjouring

Members become concerned about the team´s impending dissolution, and productivity declines. Adjourning includes feelings of loss or sadness about ending the project and separating from the team, as well as strong positive feelings of accomplishment. Behaviors include joking, missing meetings, and expressing dissatisfaction

Development Cycles of Management and Development Teams

Management Team= project manager + development team leaders Table 8 Development Cycles of Management and Development Teams

Management Team Development Teams

Form

Storm

Norm Form

Perform Storm

(Adjourn) Norm

Perform

Adjourn

Overlapping these stages will solve several problems: unformed development teams; lack of clearly defined management roles (and a well-understood decision-making process); uncontrolled Corncobs and encouragement of heroes; lack of technical respect for developers;

Manage Project Team Manage Project Team is the process of tracking team member performance, providing feedback, resolving issues, and managing changes to optimize project performance, The project management team observes team behavior, manages conflict, resolves issues, and appraises team member performance. As a result of managing the project team, change requests are submitted, the human resource plan is updated, issues are resolved, input is provided for performance appraisals, and lessons learned are added to the organization’s database. Managing the project team requires a variety of management skills for fostering teamwork and integrating the efforts of team members to create high-performance teams. Team management involves a combination of skills with special emphasis on communication, conflict management, negotiation, and leadership. Project managers should provide challenging assignments to team members and provide recognition for high performance.

Manage Project Team Inputs



Team performance assessments

Performance reports

Organizational process assets

Manage Project Team Outputs

Change requests

Staffi ng changes can include moving people to different assignments, outsourcing some of the work, and replacing team members who leave. Preventive actions are those that can be developed to reduce the probability and/or impact of


© Karin Rava 55

problems before they occur. These actions may include cross training to reduce problems during absences of project team member and additional role clarification to ensure all responsibilities are fulfilled

Enterprise environmental factors updates

Organizational process assets updates

Manage Project Team Tools & Techniques

Observation and conversation

Project performance appraisals

Clarification of roles and responsibilities, constructive feedback to team members, discovery of unknown or unresolved

issues, development of individual training plans, and the establishment of specific goals for future time periods

Conflict management

Issue log

Interpersonal skills (leadership, influencing, effectice decision making)

Understanding and Implementing Management Roles Meredith Belbin “Management Teams: Why They Succeed or Fail” (1981) 4 critical leadership and 4 critical supporting management roles - that team members seemed to play in the most diversified, successful teams. These leadership roles represent functions needed by a team for peak performance, and they also represent styles in which those leadership functions can be carried out. In management team it is needed that all these roles are present. There should be no reason that most managers’ can´t have multiple roles, as long as the roles are not in tension with each other, as long as they truly have the bandwidth to perform each role sufficiently

Critical Leadership Roles:

Driver - Who sets the strategies;

Originator - Who comes up with innovative approaches;

Coordinator - The process leader and facilitator;

Monitor - The critical reviewer

Critical Supporting Management Roles:

Supporter - who is the people person;

Implementer - responsible for putting strategies, innovative approaches, and processes into practice;

Finisher - provides the urgency necessary and ensures completion;

Investigator - researches and acts as the groups interface externally

Traditional IT Management Roles Mapped to Critical Leadership Roles

Table 9.Traditional IT Management Roles Mapped to Critical Leadership Roles


© Karin Rava 56

Understanding and Implementing Leadership Principles Differentiates between leadership and management: the manager focuses on systems and structure; the leader focuses on people; The manager relies on control; the leader inspires trust; The manager asks how and when; the leader asks what and why; Managers do things right; leaders do the right things.

The Power Bases of the Leader

Leader has several possibilities to establish power – leader´s power base. The power base is the power perceived by the followers of the leader. Understanding the perceived source of power is extremely valuable in understanding how to motivate; similar to means by which leader establishes power, so is the leadership style situational.

P. Hersey & K. H. Blanchard “Management of Organizational Behavior: Utilizing Human Resources”, 1996

Coercive - Power is derived from the perceived ability to provide sanctions or consequences for nonperformance

Connection - Power is derived from association with influential persons or organizations

Reward - Power is derived from the perception to provide compensation for things that followers would like to have

Legitimate - Power is derived from the perception of title or position

Referent - Power is derived from the perception of admiration and personal esteem

Information - Power is derived from the perception of having access to or being in possession of useful information

Expert - Power is derived from perception of education, experience, and expertise

Skills Required to be Successful Leader

Diagnosing - understanding the situation now and what your desired result is for the future

Adapting - adapting and finding the resources to accomplish the desired result

Communicating - interacting effectively with others to achieve the result

Expanded Situational Leadership Model

Authors Paul Hersey and Kenneth Blanchard, in the sixties. The models are based on the premise that there are four different states that followers can exist within, and within each of those states different leadership styles are necessary to achieve the desired result. The essence is that there is no singular way to approach leadership, it depends on the situation. Software project managers should familiarize themselves with this approach to leadership, even if they do not subscribe to it. One possible expression of this model is shown on the next figure:


© Karin Rava 57

Figure 32. Situational Leadership Model

Conflict Management Techniques

Withdrawing/Avoiding. Retreating from an actual or potential confl ict situation

Smoothing/Accommodating. Emphasizing areas of agreement rather than areas of difference

Compromising. Searching for solutions that bring some degree of satisfaction to all parties

Forcing. Pushing one’s viewpoint at the expense of others; offers only win-lose solutions

Collaborating. Incorporating multiple viewpoints and insights from differing perspectives; leads to consensus and commitment.

Confronting/Problem Solving. Treating conflict as a problem to be solved by examining alternatives; requires a give-and-take attitude and open dialogue.

Signs that the Person is not appropriate to be a Project Manager

Poor communicator;


© Karin Rava 58

He/she doesn’t work well with people;

He/she prefers details;

He/she doesn’t like to manage people;

He/she doesn’t like to follow processes;

He/she doesn’t like to document things;

He/she likes to execute and not to plan;

He/she prefers to be an order taker;

He/she is not organized;

He/she thinks project management is “overhead”

Personalities of the Successful Project Manager

Love of their work … and embracing the challenges;

Clear vision … and communicating this vision;

Strong team building skills…and setting positive tones;

Structure and alignment…creating the environment and direction;

Strong interpersonal skills…listening to and leading their teams;

Discipline…completing each phase of the project properly;

Communication skills…knowing when and to whom to communicate;

Summary Success of the collaboration is granted by:

Implementing team development process as well in development team as in management team;

Defining management roles and attributing these to team members;

Understanding leadership principles and implementing these in project according to the situation;

Commitment of every team member and willingness to collaborate

Used Literature Team Definition from Business Dictionary, http://www.businessdictionary.com/definition/team.html

Seven Essential Teamwork Skills, http://www.agileadvice.com/2009/10/12/linkstoagileinfo/seven-essential-teamwork-skills/

Essential Skills for Teamwork, http://bellinghamschools.org/sites/default/files/studentgal/onlineresearch/oldonline/mod8team.htm


William J. Brown, Hays W. McCormick III, Scott W. Thomas “Antipatterns in Project Management”, 2000

Situationl Leadership Theory http://en.wikipedia.org/wiki/Situational_leadership_theory

Larry Davies, Leadership Theories http://eport.stu.edu/blogs/ldavies/archives/2006/05/post_1.html

Situational Leadership Model http://www.12manage.com/methods_blanchard_situational_leadership.html

Paul Hersey, Kenneth Blanchard, Dewey E. Johnson “Management of Organizational Behavior”, 2001

Tom Mochal “10 signs that you aren’t cut out to be a project manager” http://blogs.techrepublic.com.com/10things/?p=233

Jeffrey L. Brewer “Project Managers, Can We Make Them or Just Make Them Better?” http://portal.acm.org/citation.cfm?id=1095754

LING Zong, Ph. D. Advanced IT Project Management, IBM Software Group

Murray R. Cantor: Object-Oriented Project Management with UML, 1998

http://www.agileadvice.com/2009/10/12/linkstoagileinfo/seven-essential-teamwork-skills/

http://www.agileadvice.com/2009/10/12/linkstoagileinfo/seven-essential-teamwork-skills/

http://bellinghamschools.org/sites/default/files/studentgal/onlineresearch/oldonline/mod8team.htm



http://en.wikipedia.org/wiki/Situational_leadership_theory

http://eport.stu.edu/blogs/ldavies/archives/2006/05/post_1.html

http://www.12manage.com/methods_blanchard_situational_leadership.html

http://blogs.techrepublic.com.com/10things/?p=233

http://portal.acm.org/citation.cfm?id=1095754


© Karin Rava 59

8. Lecture Project Communication Planning Communication in its nature is expressing thoughts, emotions, opinions and ideas and carrying these over to other

people. The goal of project communication is to effectively transfer the right amount of information, to the right people,

in the right format, and at the right time

Team communication is important for the following reasons:

project-related information needs to be shared

each member of the team needs to be with the team goal and his/her role in the team

each team member has specific skills and knowledge that must be utilized and imparted to other members in the course of the work

any questions or issues about the project must be broached and shared in order to resolve them

any decisions taken must be imparted to all the members Effective and open communication lines create feelings of trust and of belonging to the team. The more the members

feel valued the more dedicated they are likely to be, and this in turn makes it easier for the team as a whole to achieve

its goals

Results of poor communication between team members

the members may not understand what is needed and may waste time and energy in doing what is not required

the members may misunderstand one another and develop personal - this can affect their desire to work together and thereby the quality of the work.

the members may not be clear of the sequence of the things to be done and this can either hold up the project or play havoc with the deadlines.

the members may not know what to change or how to change to make themselves more efficient

Presumptions of Effective Communication

Information sender’s ability to make itself possibly clear to the receiver

Constant feedback to understand each other on needed extent Pictorially expressing:

Figure 33. Example of Communication Nature

Communication Planning by PMBOK

Communication planning (CP) goals are as follows:


© Karin Rava 60

Respond to the information and communications needs of the stakeholders Raise effectivity and quality of teamwork Share mutual competency in solving problems CP steps are as follows:

Determination of information and communication needs of various stakeholders

o who, what kind, and how much information in what format needs

o when it is needed

o how is this information made available and by whom

Developing communication management plan

Accordingly to communication management plan establishing communication approach (model) and tools to

execute it

CP inputs and outputs are expressed on the next figure:

Figure 34. Project Communication Planning Inputs and Outputs

The output from CP is communication management plan that determines following aspects:

stakeholder communication requirements;

information to be communicated, including language, format, content, and level of detail;

reason for the distribution of that information;

time frame and frequency for the distribution of required information;

person responsible for o communicating the information; o authorizing release of confidential information;

person or groups who will receive the information;

methods or technologies used to convey the information

o memos, e-mail, and/or press releases;

resources allocated for communication activities, including time and budget;

escalation process identifying time frames and the management chain (names) for escalation of issues that cannot be resolved at a lower staff level;

method for updating and refining the communications management plan as the project progresses and develops;

glossary of common terminology;


© Karin Rava 61

flow charts of the information flow in the project, workflows with possible sequence of authorization, list of reports, and meeting plans, etc.;

communication constraints, usually derived from specific legislation or regulation, technology, and organizational policies, etc.

Examples of communication management plan:

Table 10. Example of Communication Plan I

Table 11. Example of Communication Plan II

Communication in Project

Communication in project is bidirectional:

horizontal, that means inside the team or between teams. This kind of communication is concerned with main work,

in given context system development


© Karin Rava 62

vertical, that means between steering committee (system owner or customer) and project manager and between

project manager and project team. This kind of communication handles management of system development, more

specifically resource usage and issues concerning expected deliverables and their development.

The task of project manager is to coordinate bidirectional information exchange “traffic” to confirm that all

stakeholders’ information needs are fulfilled. Pictorially:

Figure 35. General Information Flows in Project

Development information and communication regards system development functions:

system specification

system design

implementation

test

user documentation and training

maintenance

configuration management This kind of information is presented in models, textual descriptions and other like development documents.

Management information by PMBOK is expressed in following table showing different kind of project (management)

documentation:

Table 12. Project Management Documents in PMBOK

Process Group Document Sub Document

Initiating Project charter

Stakeholder register

Planning Scope management plan

Schedule management plan

Cost management plan

Quality management plan


© Karin Rava 63

Process Improvement plan

Human resource management plan

Staffing management plan

Communications management plan

Risk management plan

Procurement management plan

Executing Lessons learned


Resource calendars

Ground rules

Qualified seller list

Bidder conferences

Selected sellers

Procurement contracts

Monitoring & Controlling

Change log

Change requests

Change dispositions

Issue log

Issue dispositions

Forecasts

Performance reports

Work performance information

Work performance measurements

Closing Administrative closure

Contract closures

Communication Planning Tools and Techniques

By PMBOK corresponding tools and techniques are as follows:

communication requirement analysis

communication models

communication methods

communication technology

Communications Requirement Analysis

Communications requirement analysis is based on:

project organization structure and responsibility assignment matrix

information needs of stakeholders associated with project

number of communication channels For number of communication channels following formula: N * (N-1)/2, where N = number of people

Communications complexity rises with increase of channels and therefor rises probability of misunderstanding between project members

Information typically used to determine project communication requirements includes:

organization charts,

project organization and stakeholder responsibility relationships,

disciplines, departments, and specialties involved in the project,


© Karin Rava 64

logistics of how many persons will be involved with the project and at which locations,

internal information needs (e.g., communicating across organizations),

external information needs (e.g., communicating with the media, public, or contractors)

stakeholder information from the stakeholder register and the stakeholder management strategy

Team Communication Models

Project manager can use 3 communication models:

functional communication model

unstructured communication model

product team communication model

Functional Communication Model

Each of the program functions is assigned to a single team: Analysis team, Design team, Implementation team, and so on This sort of organization is common in construction project management and many try to manage software n a similar manner. It is highly structured and formal; each team consists of a separate set of functional specialists. One team completes its work and hands off the project to the next The teams communicate by passing formal documents and other artifacts, such as code and test reports, to the team on the next functional level. The work is managed by controlling the document flow. Each specialist works in isolation and focuses on what he or she does best. Each person in the chain is said to “throw” his or her part of the problem “over the wall” to the next person Functional communications results in too little communication. The lack of communication results in:

less than optimal solutions

no shared responsibility – everyone did his or her job well, yet the result is disappointing

the product is less than the sum of parts

products are not built as designed

the software is hard to maintain or extend

intellectual property is lost

Pictorially expressed:

Figure 36. Functional Communication Model


© Karin Rava 65

Unstructured Communication Model

No defined team structure - everyone is supposed to work together to get the job done It may develop when a team grows from 3 or 4 programmers to a team of 8 or more without anyone addressing the alterations necessary to maintain viable communications or occur when a manager decides to leave the developers alone to do their work. Results in too much communication:

the more people on a project, the less overall productivity (Fred Brooks)

inability to predict or meet schedules

products not designed, resulting in a system that is expensive to maintain or extend Inexperienced, immature development organizations often adopt an unstructured approach. They adopt the idealistic view that a bunch of smart developers “don´t need no stink in´ management”. In previous jobs, they may have been victims of a rigid functional project. In any case, they do not know how else to proceed Pictorially:

Figure 37. Unstructured Communication Model

Product Team Communications Model

The product team consists of overlapping teams that own the various processes. The product team model has its origins in manufacturing development, particularly the Quality Functional Deployment (QFD) movement. These product teams are called Integrated Product Teams or Integrated Process Teams (IPTs). Each team is responsible for a major activity of the development process: one team might be responsible for system design, one for the low-level design and implementation of the subsystems, another for system testing and product delivery. A program team might coordinate all of the project´s activities. Ad hoc teams may be organized to focus on special problems that arise during development. These teams will maintain their membership throughout the project Most project members belong to more than one team - the system architect might lead the design, but also be a member of the system test team IPTs consist of the stakeholders, those who have an interest in the activity, not just the activity owner. The activity owner leads his or her IPT Communication is enhanced by the overlapping membership - the system architect could speak for the intent of the requirements team to the design team. He or she could also bring the concerns of the implementation team to the attention of the requirements team. Pictorially:


© Karin Rava 66

Figure 38. Product Team Communication Model

Communication Methods

Possible communication methods are presented in the next table:

Table 13. Communication Methods

Method Pictorially

1. Interactive communication - synchronous or multidirectional method, for example meetings, instant chats, electronical social messaging, telephone calls, forums, conferences

2. Push communication - no way of immediately giving feedback or seeking clarification, for example e-mails, voice mails, newsletters, memos, reports 3. Pull communication - sender must seek out the information at his or her discretion, for example web sites, intranet repositories, podcasts, project libraries, e-learning materials

Communication Technology

Choice of communication technology is determined by:

temporal requirements of information

availability of technology

technological competency of project members

project duration and environment Project costs are depending on the choice.


© Karin Rava 67

Communication tools enabling collaboration are presenter on the next figure:

Figure 39. Example of Communication Technologies

Used Literature


RUP Roles, http://sce.uhcl.edu/helm/rationalunifiedprocess/index.htm

OpenUP Roles, http://www.utm.mx/~caff/doc/OpenUPWeb/openup/rolesets/openup_roles_5CDDEEDA.html

Project Management Advisor , „Develop Project Staffing Plan“, http://pma.doit.wisc.edu/plan/2-2/tools.html

Project Open, „HR Project Staffing“, http://www.project-open.org/documentation/process_hr_project_staffing

Jolyon E. Hallows: Information Systems Project Management, 2. Ed., http://atoz.ebsco.com/Titles/SearchResults/1201?SearchType=Contains&Find=Information+Systems+Project+Management&GetResourcesBy=QuickSearch&resourceTypeName=booksOnly&resourceType=8%2C9%2C14&radioButtonChanged

Doreen Myers, „Project Communications and Human Resource Management, Unit #3 Project Human Resource Planning“, http://www.slideshare.net/Samuel90/slide-presentation-4397626

Ray W. Frohnhoefer, „RACI and RACI-VS“, http://www.pmhut.com/raci-and-raci-vs

Steven Bonacorsi, „RACI Diagram / RACI Matrix - A Complete Definition“, http://www.pmhut.com/raci-diagram-raci-matrix-a-complete-definition

Communication Model Example, http://www.vtaide.com/lifeskills/verbalC.htm

RUP Artifacts, http://sce.uhcl.edu/helm/rationalunifiedprocess/index.htm

Sonal Panse, „Small Group Communication: Effective Team Communication“, http://www.buzzle.com/articles/small-group-communication-effective-team-communication.html

Murray R. Cantor: Object-Oriented Project Management with UML, 1998

Team Communication, https://wiki.engr.illinois.edu/download/attachments/30806347/Team+Communication.ppt

Communication Management Plan Template by PMBOK, http://www.projectmanagementdocs.com/project-planning-templates/communications-management-plan.html




http://www.utm.mx/~caff/doc/OpenUPWeb/openup/rolesets/openup_roles_5CDDEEDA.html

http://pma.doit.wisc.edu/plan/2-2/tools.html

http://www.project-open.org/documentation/process_hr_project_staffing




http://www.slideshare.net/Samuel90/slide-presentation-4397626

http://www.pmhut.com/raci-and-raci-vs

http://www.pmhut.com/?s=%22Steven+Bonacorsi%22



http://www.vtaide.com/lifeskills/verbalC.htm


http://www.buzzle.com/articles/small-group-communication-effective-team-communication.html

https://wiki.engr.illinois.edu/download/attachments/30806347/Team+Communication.ppt


© Karin Rava 68

9. Lecture. Project Execution, Monitoring and Control Topics of the lecture are:

PDCA cycle

Project execution processes by PMBOK

Project monitoring and controlling processes by PMBOK

Project vital signs

PDCA Cycle Management processes (concerning also projects) are based on PDCA cycle model:

PLAN: design or revise a process to achieve the desired results

DO: implement the plan and measure its performance

CHECK: analyze the metrics and review the results

ACT: decide what changes are needed to improve the process

This cycle is shown on the next figure:

Figure 40.PDCA Cycle

In the context of information system development it means:

planning is design or revise a information system development process to achieve the desired information system

doing is developing information system and measuring its performance

checking is analyzing of metrics and reviewing development results

acting is deciding what changes are needed to improve development process Pictorially expressed on the next figure:


© Karin Rava 69

Figure 41. PDCA Cycle in the Context of Information System Development

Project Execution, Monitoring and Control by PMBOK (according to version 4) PDCA cycle processes are presented also in PMBOK. To planning are corresponding project planning processes (planning process group); to doing are corresponding executing processes (executing processes group); to checking and acting are corresponding monitoring and controlling processes (monitoring and controlling process group). Relationships between these process groups through corresponding inputs and outputs are presented on the next figure. Semantics of abbreviations used on the figure are as follows: PM Plan – project management plan OPA – organizational process assets EEF - enterprise environmental factors WPI – work performance information CR – change request QCM – quality control measurements

Figure 42. Relationships between Project Process Groups

Project execution processes holds in accordance process named “direct and manage project execution”. Monitoring of project performance holds in accordance process named “monitor and control project work”. Changes regarding all manageable aspects in project holds in accordance process named “perform integrated change control”. All these mentioned processes are subject of this lecture.

Project Execution Processes The Executing Process Group consists of those processes performed to complete the work defined in the project management plan to satisfy the project specifications. This Process Group involves coordinating people and resources, as well as integrating and performing the activities of the project in accordance with the project management plan. During project execution, results may require planning updates and re-baselining. This can include changes to expected activity durations, changes in resource productivity and availability, and unanticipated risks. Such variances may affect the project management plan or project documents and may require detailed analysis and development of appropriate project management responses. The results of the analysis can trigger change requests that, if approved, may modify the project management plan or other project documents and possibly require establishing new baselines All execution processes in Project Execution Process Group are presented on the next figure:


© Karin Rava 70

Figure 43. Project Execution Processes

In the centre of these processes is directing and managing project execution. Its responsibility is to ensure that planned work gets done.

Direct and Manage Project Execution

Direct and Manage Project Execution is the process of performing the work defined in the project management plan to achieve the project’s objectives. The project manager, along with the project management team, directs the performance of the planned project activities, and manages the various technical and organizational interfaces that exist within the project. This process is directly affected by the project application area. Deliverables are produced as outputs from processes performed to accomplish the project work planned and scheduled in the project management plan. Work performance information, about the completion status of the deliverables and what has been accomplished, is collected as part of project execution and is fed into the performance reporting process. The work performance information will also be used as an input to the Monitoring and Controlling Process Group. Process activities include, but are not limited to:

perform activities to accomplish project requirements;

create project deliverables;

staff, train, and manage the team members assigned to the project;

obtain, manage, and use resources including materials, tools, equipment, and facilities;

implement the planned methods and standards;

establish and manage project communication channels, both external and internal to the project team;

generate project data, such as cost, schedule, technical and quality progress, and status to facilitate forecasting;

issue change requests and adapt approved changes into the project’s scope, plans, and environment;

manage risks and implement risk response activities;

manage sellers and suppliers; and

collect and document lessons learned, and implement approved process improvement activities Direct and Manage Project Execution also requires implementation of approved changes covering:

Corrective action. Documented direction for executing the project work to bring expected future performance of the project work in line with the project management plan.

Preventive action. A documented direction to perform an activity that can reduce the probability of negative consequences associated with project risks.

Defect repair. The formally documented identification of a defect in a project component with a recommendation to either repair the defect or completely replace the component.

Direct and manage project work process inputs and outputs are presented on the next figure:


© Karin Rava 71

Figure 44. Project Execution Inputs and Outputs

Organizational Process Assets (OPA)

standardized guidelines and work instructions;

communication requirements defining allowed communication media, record retention, and security requirements;

issue and defect management procedures defining issue and defect controls, issue and defect identification and resolution, and action item tracking;

process measurement database used to collect and make available measurement data on processes and products;

project files from prior projects (e.g., scope, cost, schedule, performance measurement baselines, project calendars, project schedule, network diagrams, risk registers, planned response actions, and defined risk impact);

issue and defect management database containing historical issue and defect status, control

information, issue and defect resolution, and action item results

Work Performance Information (WIP)

Gathering and analysis of work performance information is essential to the project management plan and should be considered a priority. Work performance information contributes to the efficient use of resources, identifies potential trouble spots and problems, and serves as an effective project management tool. It is useful as input data for quality control measures and programs. WIP can include following data items:

status information on schedule progress

whether deliverables have been completed, or not

start and finish status of schedule activities

quality standards expectation results

authorized costs vs. costs incurred to date

estimated completion time for scheduled activities in progress

percentage of physical completion of in-progress schedule activities

experience based knowledge acquired, documented, and posted to knowledge base

details of resource utilization

Monitoring and Controlling Processes The Monitoring and Controlling Process Group consists of those processes required to track, review, and regulate the progress and performance of the project; identify any areas in which changes to the plan are required; and initiate the corresponding changes. The key benefit of this Process Group is that project performance is observed and measured regularly and consistently to identify variances from the project management plan. The Monitoring and Controlling Process Group also includes:

controlling changes and recommending preventive action in anticipation of possible problems,

monitoring the ongoing project activities against the project management plan and the project performance baseline, and


© Karin Rava 72

influencing the factors that could circumvent integrated change control so only approved changes are implemented

This continuous monitoring provides the project team insight into the health of the project and identifies any areas requiring additional attention. The Monitoring and Controlling Process Group not only monitors and controls the work being done within a Process Group, but also monitors and controls the entire project effort. In multi-phase projects, the Monitoring and Controlling Process Group coordinates project phases in order to implement corrective or preventive actions to bring the project into compliance with the project management plan. This review can result in recommended and approved updates to the project management plan. For example, a missed activity finish date may require adjustments to the current staffing plan, reliance on overtime, or trade-offs between budget and schedule objectives. Project monitor and control processes are presented on the next figure:

Monitoring and controlling processesDirect and

manage

project

execution

Control

schedule

Control

costs

Control

scope

Administer

procurements Report

performance

Monitor and

control risks

WPI

CR

Deliverables

Perform quality

control

Approved

CR

QCM

WPM

Verify

scope

Validated

deliverables

Performance

reports

Monitor and

control

project work

Perform integrated

change control

Figure 45. Project Monitor and Control Processes

In the centre of project monitor and control are 2 processes: monitor and control project work and perform integrated change control. These processes are mutually related through change request life cycle management. Following monitor and control processes are described more detailed:

Monitor and Control Project Work

Verify Scope

Scope Control

Schedule Control

Cost Control

Report Performance Other monitor and control processes (performing quality and integrated change control) are discussed in separate lectures.

Monitor and Control Project Work

Monitor and Control Project Work is the process of tracking, reviewing, and regulating the progress to meet the performance objectives defined in the project management plan. Monitoring includes status reporting, progress measurement, and forecasting. Performance reports provide information on the project’s performance with regard to scope, schedule, cost, resources, quality, and risk, which can be used as inputs to other processes. Monitor and Control Project Work is the process of tracking, reviewing, and regulating the progress to meet the performance objectives


© Karin Rava 73

defined in the project management plan. Monitoring is an aspect of project management performed throughout the project. Monitoring includes collecting, measuring, and distributing performance information, and assessing measurements and trends to effect process improvements. Continuous monitoring gives the project management team insight into the health of the project, and identifies any areas that may require special attention. Control includes determining corrective or preventive actions or replanning and following up on action plans to determine if the actions taken resolved the performance issue. The Monitor and Control Project Work process is concerned with:

Comparing actual project performance against the project management plan;

Assessing performance to determine whether any corrective or preventive actions are indicated, and then recommending those actions as necessary;

Identifying new risks and analyzing, tracking, and monitoring existing project risks to make sure the risks are identified, their status is reported, and that appropriate risk response plans are being executed;

Maintaining an accurate, timely information base concerning the project’s product(s) and their associated documentation through project completion;

Providing information to support status reporting, progress measurement, and forecasting;

Providing forecasts to update current cost and current schedule information; and

Monitoring implementation of approved changes as they occur. Inputs and outputs of this process are presented on the following figure:

Figure 46. Project Work Monitor and Control Inputs and Outputs

Relationships with other processes are shown on the next figure:


© Karin Rava 74

Figure 47. Monitor and Control of Project Work Process Relationships to Other Processes

This subject will be covered more detailed in a separate lecture.

Performance Reports

Reports should be prepared by the project team detailing activities, accomplishments, milestones, identified issues, and

problems. Performance reports can be used to report the key information including, but not limited to:

current status

significant accomplishments for the period

scheduled activities

forecasts

issues

Organization Process Assets

Available organizational process assets for monitoring and control of project work can be as follows:

organization communication requirements,

financial controls procedures (e.g., time reporting, accounting codes, expenditure and disbursement reviews, and standard contract provisions)

issue and defect management procedures

risk control procedures including risk categories, probability definition and impact, and probability and impact matrix,

process measurement database used to make available measurement data on processes and products

lessons learned database

Verifying Scope

Verifying scope is the process of formalizing acceptance of the completed project deliverables. It includes reviewing deliverables with the customer or sponsor to ensure that they are completed satisfactorily and obtaining formal acceptance of deliverables by the customer or sponsor. Scope verification differs from quality control in that scope verification is primarily concerned with acceptance of the deliverables, while quality control is primarily concerned with correctness of the deliverables and meeting the quality requirements specified for the deliverables


© Karin Rava 75

Scope verification process inputs and outputs are presented on the following figure:

Figure 48. Scope Verification Inputs and Outputs

Main inputs to the process are validated deliverables that have been completed and checked by quality control process. Main outputs from scope verification are in positiive case by the customer or sponsor accepted deliverables; in negative case not accepted delievrables with documented reasons for non-acceptance. Those deliverables require a change request for defekt repair.

Control Scope

Control Scope is the process of monitoring the status of the project and product scope and managing hanges to the scope baseline. Controlling the project scope ensures all requested changes and recommended corrective or preventive actions are processed through the Perform Integrated Change Control process. Project scope control is also used to manage the actual changes when they occur and is integrated with the other control processes Control scope process inputs and outputs are presented on the following figure:

Figure 49. Scope Control Inputs and Outputs

WPI (Work Performance Information) is information about project progress, such as which deliverables have started, their progress and which deliverables have finished. WPM (Work Performance Measurements) can include planned vs. actual technical performance or other scope performance measurements. This information is documented and communicated to stakeholders. CR (Change Request) – to the scope baseline or ohter components of the project management plan. Change requests can include preventive or corrective actions or defect repairs. Change requests are processed for review and disposition according to the Perform Integrated Change Control process. Control scope tool and technique is variance analysis. Project performance measurements are used to assess the magnitude of variation from the original scope baseline. Important aspects of project scope control include determining the cause and degree of variance relative to the scope baseline and deciding whether corrective or preventive action is required


© Karin Rava 76

Control Schedule

Control Schedule is the process of monitoring the status of the project to update project progress and manage changes to the schedule baseline. Schedule control is concerned with:

Determining the current status of the project schedule,

Influencing the factors that create schedule changes,

Determining that the project schedule has changed, and

Managing the actual changes as they occur. Control schedule process inputs and outputs are presented on the following figure:

Figure 50. Control Schedule Inputs and Outputs

WPI is Information about project progress, such as which activities have started, their progress, and which activities have fi nished. WPM are the calculated SV and SPI values for WBS components, in particular the work packages and control accounts, are documented and communicated to stakeholders. Control schedule tools and techniques are:

Performance reviews what measure, compare, and analyze schedule performance such as actual start and finish dates, percent complete, and remaining duration for work in progress.

Variance analysis where Schedule performance measurements (SV, SPI) are used to assess the magnitude of variation to the original schedule baseline. The total float variance is also an essential planning component to evaluate project time performance. Important aspects of project schedule control include determining the cause and degree of variance relative to the schedule baseline and deciding whether corrective or preventive action is required.

Adjusting Leads and Lags is used to find ways to bring project activities that are behind into alignment with plan.

Schedule Compressing techniques to find ways to bring project activities that are behind into alignment with the plan

Control Cost

Control Costs is the process of monitoring the status of the project to update the project budget and managing changes to the cost baseline. Updating the budget involves recording actual costs spent to date. Any increase to the authorized budget can only be approved through the Perform Integrated Change Control process. Monitoring the expenditure of funds without regard to the value of work being accomplished for such expenditures has little value to the project other than to allow the project team to stay within the authorized funding. Thus much of the effort of cost control involves analyzing the relationship between the consumption of project funds to the physical work being accomplished for such expenditures. The key to effective cost control is the management of the approved cost performance baseline and the changes to that baseline. Project cost control includes:

Influencing the factors that create changes to the authorized cost baseline,

Ensuring that all change requests are acted on in a timely manner,

Managing the actual changes when and as they occur,

Ensuring that cost expenditures do not exceed the authorized funding, by period and in total for the project,


© Karin Rava 77

Monitoring cost performance to isolate and understand variances from the approved cost baseline,

Monitoring work performance against funds expended,

Preventing unapproved changes from being included in the reported cost or resource usage,

Informing appropriate stakeholders of all approved changes and associated cost, and

Acting to bring expected cost overruns within acceptable limits. Control schedule process inputs and outputs are presented on the following figure:

Figure 51. Control Costs Inputs and Outputs

Work performance information includes information about project progress, such as which deliverables have started, their progress and which deliverables have fi nished. Information also includes costs that have been authorized and incurred, and estimates for completing project work. Work Performance Measurements are the calculated CV, SV, CPI, and SPI values for WBS components, in particular the work packages and control accounts. They are documented and communicated to stakeholders. Control costs main method is earned value management (EVM) to measure performance. It integrates project scope, cost, and schedule measures to help the project management team assess and measure project performance and progress. It is a project management technique that requires the formation of an integrated baseline against which performance can be measured for the duration of the project. EVM develops and monitors three key dimensions for each work package and control account:

Planned value (PV) is the authorized budget assigned to the work to be accomplished for an activity or work breakdown structure component. It includes the detailed authorized work, plus the budget for such authorized work, allocated by phase over the life of the project. The total planned value for the project is also known as Budget At Completion (BAC).

Earned value (EV) is the value of work performed expressed in terms of the approved budget assigned to that work for an activity or work breakdown structure component. It is the authorized work that has been completed, plus the authorized budget for such completed work. Project managers monitor EV, both incrementally to determine current status and cumulatively to determine the long-term performance trends.

Actual cost (AC) is the total cost actually incurred and recorded in accomplishing work performed for an activity or work breakdown structure component. It is the total cost incurred in accomplishing the work that the EV measured. The AC has to correspond in definition to whatever was budgeted for in the PV and measured in the EV (e.g., direct hours only, direct costs only, or all costs including indirect costs).

Variances from the approved baseline will also be monitored:

Schedule variance (SV) is a measure of schedule performance on a project. It is equal to the earned value (EV) minus the planned value (PV). The EVM schedule variance is a useful metric in that it can indicate a project falling behind its baseline schedule. The EVM schedule variance will ultimately equal zero when the project is completed because all of the planned values will have been earned. Equation: SV = EV – PV.


© Karin Rava 78

Cost variance (CV) is a measure of cost performance on a project. It is equal to the earned value (EV) minus the actual costs (AC). The cost variance at the end of the project will be the difference between the budget at completion (BAC) and the actual amount spent. The EVM CV is particularly critical because it indicates the relationship of physical performance to the costs spent. Any negative EVM CV is often non-recoverable to the project. Equation: CV= EV – AC.

The SV and CV values can be converted to effi ciency indicators to refl ect the cost and Schedule performance of any project for comparison against all other projects or within a portfolio of projects. The variances and indices are useful for determining project status and providing a basis for estimating project cost and schedule outcome.

The schedule performance index (SPI) is a measure of progress achieved compared to progress planned on a project. It is sometimes used in conjunction with the cost performance index (CPI) to forecast the final project completion estimates. An SPI value less than 1.0 indicates less work was completed than was planned. An SPI greater than 1.0 indicates that more work was completed than was planned. Since the SPI measures all project work, the performance on the critical path must also be analyzed to determine whether the project will finish ahead of or behind its planned finish date. The SPI is equal to the ratio of the EV to the PV. Equation: SPI = EV/PV.

The cost performance index (CPI) is a measure of the value of work completed compared to the actual cost or progress made on the project. It is considered the most critical EVM metric and measures the cost efficiency for the work completed. A CPI value less than 1.0 indicates a cost overrun for work completed. A CPI value greater than 1.0 indicates a cost underrun of performance to date. The CPI is equal to the ratio of the EV to the AC. Equation: CPI = EV/AC.

Report Performance

Report Performance is the process of collecting and distributing performance information, including status reports, progress measurements, and forecasts. The performance reporting process involves the periodic collection and analysis of baseline versus actual data to understand and communicate the project progress and performance as well as to forecast the project results. Report performance process inputs and outputs are presented on the following figure:

Figure 52. Report performance Inputs and Outputs

Performance reports are issued periodically and their format may range from a simple status report to more elaborate reports. A simple status report might show only performance information such as percent complete, or status dashboards for each area (e.g., scope, schedule, cost, and quality). More elaborate reports may include:

Analysis of past performance,

Current status of risks and issues,

Work completed during the reporting period,

Work to be completed during the next reporting period,

Summary of changes approved in the period,

Results of variance analysis,

Forecasted project completion (including time and cost), and

Other relevant information to be reviewed and discussed.


© Karin Rava 79

For summary purposes all executing, monitoring and controlling processes are presented in the following table:

Table 14.Executing & Monitoring & Controlling Processes over Aspects

Management aspect Executing processes Monitoring & controlling processes

Integration Direct and Manage Project Execution Monitor and Control Project Work Perform Integrated Change Control

Scope Verify Scope Control Scope

Time Control Schedule

Cost Control Costs

Quality Quality Assurance Quality Control

Human Resource Acquire Project Team Develop Project Team Manage Project Team

Communications Distribute Information Manage Stakeholder Expectations

Report Performance

Risks Monitor and Control Risks

Procurement Conduct Procurements Administer Procurements

Project Vital Signs

Comprehensive method for monitoring, reporting, and taking timely actions to correct problems during IT project. By Gopal K. Kapur - ProjectHALT Methodology These vital signs are following:

Status of the Critical Path

Mileston Hit Rate

Deliverable Hit Rate

Issues

Cost-to-Date vs. Estimated Cost-to-Date

Actual Resources vs. Planned Resources

High Probability, High Impact Risk Events

General Disposition of the Team

Sponsor's Commitment and Time

Status of the Critical Path

Communicates whether the project is on schedule, ahead of schedule, or behind of it. Delay, what is:

< 10% - a fairly normal fluctuation from the norm and can usually be recovered with strong guidance from the

project manager and focused by the team

10% - 20% - problems resulting in the breach of the critical path are beyond the control of the team, and the

project manager and the sponsor need to make sure the team has a viable plan to recover the delay


© Karin Rava 80

> 20% - extremely difficult to recover from such delays without compromising the other 3 key components of

the project – scope (functionality), budget, and quality. Unless the underlying problems are corrected, the

project is sure to continue on its downward slide

Milestone Hit Rate

Indicates the number of milestones the team was planning to hit and the number of milestones they actualy hit during a

specific reporting period

Methodology authors recommend 2 separate monitoring cycles:

To-date performance - the total number of milestones planned to be hit vs. The total number of milestones

actually hit

A shorter monitoring cycle - every 2 weeks: the total number of milestones planned to be hit vs. The total

number of milestones actually hit

The to-date hit rate tells of the overall speed and progress of the team, and the shorter monitoring cycle indicates the

team´s recent progress

A gap of 10% to 20% - the team is beginning to fall. Project manager need to review the situation, devise a plan

for recovery, and work with the team to ensure it begins to increase its milestone hit rate

> 20% - there is little progress on the project, the team is barely crawling, it has lost its focus and momentum.

This type of slow down is sure to result in considerable delay in the currently promised delivery date of the

project

Deliverable Hit Rate

Deliverables tell us about team´s accomplishments. It is important to monitor the team´s accomplishments in terms of

deliverables planned for completion versus the number of deliverables actually completed. The failure of the team to

maintain a consistent deliverable hit rate suggests that there are deep rooted issues that need to be resolved

2 separate monitoring cycles:

To-date performance: the total number of deliverables planned to be completed to-date vs. The total number of

deliverables actually completed

A shorter monitoring cycle – every 4 weeks: the total number of deliverables planned to be completed vs. The

total number of deliverables actually completed

The to-date completion rate of deliverables tells about the rate of the “build” of the project, and the shorter monitoring

cycle indicates the ongoing progress

The total number of deliverables planned to be completed vs. The total number of deliverables actually completed, what

has/is:

A gap of 10% to 20% - some of the team members are encountering obstacles which are keeping them form

finishing their deliverables. Critical path will soon be breached

> 20% - too many delievrables are remain incomplete or have not yet been started. This could be due to such

problems as shortage of resources, lack of appropriate skills, poor specifications, ad hoc change management

process, or discovery of new functionality

Cost-to-Date vs. Estimated Cost-to-Date

As the project proceeds down its development path, it is imperative that the actual cost-to-date be compared to the

estimated cost. Project manager must carefully monitor any overspending

If the actual cost-to-date is:

Between 10% to 20% higher than the estimated cost-to-date


© Karin Rava 81

o The return on investment (ROI) will be affected

o The benefit to the bottom line will be considerably less than what was promised to the client at the time

of original estimates

> 20% higher than estimated cost

o The projects actual cost is running at a rate that may fail to return any financial benefits at all

For organizations that do not monitor the total cost, emthodology authors suggest capturing Effort-to-Date vs.

Estimated Effort-to-Date

If the actual effort-to-date is:

Between 10% to 20% higher than the estimated effort-to-date

o Original estimates were too optimistic, or

o The team members are discovering complexities they had not forecast at the start of the project, or

o Work environment is not very productive and too much time is being lost due to interruptions, or

o Scope creep

> 20% higher than estimated effort

o Any return on investment promised to management at the time of project approval is breached

o Overtime by the project team is present; excessive overtime, in turn leads to eventual low productivity

and low quality of the end product as well team burnout

Actual Resources vs. Planned Resources

There are 2 measurements of resources

The gap between the number of full time equivalent (FTE) team members actually working on the project vs.

The number of FTE team members initially planned

The amount of unplanned turnover – the number of FTE team members that have left the team unexpectedly

The gap of less than 10% - If short term, usually does not result in any appreciable hit on schedule, functionality, or

quality of the end product

If the project is under resourced by 10 to15% - serious hit on the quality of the end product, as there will be a little less

testing, a little less documentation, and little less prototyping as planned

A resource gap > 15 % - in addition to a hit on the quality of the product, there will be a hit on the scope of the project:

client does not get what was promised

A resource gap > 20 % - SOS – the schedule, scope, and quality of the project are all in jeopardy

Unplanned staff turnover

Based on 41 medium to large projects

Unplanned turnover of a core team member causes the critical path to slip behind schedule by 4 to 6 weeks

Unplanned turnover of a project manager delays a project by 6 to 9 weeks

The change of a sponsor jeopardizes the entire project, as a new sponsor often wants to re-approve the projects

budget, schedule, and mission

Project health report card

Table 15. Project Vital Signs

Vital Sign Variance Value

1. Status of the Critical Path (Delay) ‹10% 0

10% to 20% 1

›20% 2


© Karin Rava 82

2. Milestone Hit Rate (Gap) ‹10% 0

10% to 20% 1

›20% 2

3. Deliverable Hit Rate (Gap) ‹10% 0

10% to 20% 2

›20% 4

4. Issues No Issues 0

Issues ‹ Deliv. 1

Issues › Deliv. 2

5. Cost-to-Date vs. Estimated Cost-to-Date (Higher)

‹10% 0

10% to 20% 1

›20% 2

6. Actual Resources vs. Planned Resources (Shortage)

‹10% 0

10% to 15% 2

›15% 4

7. High Probability, High Impact Risk Events 1-3 Risks 1

4-5 Risks 3

6-7 Risks 4

Assessment: 1-5 Green; 6-10 Yellow; 11-20 Red Total

Summary One thing is plan, another thing is acting according to that plan. To ensure that project is under control, project manager must have overview of what is happening and knowledge about what should be happening. Project manager must track “signs” of projects health or powerlessness and have knowledge and wisdom to act respectively.

Used Literature

PDCA cycle, http://en.wikipedia.org/wiki/PDCA


ProjectHALT Methodology, http://www.center4pm.com/ProjectHALTt.pdf

Work Performance Information, http://project-management-knowledge.com/definitions/w/work-performance-information/

10. Lecture. Project Configuration and Change Management

Lecture Topics

Project configuration management

Change control and corresponding system

Project change management in PMBOK

http://en.wikipedia.org/wiki/PDCA



http://www.center4pm.com/ProjectHALTt.pdf

http://project-management-knowledge.com/definitions/w/work-performance-information/

http://project-management-knowledge.com/definitions/w/work-performance-information/


© Karin Rava 83

Project change management in RUP

Project Configuration Management Project configuration management is one part of project management and deals with management of project configuration lifecycle. Configuration Management ensures that the products and their descriptions are correct and complete. It concentrates on the management of technology by identifying and controlling the functional and physical design characteristics of products. It can also be used to track product specifications, processes, policies, and procedures, providing an approval mechanism for changes to them. Configuration management specialists identify and document configuration requirements, control changes, record and report changes, and audit the products to verify conformance to requirements

Change Control and System Change control and system (CCS) is a component of configuration management system. CCS is focused on changes that directly impact the project management plan: scope, schedule, budget, cost, quality, risk, and procurement management plans. It provides a mechanism to make sure that needed changes don´t overwhelm the project and that they´re properly managed by:

identifying and logging all request for changes

analyzing, evaluating, and documenting the impacts that the required changes will have throughout the project

defining a method for the formal review, make-up of the change control board, and decision-making authority of changes

ensuring that communication is thorough and complete about all changes to the stakeholders and project team CCS is defined also as a formal, documented process that describes when and how official project documents and work may be hanged. It describes who is authorized to make changes and how to make them. Is connected to change control board (CCB), configuration management, and a process for communicating changes. An example of Integrated Change Control Process is presented on the following figure:

Figure 53. Example of Change Control Process

Changes Categorization

Changes are generally of 2 types:


© Karin Rava 84

any proposed deviation from any part of the project management plan or

any alteration to specifications, processes, and procedures If an adjustment or correction is needed to the scope, schedule, activities, efforts, costs, budget, quality, staffing, risk components, resources, or contracts then that change will impact the project management plan which, if unmanaged can disrupt the project plan and work being done. Change can occur as a result in a modification to specifications of the product or a process involved in creating the deliverables if unmanaged, these changes can introduce ripple effects that go unnoticed until suddenly they result in mayhem Change Aspects in the Project Context are presented on the following figure:

Figure 54. Change aspects in the project context

Sources of the Change

Changes are necessary in order for the project team to be responsive and adaptable to evolving customer, organizational, and project management needs. Changes are usually driven by one of the following needs:

Value added - The change would be beneficial to the deliverable or project

External events - The change is a reaction to an event triggered outside the project boundaries - political, legal, economic, social, technological etc. changes

Risk responses - The change is needed to take advantage of an opportunity, reduce the chance of a negative event occurring, or is in response to an unplanned event that´s currently taking place

Errors and omissions - The change is needed because of an oversight or defect, or the change is needed because the iterative nature of the project has exposed new knowledge

Under oversight belong:

scope creep - scope is being altered over time without proper change management applied

hope creep - team member being behind schedule but reporting to be on schedule

effort creep - team member working but not making progress

feature creep - team members arbitrarily adding features and functions, no proper change management applied

Project Change Management in PMBOK To change control system or process corresponds In PMBOK Perform Integrated Change Control process. Perform Integrated Change Control is the process of reviewing all change requests, approving changes and managing changes to the deliverables, organizational process assets, project documents and the project management plan. The


© Karin Rava 85

Perform Integrated Change Control process includes the following change management activities in differing levels of detail, based upon the progress of project execution:

Influencing the factors that circumvent integrated change control so that only approved changes are implemented;

Reviewing, analyzing, and approving change requests promptly, which is essential, as a slow decision may negatively affect time, cost, or the feasibility of a change;

Managing the approved changes;

Maintaining the integrity of baselines by releasing only approved changes for incorporation into the project management plan and project documents;

Reviewing, approving, or denying all recommended corrective and preventive actions;

Coordinating changes across the entire project (e.g., a proposed schedule change will often affect cost, risk, quality, and staffing); and

Documenting the complete impact of change requests. Inputs and corresponding outputs of this process are presented on the following figure:

Figure 55. Perform Integrated Change Control Inputs and Outputs

Perform Integrated Change Control Inputs

Project Management Plan

Work Performance Information (deliverable status; schedule progress; costs incurred)

Change Requests

Enterprise Environmental Factors (configuration management system for example)

Organizational Process Assets (change control procedures; procedures for approving and issuing change authorizations; process measurement database)

Perform Integrated Change Control Outputs

Change Request Status Updates

Project Management Plan Updates

Project Document Updates


© Karin Rava 86

Project Change Management in RUP Project change management in RUP is organized in configuration management (CM) system. The major aspects of a CM System include all of the following:

Change Request Management

Configuration Status Reporting

Configuration Management (CM)

Change Tracking

Version Selection

Software Manufacture

Change Request Management (CRM) – addresses the organizational infrastructure required to assess the cost, and schedule, impact of a requested change to the existing product. Change Request Management addresses the workings of a Change Review Team or Change Control Board. Configuration Status Accounting (Measurement) – is used to describe the ‘state’ of the product based on the type, number, rate and severity of defects found, and fixed, during the course of product development. Metrics derived under this aspect, either through audits or raw data, are useful in determining the overall completeness status of the project. Configuration Management (CM) – describes the product structure and identifies its constituent configuration items that are treated as single versionable entities in the configuration management process. CM deals with defining configurations, building and labeling, and collecting versioned artifacts into constituent sets and maintaining traceability between these versions. Change Tracking – describes what is done to components for what reason and at what time. It serves as history and rationale of changes. It is quite separate from assessing the impact of proposed changes as described under 'Change Request Management'. Version Selection – the purpose of good 'version selection' is to ensure that right versions of configuration items are selected for change or implementation. Version selection relies on a solid foundation of 'configuration identification'. Software Manufacture – covers the need to automate the steps to compile, test and package software for distribution. The purpose of planning project configuration and change control is to:

Establish project configuration management policies

Establish policies and processes for controlling product change

Document this information in the Configuration Management Plan (included in Software Development Plan) The purpose of creating project CM environment activity is to establish an environment, by creating and maintaining data repositories, where the overall product can be developed, built, and be available for maintenance and re-use. The purpose of changing and delivering configuration items is to describe:

How any role can create a workspace, access project artifacts, make changes to those artifacts, deliver the changes for inclusion in the overall product, and then be able to view the newly enhanced product.

The Integrator, from the integration workspace, needs to be able to build the product, create baselines and make the baselines available to the rest of the development team.

The purpose of managing baselines and releases is to ensure that subsystems, when they reach a specified level of maturity, are baselined, and then available for release, or re-use in subsequent project iterations and/or other projects. The purpose of monitoring and reporting configuration status is:

To determine if the product meets both functional and physical requirements.

To determine if required artifacts are stored in a controlled library and baselined.

To ensure that artifacts and baselines are available.

To support project Configuration Status Accounting activities that are based on a formalized recording, and reporting on the status of proposed changes, and the status of the implementation of proposed changes.

To facilitate product review through defect tracking and reporting activities.

To ensure that data is 'rolled-up' and reported for the purposes of tracking progress and trends. With changes and their management deals workflow named „Manage Change Requests“. The purpose of having a standard, documented change control process is to ensure that changes are made within a project in a consistent


© Karin Rava 87

manner and the appropriate stakeholders are informed of the state of the product, changes to it and the cost and schedule impact of these changes. As follows I describe change management process more specifically.

Changes to Development Artifacts in RUP

Changes to development artifacts are proposed through Change Requests (CRs) - a formally submitted artifact that is used to track all stakeholder requests. Change Requests are used to:

document new features;

document and track defects;

enhancement requests and any other type of request for a change to the product along with related status information throughout the project lifecycle

The benefit of CRs is that they provide a record of decisions and, due to their assessment process, ensure that change impacts are understood across the project. Change Control Manager is responsible for Change Requests. Change request management responsibilities and artifacts pictorially:

Figure 56. Change Management Responsibilities and Artifacts in RUP

Change request management process is presented on the next figure:

Figure 57. Change management process in RUP


© Karin Rava 88

Change request states are presented on the following figure:

Figure 58. Change Request States

By implementing change we must consider:

effort - How much work is needed to make over again? How much additional work must be done?

complicity - Is requested change easy to implement? What is the possible impact to others system components?

severity - What kind of is the impact of not to implement? Is there any loss of work already done or some kind of data?

impact - What are consequences of implementing change? What are consequences of not implementing change?

schedule - When this change is needed? Is this temporally achievable?

costs - What is cost or saving of change?

authority - Is there authority of implementing change request?

Summary Uncontrolled changes make confusion, what in turn decrease commitment to project – the result is project failure. Changes under control give confidence against unpleasant surprises for all stakeholders. Change management creates transparency and accountability in project. Balance in implementing changes indicates good project management practice. Change is not to be afraid of, but we must be able to deal with it

Used Literature PMI Guide to the Project Management Body of Knowledge (PMBOK® Guide) (5th Edition),

http://app.knovel.com/hotlink/toc/id:kpGPMBKPM1/guide-project-management/guide-project-management?b-q=PMBOK&b-group-by=true (available through TTU network)

RUP, http://sce.uhcl.edu/helm/rationalunifiedprocess/index.htm

Project Integration Management, http://www.cs.su.ac.th/course/517537/slide/lecture3.pdf




http://www.cs.su.ac.th/course/517537/slide/lecture3.pdf


© Karin Rava 89

Herbert Gonder “Change Management - PMBOK® says...”, http://www.pmi-muc.de/Vortraege/20071203/CM-PMBOK-20.pdf

Change Management Metamodel, http://en.wikipedia.org/wiki/File:Metamodel_change_management.png

Configuration Management, http://en.wikipedia.org/wiki/Image:ConfiurationActivityModel.png

Change Control Process Template, http://www.processimpact.com/process_assets/change_control_process.doc

Simon Wallace, The ePMbook, www.epmbook.com

Michael D. Taylor “How To Control Changes to The Project”, http://www.pmhut.com/how-to-control-changes-to-the-project

William Ibbs, Clarence K. Wong,Young Hoon Kwak “Project Change Management System”, http://home.gwu.edu/~kwak/PCMS.pdf

11. Lecture. Project Risk Management

Lecture Topics

Concepts regarding risk management

Roles and responsibilities in risk management

Risk management processes by PMBOK

Risk Management Concepts Risk: is any uncertain event that impacts one or more project objectives. Risks that are detrimental to project

objectives are also called threats or negative risks while risks that are beneficial to the project are called opportunities or positive risks.

Risk response: these are the actions that will be taken prior to the risk taking place that reduce the probability or impact of a threat should it occur or increase the probability or impact of an opportunity

Root cause: the factor(s) that is the source of the risk. We need to understand what factors generate the risk so that we can better develop plans to influence the risk

Trigger: the signs, symptoms, or key event that warns us the risk is imminent or is now more likely to occur

Probability: an assessment of how likely it is that the risk event will occur. Risk responses try to influence probability before the risk takes place –our goal is to reduce the probability of negative impacts from occurring and increasing the chances of positive risks

Impact: the effect the risk will have, usually expressed in monetary, time, quality, or scope measures. Prior to the risk event taking place, our aim is to reduce or eliminate the impact a negative risk will have (should it take place) or to increase the beneficial impact of a positive risk

Contingency plan: these are the actions that will be taken in response to a risk event that is imminent or which is occurring. Contingency plans aim to reduce the impact of a negative risk or increase the impact of an opportunity, and are used in combination with risk responses.

Fallback plan: what actions will be taken if the contingency plan proves ineffective

Roles and Responsibilities in Risk Management Project manager: the project manager is responsible for overall risk management and ensuring that it’s properly

coordinated with all other project management activities.

Risk manager: the person responsible for establishing and overseeing risk management processes and coordinating them with the project manager. The risk manager monitors risks and regularly communicating the risk status to the project team and stakeholders. The risk manager will hold some level of decision-making authority, and where that authority begins and ends needs be documented in the risk management plan

Risk owner: this is the person who has the skills and expertise necessary to best manage a particular risk. This role assists in developing the risk responses, contingency plans, risk actions, and monitors the risk.

http://www.pmi-muc.de/Vortraege/20071203/CM-PMBOK-20.pdf

http://www.pmi-muc.de/Vortraege/20071203/CM-PMBOK-20.pdf

http://en.wikipedia.org/wiki/File:Metamodel_change_management.png

http://en.wikipedia.org/wiki/Image:ConfiurationActivityModel.png

http://www.processimpact.com/process_assets/change_control_process.doc

http://www.epmbook.com/

http://www.pmhut.com/how-to-control-changes-to-the-project

http://www.pmhut.com/how-to-control-changes-to-the-project

http://home.gwu.edu/~kwak/PCMS.pdf


© Karin Rava 90

Risk action owner or risk response owner: the person responsible for carrying out risk response activities for a particular risk

Risk Management Processes in PMBOK The objective of project risk management is not to avoid risks entirely, but to increase the probability and impact of positive events, and decrease the probability and impact of events adverse to the project. Without risk-taking, new methods of efficiency, originality, and competitiveness can't be achieved, so the project risk processes make sure the costs of risks are weighed against the benefits they provide. The Project Risk Management knowledge area includes the processes that identify, evaluate, respond to, and monitor project risks.

General Inputs to Risk Management Processes

Project scope statement

Cost and schedule management plan

Quality management plan

stakeholder register

organizational process assets (risk categories; common definitions of concepts and terms; roles and responsibilities; templates; lessons learned)

enterprise environmental factors (risk attitudes and tolerances that describe the degree of risk that an organization will withstand)

General Outputs from Risk Management Processes

risk management plan

risk register

Risk Management Processes (Steps)

1. risk management planning 2. risk identification 3. risk qualitative analysis 4. risk quantitative analysis 5. risk responses planning 6. risk monitoring and control RM steps continue across the entire life cycle of the project. Managing risk is a discipline; it is important to follow the steps methodically and thoroughly.

Step 1 – Plan Risk Management Plan Risk Management is the process of defining how to conduct risk management activities for a project. It is important to :

to ensure that the degree, type, and visibility of risk management are commensurate with both the risks and the importance of the project to the organization.

to provide sufficient resources and time for risk management activities, and

to establish an agreed-upon basis for evaluating risks. The Plan Risk Management process should begin as a project is conceived and should be completed early during project planning. Plan Risk Management involves:

Defining what risk management activities will occur

Establishing the allotted time and cost for risk management activities

Assigning risk management responsibilities

Deciding how risk probability and impact will be measured

Deciding on acceptable risk thresholds and tolerances


© Karin Rava 91

The output of this process is risk management plan.

Risk Management Plan

The risk management plan describes how risk management will be structured and performed on the project. It includes the following:

Risk management methodology for the project, describing the approaches, tools, and techniques that’ll govern how project risk management will occur

Responsibilities for risk management activities. Defines the lead, support, and risk management team members for each type of activity in the risk management plan, and clarifies their responsibilities

Budget, schedule, and frequency of risk management activities. Activities needed for risk management (and incorporated into the project schedule). Resources and costs allocated to risk management and risk activities as later defined and incorporated into project cost baseline

Definitions of risk probability and impact

Probability and impact matrix

Revised stakeholder’s tolerances

Reporting formats and rules for tracking risk activities

Step 2 – Risk Identification Identify Risks is the process of determining which risks may affect the project and documenting their characteristics. Participants in risk identification activities can include the following: project manager, project team members, risk management team (if assigned), customers, subject matter experts from outside the project team, end users, other project managers, stakeholders, and risk management experts. Identify Risks is an iterative process because new risks may evolve or become known as the project progresses through its life cycle. The frequency of iteration and who participates in each cycle will vary by situation. The format of the risk statements should be consistent to ensure the ability to compare the relative effect of one risk event against others on the project. The process should involve the project team so they can develop and maintain a sense of ownership and responsibility for the risks and associated risk response actions. Stakeholders outside the project team may provide additional objective information.

Risk Identification Techniques

Documentation reviews

Information gathering techniques (brainstorming; Delphi technique; interviewing; root cause analysis)

assumptions analysis;

diagramming techniques (cause and effect diagrams; system or process flow charts; influence diagrams);

SWOT analysis;

Expert judgment

The output of risk identification process is risk register.

Risk register

Dataset characterizing identified risks may contain the following attributes:

Risk: The name, description, and a unique identifier for the risk

Risk Owner: The risk owner is the person in charge of monitoring and controlling the risk

Risk category: The categorization from the risk management plan that the risk falls within. Changes may be requested to the categories originally defined in the risk management plan as risks are identified and analyzed

Root cause: The core factor(s) leading to the risk. A risk may have multiple causes as well as multiple impacts

Potential response: Responses to risks are planned in Risk Response Planning, but potential responses may become obvious during risk identification and should be captured in the risk register

Impact: The risk register contains the specific details about what will be effected should the risk occur


© Karin Rava 92

Probability: The probability of the risk expressed as a percentage or on a scale as defined by the risk management plan

Symptoms/Warning Signs: Any specific conditions likely to trigger the risk or symptoms that the risk is about to occur should be identified. This will help during risk monitoring.

Risk Score: The probability and impact score for the risk. This is obtained from a formula (usually probability x impact) defined in the risk management plan and generated from the probability and impact matrix

Risk Ranking/Priority: This is the prioritization or relative ranking for the risk that allows efforts to be spent more effectively on the higher priority risks.

Risk Response: The strategies and activities that will be taken to encourage and exploit a positive risk, or address a negative risk

Risk Response Responsibilities: The risk action owners are people who have risk response actions to take

Secondary Risks: Risk responses can often raise new risks

Risk Response Budget: This is the budgeted cost to implement approved risk responses

Risk Response Schedule: The scheduled activities necessary to put the risk response into action

Contingency Plan: These are the actions that will take place should the risk response fail. The contingency plan also establishes under what criteria it's to be enacted

Fallback Plan: The fallback plan is a backup to the contingency plan should it fail

Step 3 – Risk Qualitative Analysis Perform Qualitative Risk Analysis is the process of prioritizing risks for further analysis or action by assessing and combining their probability of occurrence and impact Perform Qualitative Risk Analysis assesses the priority of identified risks using their relative probability or likelihood of occurrence, the corresponding impact on project objectives if the risks occur, as well as other factors such as the time frame for response and the organization’s risk tolerance associated with the project constraints of cost, schedule, scope, and quality. Such assessments reflect the attitude of the project team and other stakeholders to risk. This process contains following sub processes or activities:

1. assessing of identified risks by their probability of occurrence; 2. assessing of identified risks by their impact; 3. calculating risk score 4. prioritizing risks by score

By calculating the score we can use different scales. The specific scale must be defined in the risk management plan.

Table 16. Examples of Probability and Impact Scales

Name Example

Relative (or ordinal) scale Very Low Low Medium High Very High

Linear (or cardinal) scale (numeric, intervals between designations are equal)

1 2 3 4 5

Non-linear scale (numeric, but intervals between designations are not equal)

1 2 4 8 16

1. Assessing identified risks by probability of occurrence

As example is given table probability ranks:


© Karin Rava 93

Table 17. Risks Probability Ranks

Scale Probability Rank Numeric Equivalent

Very Low Probability 10% 1

Low Probability 30% 2

Medium Probability 60% 3

High Probability 80% 4

Very High Probability 95% 5

An example of risks assessment results

Table 18. Example of Risk Probabilities Assessment

Very Low Low Medium High Very High

Risk X X

Risk Y X

Risk Z X

Risk Y gets assessment result „2“.

2. Assessing identified risks by their impacts

Example of impact rating criteria are presented in the following table:

Table 19. Example of Impact Rating Criteria

Very Low Low Medium High Very High

Time 3 days or less 7 days or less 10 days or less 14 days or less 15 days or less

Numeric Equivalent

1 2 3 4 5

Scope < 10 hrs effort < 20 hrs effort < 30 hrs effort < 40 hrs effort > 40 hrs effort

Numeric Equivalent

1 2 3 4 5

Cost < 1000 eur < 1500 eur < 2000 eur < 2500 eur > 2500 eur

Numeric Equivalent

1 2 4 8 16

Risks impact calculation example is presented in the following table:

Table 20. Risks Impact Calculation Example

Time Scope Cost

Very Low

Lowl

Medium

High

Very High

Very Low

Low

Medium

High

Very High

Very Low

Low

Medium

High

Very High

Impact Rating

1 2 3 4 5 1 2 3 4 5 1 2 4 8 16

Risk X

X X X 4

Ris x x X 10


© Karin Rava 94

k Y

Risk Z

x X x 8

Risk Y gets impact rating „10“.

3. Calculating risk score

Score is the product of probability assessment result and impact rating. By the example of Risk Y the score is 2 x 10 = 20

4. Risks prioritizing

Risks prioritizing is based on Risk Probability and Impact Matrix presented in the following table:

Table 21. Risks Probability and Impact Matrix

15 30 50 80 130

12 24 40 64 104

9 18 30 48 78

6 12 20 32 50

3 6 10 16 26

Interpretation of this table is:

>= 75 = very high priority risk

>= 35 and < 75 = high priority risk

>= 18 and < 35 = medium priority risk

>= 9 and < 18 = low priority risk

< 9 = very low priority risk

By this matrix the priority of risk y is „medium“.

Step 4 – Risk Quantitative Analysis Perform Quantitative Risk Analysis is the process of numerically analyzing the effect of identified risks on overall project objectives. This process is performed on risks that have been prioritized by the Perform Qualitative Risk Analysis process as potentially and substantially impacting the project’s competing demands. The Perform Quantitative Risk Analysis process analyzes the effect of those risk events. It may be used to assign a numerical rating to those risks individually or to evaluate the aggregate effect of all risks affecting the project. It also presents a quantitative approach to making decisions in the presence of uncertainty. Techniques used in quantitative risk analysis are the following:

Sensitivity analysis

Expected monetary value analysis

Modeling and simulations

Step 5 – Risk Response Planning Plan Risk Responses is the process of developing options and actions to enhance opportunities and to reduce threats to project objectives. It follows the Perform Qualitative Risk Analysis process and the Perform Quantitative Risk Analysis process (if used). It includes the identification and assignment of one person (the “risk response owner”) to take


© Karin Rava 95

responsibility for each agreed-to and funded risk response. Plan Risk Responses addresses the risks by their priority, inserting resources and activities into the budget, schedule and project management plan as needed. Planned risk responses must be appropriate to the significance of the risk, cost effective in meeting the challenge, realistic within the project context, agreed upon by all parties involved, and owned by a responsible person. They must also be timely. Selecting the best risk response from several options is often required. There are 4 classifications of response strategies – proactive behavior:

Eliminate uncertainty

Allocate ownership

Modify exposure

Include in baseline

1. Eliminate uncertainty

Threat response – avoid. Risk avoidance involves changing the project management plan

to eliminate the threat posed by an adverse risk

to isolate the project objectives from the risk's impact

to relax the objective that is in jeopardy Opportunity response – exploit. This strategy seeks to eliminate the uncertainty associated with a particular upside risk

by making the opportunity definitely happen

2. Allocate ownership

Threat response – transfer. Risk transference requires shifting the negative impact of a threat, along with ownership of the response, to a third party Opportunity response – share. Sharing a positive risk involves allocating ownership to a third party who is best able to capture the opportunity for the benefit of the project

3. Modify exposure

Threat response – mitigate. Risk mitigation implies a reduction in the probability and/or impact of adverse risk event to an acceptable threshold Opportunity response – enhance. Modifies the size of an opportunity by increasing probability and/or positive impacts and by identifying and maximizing key drivers of these positive-impact risks

4. Include in baseline

Threat response – accept. Indicates that the project team has decided not to change the project management plan to deal with a risk or is unable to identify any other suitable response strategy Opportunity response – ignore. The same as for threat

Contingency Strategy

A contingent response involves a contingency plan, which will be put into effect should the risk response fail. The contingent response identifies the exact situation and circumstances (triggers) in which the contingency plan can be put into effect and when it can be discontinued. This response type is used in combination with another risk response, such as mitigation. Regardless of the primary risk response strategy, a contingency plan should be in place for all but the lowest priority risks (and even those depending upon what objectives they can impact). The fallback plan kicks in if the contingency plan fails. It can be looked at as a contingency plan for the contingency plan. The fallback plan spells out steps will be taken to recover if the contingency plan fails, and it specifies under what situations and circumstances it is activated and subsequently deactivated


© Karin Rava 96

Step 6 – Risk Monitoring and Control Monitor and Control Risks is the process of implementing risk response plans, tracking identified risks, monitoring residual risks, identifying new risks, and evaluating risk process effectiveness throughout the project. Planned risk responses that are included in the project management plan are executed during the life cycle of the project, but the project work should be continuously monitored for new, changing, and outdated risks. The Monitor and Control Risks process applies techniques, such as variance and trend analysis, which require the use of performance information generated during project execution. Other purposes of the Monitor and Control Risks process are to determine if:

Project assumptions are still valid,

Analysis shows an assessed risk has changed or can be retired,

Risk management policies and procedures are being followed, and

Contingency reserves of cost or schedule should be modified in alignment with the current risk assessment. Monitor and Control Risks can involve choosing alternative strategies, executing a contingency or fallback plan, taking corrective action, and modifying the project management plan. The risk response owner reports periodically to the project manager on the effectiveness of the plan, any unanticipated effects, and any correction needed to handle the risk appropriately. Monitor and Control Risks also includes updating the organizational process assets, including project lessons learned databases and risk management templates, for the benefit of future projects.



David Hillson, „Effective Strategies for Exploiting Opportunities“, http://www.risk-doctor.com/pdf-files/opp1101.pdf

Simon Wallace, The ePMbook, www.epmbook.com

LING Zong, Ph. D. Advanced IT Project Management, IBM Software Group

Richard E. Fairley, Software Risk Management. Software engineering glossary http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01438337

Risk Assessment and Allocation for Highway Construction Management. http://international.fhwa.dot.gov/riskassess/risk_hcm06_04.cfm#sfig17

Project Risk Management Handbook and Tools, http://www.dot.ca.gov/hq/projmgmt/guidance_prmhb.htm

12. Lecture. Project Quality Management

Lecture Topics

Definitions of quality

Quality management processes in PMBOK

Differences between quality control and assurance

Quality management in RUP

Definitions of Quality

The degree to which a set of inherent characteristics fulfill requirements (PMBOK, originally ISO 9000)

An inherent or distinguishing characteristic; a property or a personal trait, especially a character trait or essential

character; nature or superiority of kind or degree or grade of excellence (The American Heritage Dictionary of the

English Language)



http://www.risk-doctor.com/pdf-files/opp1101.pdf

http://www.risk-doctor.com/pdf-files/opp1101.pdf

http://www.epmbook.com/

http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01438337

http://international.fhwa.dot.gov/riskassess/risk_hcm06_04.cfm


© Karin Rava 97

"...the characteristic of having demonstrated the achievement of producing a product that meets or exceeds agreed-

on requirements—as measured by agreed-on measures and criteria—and that is produced by an agreed-on process”

(RUP, in the context of software development)

It must be separate quality and grade (rank) where grade means a category assigned to products or services having the

same functional use but different technical characteristics

Achieving quality is not simply "meeting requirements", or producing a product that meets user needs and expectations.

Quality also includes:

identifying the measures and criteria to demonstrate the achievement of quality

the implementation of a process to ensure that the product created by the process has achieved the desired degree

of quality, and can be repeated and managed

The responsibility of project manager is to ensure that:

project work end result(s) meet(s) stakeholder expectations (needs)

project work (resource usage) meets stakeholders expectations (needs)

In the context of information system development to achieve these responsibilities comes into the play information

system and information system development process quality management. In this lecture project quality management

processes are discussed.

Quality Management Processes in PMBOK Project Quality Management by PMBOK includes the processes and activities of the performing organization that determine quality policies, objectives, and responsibilities so that the project will satisfy the needs for which it was undertaken. It implements the quality management system through policy and procedures with continuous process improvement activities conducted throughout, as appropriate. Project Quality Management addresses the management of the project and the product of the project. It applies to all projects, regardless of the nature of their product. Product quality measures and techniques are specific to the type of product produced by the project. Failure to meet product or project quality requirements can have serious negative consequences for any or all of the project stakeholders. For example:

Meeting customer requirements by overworking the project team may result in increased employee attrition, errors,

or rework.

Meeting project schedule objectives by rushing planned quality inspections may result in undetected errors.

Modern quality management complements project management. Both disciplines recognize the importance of:

Customer satisfaction. Understanding, evaluating, defining, and managing expectations so that customer requirements are met. This requires a combination of conformance to requirements (to ensure the project produces what it was created to produce – done right (lecturer remark)) and fitness for use (the product or service must satisfy real needs – right product (lecturer remark)).

Prevention over inspection. One of the fundamental tenets of modern quality management states that quality is planned, designed, and built in—not inspected in. The cost of preventing mistakes is generally much less than the cost of correcting them when they are found by inspection.

Continuous improvement. The plan-do-check-act cycle is the basis for quality improvement as defined by Shewhart and modified by Deming. In addition, quality improvement initiatives undertaken by the performing organization, such as TQM and Six Sigma, should improve the quality of the project’s management as well as the quality of the project’s product. Process improvement models include Malcolm Baldrige, Organizational Project Management Maturity Model (OPM3®), and Capability Maturity Model Integrated (CMMI®).

Management Responsibility. Success requires the participation of all members of the project team, but remains the responsibility of management to provide the resources needed to succeed.


© Karin Rava 98

Project quality management processes in PMBOK are as follows:

Plan quality

Perform quality assurance

Perfrom quality control

Overview of these processes and mutual relationships through inputs and outputs gives the next figure:

Figure 59. Project Quality Management Processes in PMBOK

Plan Quality Plan Quality is the process of identifying quality requirements and/or standards for the project and product, and documenting how the project will demonstrate compliance. Quality planning should be performed in parallel with the other project planning processes. For example, proposed changes in the product to meet identified quality standards may require cost or schedule adjustments and a detailed risk analysis of the impact to plans. The quality planning techniques are those most frequently used on projects. There are many others that may be useful on certain projects or in some application areas. Plan quality process inputs and outputs are presented on the next figure:

Figure 60. Plan Quality Process Inputs and Outputs


© Karin Rava 99

Plan Quality Inputs

Scope baseline (SB)

Stakeholder register (SHR)

Cost performance baseline (CPB)

Schedule baseline (SHB)

Risk register (RR)

Enterprise environmental factors (EEF – rules, standards etc.)

Organizational process assets (OPA – quality policies in organization)

Plan Quality Tools and Techniques

Cost-benefit analysis

Cost of quality

Control charts

Benchmarking

Statistical sampling

Quality management methodologies

Plan Quality Outputs:

Quality Management Plan (QMP) - describes how the project management team will implement the performing

organization’s quality policy

Quality metrics (QM) - an operational definition that describes, in very specific terms, a project or product attribute

and how the quality control process will measure it. Quality metrics examples: on-time performance, budget

control, defect frequency, failure rate, availability, reliability, test coverage

Quality checklists (QCL) - a structured tool, usually component-specific, used to verify that a set of required steps

has been performed

Process improvement plan (PIP) - details the steps for analyzing processes to identify activities which enhance their

value. Areas to consider include:

o Process boundaries - describes the purpose of processes, their start and end, their inputs/ outputs, the

data required, the owner, and the stakeholders

o Process configuration - a graphic depiction of processes, with interfaces identified, used to facilitate

analysis.

o Process metrics - along with control limits, allows analysis of process efficiency

o Targets for improved performance - guides the process improvement activities

Perform Quality Assurance Perform Quality Assurance is the process of auditing the quality requirements and the results from quality control measurements to ensure appropriate quality standards and operational definitions are used. Perform Quality Assurance also provides an umbrella for continuous process improvement, which is an iterative means for improving the quality of all processes. Continuous process improvement reduces waste and eliminates activities that do not add value. This allows processes to operate at increased levels of efficiency and effectiveness. Perform Quality Assurance inputs and outputs pictorially are presented on the next figure:


© Karin Rava 100

Figure 61. Perform Quality Assurance Process Inputs and Outputs

Perform Quality Assurance Inputs

o Project management plan (PMP), specifically quality management plan (QMP) and process improvement plan (PIP)

o Quality metrics (QM) o Work performance information (WPI):

o Technical performance measures,

o Project deliverables status,

o Schedule progress

o Costs incurred.

o Quality control measurements (QCM). The results of quality control activities. They are used to analyze and evaluate the quality standards and processes of the performing organization.

Perform Quality Assurance Tools and Techniques

Plan quality and perform quality control tools and techniques

Quality audits

Process analysis

Perform Quality Assurance Outputs

Organizational Process Assets (OPA) updates

Change requests (CR): they can be used to take corrective action or preventive action or to perform defect repair

PMP updates

Project document updates

Perform Quality Control Perform Quality Control is the process of monitoring and recording results of executing the quality activities to assess performance and recommend necessary changes. Quality control is performed throughout the project. Quality standards include project processes and product goals. Project results include deliverables and project management results, such as cost and schedule performance. Quality control is often performed by a quality control department or


© Karin Rava 101

similarly titled organizational unit. Quality control activities identify causes of poor process or product quality and recommend and/or take action to eliminate them. Perform quality control inputs and outputs pictorially are presented on the next figure:

Figure 62. Perform Quality Control Process Inputs and Outputs

Perform Quality Control Inputs

Project management plan (PMP), specifically quality management plan (QMP)

Quality metrics (QM)

Quality checklists (QCL)

Work performance measurements (WPM): they are used to produce project activity metrics to evaluate actual progress as compared to planned progress. These metrics include, but are not limited to:

o Planned vs. actual technical performance,

o Planned vs. actual schedule performance, and

o Planned vs. actual cost performance.

Approved change requests: they can include modifications such as defect repairs, revised work methods and revised schedule. The timely implementation of approved changes needs to be verified

Deliverables

Organizational process assets (OPA)

Perform Quality Control Tools and Techniques

o Cause and effect diagrams o Control charts o Histogram o Pareto chart o Run chart o Scatter diagram o Statistical sampling o Inspection o Approved change requests review

Quality Control Outputs

Quality Control Measurements (QCM) - the documented results of quality control activities in the format specified during quality planning


© Karin Rava 102

Validated Changes - any changed or repaired items are inspected and will be either accepted or rejected before notification of the decision is provided. Rejected items may require rework

Validated Deliverables - a goal of quality control is to determine the correctness of deliverables. The results of the execution quality control processes are validated deliverables. Validated deliverables are an input to Verify Scope for formalized acceptance

In the context of information system development we can find project quality management processes as illustrated on the next figure:

Figure 63. Quality Management Processes in the context of IS Development

Differences between Quality Control and Assurance

Quality Control

relates to a specific product or service.

verifies whether specific attribute(s) are in, or are not in, a specific product or service.

identifies defects for the primary purpose of correcting defects.

is the responsibility of the team/worker.

is concerned with a specific product.

Quality Assurance

helps establish processes

sets up measurement programs to evaluate processes.

identifies weaknesses in processes and improves them.

is a management responsibility, frequently performed by a staff function.

is concerned with all of the products that will ever be produced by a process.

is sometimes called quality control over quality control because it evaluates whether quality control is working.

personnel should not ever perform quality control unless it is to validate quality control.


© Karin Rava 103

Quality Management in RUP We measure primarily to gain control of a project, and therefore to be able to manage it. We measure to:

evaluate how close or far we are from the objectives we had set in our plan in terms of completion, quality, compliance to requirements, etc.

be able to better estimate for new projects effort, cost and quality, based on past experience.

evaluate how we improve on some key aspects of performance of the process over time, to see what are the effects of changes.

The measurement of Quality, whether Product or Process, requires the collection and analysis of information, usually stated in terms of measurements and metrics. Measuring some key aspects of a project adds a non-negligible cost. So we do not measure just anything because we can. We must set very precise goals for this effort, and only collect metrics that will allow us to satisfy these goals. There are two kinds of goals:

Knowledge goals

Change or achievement goals

Knowledge goals are expressed by the use of verbs like evaluate, predict, monitor. You want to better understand your development process. For example, you may want to assess product quality, obtain data to predict testing effort, monitor test coverage, or track requirements changes. Change or achievement goals are expressed by the use of verbs such as increase, reduce, improve, or achieve. You are usually interested in seeing how things change or improve over time, from an iteration to another, from a project to another. Examples:

Monitor progress relative to plan

Improve customer satisfaction

Improve productivity

Improve predictability

Increase reuse These general management goals do not translate readily into metrics. We have to translate them into some smaller sub goals (or action goals) which identify the actions project members have to take to achieve the goal. And we have to make sure that the people involved understand the benefits. Examples: the goal to "improve customer satisfaction" would decompose into:

Define customer satisfaction

Measure customer satisfaction, over several releases

Verify that satisfaction improves The goal to "improve productivity" would decompose into:

Measure effort

Measure progress

Calculate productivity over several iterations or projects.

Compare the results Then some of the sub goals (but not all) would require some metrics to be collected. Example: "Measure customer satisfaction" can be derived from:

Customer survey (where customer would give marks for different aspects)

Number and severity of calls to a customer support hotline. All metrics require criteria to identify and to determine the degree or level at which of acceptable quality is attained. The level of acceptable quality is negotiable and variable, and needs to be determined and agreed upon early in the development lifecycle For example, in the early iterations, a high number of application defects are acceptable, but not architectural ones. In late iterations, only aesthetic defects are acceptable in the application. The acceptance criteria may be stated in many ways and may include more than one measure. Common acceptance criteria may include the following measures:


© Karin Rava 104

Defect counts and / or trends, such as the number of defects identified, fixed, or that remain open (not fixed). Test coverage, such as the percentage of code, or use cases planned or implemented and executed (by a test). Test coverage is usually used in conjunction with the defect criteria identified above). Performance, such as a the time required for a specified action (use case, operation, or other event) to occur. This is criteria is commonly used for Performance testing, Failover and recovery testing, or other tests in which time criticality is essential. Compliance. This criteria indicates the degree to which an artifact or process activity / step must meet an agreed upon standard or guideline. Acceptability or satisfaction. This criteria is usually used with subjective measures, such as usability or aesthetics.

Measuring Product Quality

Stating the requirements in a clear, concise, and testable fashion is only part of achieving product quality. It is also necessary to identify the measures and criteria that will be used to identify the desired level of quality and determine if it has been achieved. Measures describe the method used to capture the data used to assess quality, while criteria define the level or point at which the product has achieved acceptable (or unacceptable) quality. Measuring the product quality of an executable artifact is achieved using one or more measurement techniques, such as:

reviews / walkthroughs

inspection

execution Different metrics are used, dependent upon the nature the quality goal of the measure. For example, in reviews, walkthroughs, and inspections, the primary goal is to focus on the function and reliability quality dimensions. Defects, coverage, and compliance are the primary metrics used when these measurement techniques are used. Execution however, may focus on function, reliability, or performance. Therefore defects, coverage, and performance are the primary metrics used. Other measures and metrics will vary based upon the nature of the requirement.

Measuring Process Quality

The measurement of Process Quality is achieved by collecting both knowledge and achievement measures.

The degree of adherence to the standards, guidelines, and implementation of an accepted process.

Status / state of current process implementation to planned implementation.

The quality of the artifacts produced (using product quality measures described above). Measuring process quality is achieved using one or more measurement techniques, such as:

progress - such as use cases demonstrated or milestones completed

variance - differences between planned and actual schedules, budgets, staffing requirements, etc.

product quality measures and metrics (as described in Measuring Product Quality section above)



RUP, Project Management Discipline Concept “Measuring Quality” http://sce.uhcl.edu/helm/rationalunifiedprocess/index.htm

Monterrey Software Quality Assurance Association (MSQAA), Quality Assurance versus Quality Control, http://www.msqaa.org/Best_Practices/Quality_Control/QualityAssuranceVersusQualityControl.pdf

Quality Assurance Institute, Guide to CSTE Common BOK, Ver. 6.2.., http://www.softwaretestinggenius.com/download/CBOK.pdf




http://www.msqaa.org/Best_Practices/Quality_Control/QualityAssuranceVersusQualityControl.pdf

http://www.softwaretestinggenius.com/download/CBOK.pdf


© Karin Rava 105

13. Lecture. Project Closing Why do projects end?

Objective has been met;

Objective cannot be met;

Need no longer exists With project closing is associated 2 main questions: when to end and how to end a project? Evaluation about Project Closure should be based on at least following aspects:

Economical valuation - is projects continuance economically reasonable?

Evaluation of projects costs and schedule - when all projects costs and performance data are known, should project be terminated or continued?

Customers objectives - are customers’ existing objectives still under projects fulfillment?

Client relationships and reputation - when premature termination is justified, then what is its impact to organizations reputation and client relationships?

Contractual and ethical considerations - is projects premature termination by contract possible? Is projects termination ethical?

Reasons to Kill a Project

When the project has formally ended - all the deliverables have been accepted by client and the project formally closed

When you have delivered 80% of the project - to deliver the other 20% often meant 80% more time and the ROI was not worth of it.

When it is obvious that the project will not deliver against the original business case.

When the project is so over budget that you are simply pouring money into sinking hole.

When key stakeholders object to or clearly do not buy into the project and without them, the project will clearly not succeed.

When the project does not fit with the overall strategy of the company - too many projects and not all fitted into the company strategy.

When risks are so high that to continue would impact negatively on the company - financial, publicity, health and safety

Project Closure Process In PMBOK this is the process to formally close down the project or in multi-phase projects the closure of a phase whether a project is successful or not. Pictorially is presented on the following figure:

Figure 64. Close Project or Phase Process in PMBOK


© Karin Rava 106

Project formal closing gives insurance to customer and stakeholders for further operation. It ensures that:

Outcomes match the stated goals of the project;

Customers and stakeholders are happy with the results;

Critical knowledge is captured;

The team feels a sense of completion;

Project resources are released for new projects;

The customers have formally accepted all outcomes;

Operational; procedures are in place;

The handover to operational staff has been completed;

Documentation and reference material is in place;

Any further actions and recommendations are documented and disseminated;

The results are disseminated to relevant people;

There are no loose ends

Planning for Closure

Project closing needs to be planned temporally and financially. Projects end planning begins already on the first day of the project. The same group of people must participate in closing process that were participating in project initiating - generally project management group or steering committee. To properly plan any project, you have to envision the end-game…how and when will your project end? Following closure issues should be addressed as you initially define and structure your project: acceptance criteria; timing of closure activities; transition needs; resources, roles and responsibilities; communication

Main Procedures in Project Closing

Contract closure procedures: o verifying project scope; o performing formal acceptance and handover of the final product, service, or result to the customer; o making project final documentation and presenting project performance overview to the customer

Administrative closure procedures o making sure the project is finalized across all processes; o gathering and disseminating lessons learned; o dismissing project organization and transferring responsibilities and other resources; o archiving project information

Scope Verification or Project Final Deliverables Audit

Before the project can be formally closed out, an audit must be conducted to verify that all required scope (work) has been satisfactorily completed. Includes following steps:

verify tested products meet all specifications;

validate all supported documents;

verify all deliverables are available (product count); assess customer satisfaction In RUP are 2 process:

final configuration audit – functional and physical configuration audit

final product acceptance review – according Product Acceptance Plan

Project Final Report - Documentation for Project Signoff Meeting

Project description: o project background; o Project objectives; o Project organization; o Project performance; o Deliverables description (if deviations from plan then their reasons); Overview of planned and used resources;


© Karin Rava 107

Proposals for continuation of work: o Activities necessary to use project outcomes and are beyond project frames; o Regulation for making changes in outcomes; Initial plans for new project

Project Signoff Meeting

To get final signoff from project sponsor and any key stakeholder or to obtain formal project acceptance from customers and management. A formal signoff documents that the sponsor is satisfied, objectives are met, and the project is truly complete. A content of that meeting:

Project acceptance review;

Final metrics review;

Acknowledgment the contributions of team members;

Sharing the key lessons learned;

Discussing related projects for the future

Project Acceptance Review

During the meeting the attendees review the results of the product acceptance reviews and tests that are reported in the iteration assessment and using the product acceptance criteria from the Product Acceptance Plan determine the following:

Physical audit results - Has the customer received all the project deliverables?

Functional audit results - Did the results of the product acceptance reviews and test demonstrate that the product satisfies its requirements? Has any required customer training been completed? If required, has on-site installation been successfully completed?

The Approval Decision

Project Accepted - The customer representative agrees that the project deliverables have satisfied the acceptance criteria, and the customer takes possession of the delivered product an support materials

Conditional Acceptance - The customer representative agrees to accept the results of the project, subject to the completion of specified corrective actions

Project Not Accepted - The project fails to achieve the product acceptance criteria, and requires additional work and another project acceptance cycle to be carried out.

Project is Completed by customer decision. Addresses delivery and receiving of the final product, service, or result to the customer; extent and mode of notification about project close-out. Project manager is dismissed from responsibilities for project by management of organization

Finalizing the Project´s Documents

Collecting final time sheets, expense reports, and team status reports;

Closing or completing remaining tasks in the project schedule;

Collecting final cost and schedule metrics;

Making final payments to vendors and contractors, and closing out contractors;

Reviewing and updating the issue log, highlighting remaining issues, and deciding how these issues are to be addressed;

Preparing a plan for handling ongoing product support;

Documenting What You´ve Learned;

Survey team members about what worked and what didn´t;

Call a meeting with your sponsor and executive stakeholders to capture their thoughts;

Ask consultants and vendors for objective feedback, both about your organization and about the project´s execution

Setting up a Library

Storing all key documents in a project library that is accessible to future project teams –

Project planning documents;


© Karin Rava 108

Status reports;

Design documents;

Test cases and test results;

Issues and resolutions;

Risk documentation;

Change requests;

Presentations;

Important communications (both those sent and those received);

Time and expense reports;

Contracts and invoices;

Recognize and Reward

Evaluate - provide each team member with a performance evaluation: highlight contributions the member made;

Identify skills the member updated;

Recommend new roles the member might be ready for;

Celebrate!. Team needs and deserves a celebration. A team dinner, a team outing, gift certificates, or other rewards are minor costs that generate a large return in terms of morale and job satisfaction

Project Cancellation Project closing process occurs even if the project is canceled or otherwise terminated before fulfilling all its requirements. When a project is terminated, the project performance and deliverables are evaluated up to that point in time. The deliverables as they stand at termination are compared against where they were expected to be. It's also important to document the reasons the project was terminated as these contribute to the knowledge base for future projects.

Used Literature Rosenhead Ron, 7 Reasons to kill a project http://www.goarticles.com/cgi-bin/showa.cgi?C=1538541

Project Management Process. Project Closure (lk. 81 – 86) http://www.projectsmart.co.uk/docs/pmprocess.pdf


RUP, http://sce.uhcl.edu/helm/rationalunifiedprocess/index.htm

Barager Jeffrey S., Project closure: Applying the finishing touches http://office.microsoft.com/en-us/project/HA011277661033.aspx

Esther Schindler, “26 Ways To Know Your Software Development Project Is Doomed”, http://www.cio.com/article/print/470103

JISC infoNet, " Closing a Project - Introduction", http://www.pmhut.com/closing-a-project-introduction

Gina Abudi, „How to Capture Lessons Learned“, www.pmhut.com/how-to-capture-lessons-learned

http://www.goarticles.com/cgi-bin/showa.cgi?C=1538541

http://www.projectsmart.co.uk/docs/pmprocess.pdf




http://office.microsoft.com/en-us/project/HA011277661033.aspx

http://office.microsoft.com/en-us/project/HA011277661033.aspx

http://www.cio.com/article/print/470103

http://www.pmhut.com/?s=%22JISC+infoNet%22

http://www.pmhut.com/closing-a-project-introduction

http://www.pmhut.com/?s=%22Gina+Abudi%22

http://www.pmhut.com/how-to-capture-lessons-learned