Upload
donhu
View
219
Download
1
Embed Size (px)
Citation preview
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.
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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:
IS PM lectures, 2014 idu3390
© 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.
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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.
IS PM lectures, 2014 idu3390
© 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.
IS PM lectures, 2014 idu3390
© 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:
IS PM lectures, 2014 idu3390
© 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:
IS PM lectures, 2014 idu3390
© 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:
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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:
IS PM lectures, 2014 idu3390
© 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.
IS PM lectures, 2014 idu3390
© 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.
IS PM lectures, 2014 idu3390
© 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:
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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?
IS PM lectures, 2014 idu3390
© 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.
IS PM lectures, 2014 idu3390
© 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
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)
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
IS PM lectures, 2014 idu3390
© 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.
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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,
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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?
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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.
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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.
IS PM lectures, 2014 idu3390
© 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:
IS PM lectures, 2014 idu3390
© 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.
IS PM lectures, 2014 idu3390
© 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)
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© Karin Rava 36
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)
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
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
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
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=
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:
IS PM lectures, 2014 idu3390
© 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:
IS PM lectures, 2014 idu3390
© 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.
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
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)
John Filicetti. Project Management Process - Phase 2 - Planning - Develop Project Schedule,
http://www.pmhut.com/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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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.
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© Karin Rava 49
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 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:
IS PM lectures, 2014 idu3390
© 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:
IS PM lectures, 2014 idu3390
© 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)
IS PM lectures, 2014 idu3390
© 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
Project management plan;
Resource calendars
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
Project staff assignments
Project management plan;
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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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:
IS PM lectures, 2014 idu3390
© 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;
IS PM lectures, 2014 idu3390
© 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
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)
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
IS PM lectures, 2014 idu3390
© 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:
IS PM lectures, 2014 idu3390
© 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;
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
Project staff assignments
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,
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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:
IS PM lectures, 2014 idu3390
© 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.
IS PM lectures, 2014 idu3390
© Karin Rava 67
Communication tools enabling collaboration are presenter on the next figure:
Figure 39. Example of Communication Technologies
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 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
IS PM lectures, 2014 idu3390
© 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:
IS PM lectures, 2014 idu3390
© 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:
IS PM lectures, 2014 idu3390
© 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:
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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:
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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,
IS PM lectures, 2014 idu3390
© 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.
IS PM lectures, 2014 idu3390
© 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.
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
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)
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
IS PM lectures, 2014 idu3390
© 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:
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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.
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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:
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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.
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)
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)
IS PM lectures, 2014 idu3390
© 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.
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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:
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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.
IS PM lectures, 2014 idu3390
© 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:
IS PM lectures, 2014 idu3390
© 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)
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, 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
IS PM lectures, 2014 idu3390
© 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
IS PM lectures, 2014 idu3390
© 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;
IS PM lectures, 2014 idu3390
© 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;
IS PM lectures, 2014 idu3390
© 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
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
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