3000 words
template/CDC UP PROJECT MGT TEMPLATE
Version:
<1.0>
project Management plan
Version <1.0>
VERSION HISTORY
[Provide information on how the development and distribution of the Project Management Plan was controlled and tracked. Use the table below to provide the version number, the author implementing the version, the date of the version, the name of the person approving the version, the date that particular version was approved, and a brief description of the reason for creating the revised version.]
Version #
Implemented
By
Revision
Date
Approved
By
Approval
Date
Reason
1.0
UP Template Version: 11/30/06
Note to the Author
[This document is a template of a Project Management Plan document for a project. The template includes instructions to the author, boilerplate text, and fields that should be replaced with the values specific to the project.
Blue italicized text enclosed in square brackets ([text]) provides instructions to the document author, or describes the intent, assumptions and context for content included in this document.
Blue italicized text enclosed in angle brackets (
Text and tables in black are provided as boilerplate examples of wording and formats that may be used or modified as appropriate to a specific project. These are offered only as suggestions to assist in developing project documents; they are not mandatory formats.
When using this template for your project document, it is recommended that you follow these steps:
Replace all text enclosed in angle brackets (e.g.,,
Select File>Properties>Summary and fill in the Title field with the Document Name and the Subject field with the Project Name.
Select File>Properties>Custom and fill in the Last Modified, Status, and Version fields with the appropriate information for this document.
After you click OK to close the dialog box, update the fields throughout the document with these values by selecting Edit>Select All (or Ctrl-A) and pressing F9. Or you can update an individual field by clicking on it and pressing F9. This must be done separately for Headers and Footers.
Modify boilerplate text as appropriate to the specific project.
To add any new sections to the document, ensure that the appropriate header and body text styles are maintained. Styles used for the Section Headings are Heading 1, Heading 2 and Heading 3. Style used for boilerplate text is Body Text.
To update the Table of Contents, right-click and select “Update field” and choose the option- “Update entire table”
Before submission of the first draft of this document, delete this “Notes to the Author” page and all instructions to the author, which appear throughout the document as blue italicized text enclosed in square brackets.]
TABLE OF CONTENTS
4
1
Introduction
4
1.1
Purpose of Project Management Plan
4
2
Executive Summary of Project Charter
4
2.1
Assumptions/Constraints
4
3
Scope Management
4
3.1
Work Breakdown Structure
4
3.2
Deployment Plan
4
3.3
Change Control Management
4
4
Schedule/Time Management
5
4.1
Milestones
5
4.2
Project Schedule
5
4.2.1
Dependencies
5
5
Cost/Budget Management
5
6
Quality Management
5
7
Human Resource Management
5
8
Communications Management
5
8.1
Communication Matrix
5
9
Risk Management
6
9.1
Risk Log
6
10
Issue Management
6
10.1
Issue Log
6
11
Procurement Management
6
12
Compliance Related Planning
7
Appendix A: Project Management Plan Approval
8
APPENDIX B: REFERENCES
9
APPENDIX C: KEY TERMS
10
APPENDIX D: SUMMARY OF SPENDING
Introduction
Purpose of Project Management Plan
[Provide the purpose of the project charter.]
The intended audience of the
Executive Summary of Project Charter
[Provide an executive summary of the approved project charter. Provide a reference to the approved Project Charter. Elaborate on any sections within the Project Charter that need further detail contained within the PMP.]
Assumptions/Constraints
[Insert summary of any changes from the project assumptions and/or constraints that were originally outlined in the project charter.]
Scope Management
[Insert the project’s scope management plan or provide a reference to where it is stored.]
Work Breakdown Structure
[Insert the project’s work breakdown structure or provide a reference to where it is stored.]
Deployment Plan
[Example: The project involves deploying an application to state health partners. This section would discuss the approach for rolling out the application to the end users, including conducting environment assessments, developing memorandums of understandings, hardware/software installation, data conversion.]
Change Control Management
[Example of Change Control: If a development server for your project is administered by another organization that is responsible for installing machine upgrades and there are scheduled outages that will impact your project schedule. Changes to the project will need to be made to deal with the potential impact of the scheduled outage.]
Schedule/Time Management
[Example of schedule management approach: Establish a baseline within the first two weeks of the project and monitor progress against the baseline on a weekly basis. The Project Manager will be responsible for ensuring the project schedule is updated with the latest information and never more than three business days out of date. For variances on executive milestones greater than 10%, the project may choose to use guidance specified by CPIC. See the CDC UP Project Schedule document for more guidance on project schedules and for Project Schedule templates.]
Milestones
The table below lists the milestones for this project, along with their estimated completion timeframe.
Milestones
Estimated Completion Timeframe
[Insert milestone information (e.g., Project planned and authorized to proceed)]
[Insert completion timeframe (e.g., Two weeks after project concept is approved)]
[Add additional rows as necessary]
Project Schedule
[Insert the project’s schedule or provide a reference to where it is stored.]
Dependencies
[Insert the schedule/project dependencies (both internal and external).]
Cost/Budget Management
[Insert the project’s cost management plan or provide a reference to where it is stored.]
Quality Management
[Example: For an information system, controlling the consistency of screen layouts would include reviewing all screens to make sure they match the standards. Quality measures may be no bugs or defects for certain critical requirements, consistent screen layouts, or correctly calculating variables. Quality may be ensured through inspections, audits, formal testing and documentation of defects in a defect tracking system to ensure defects are fixed, retested and closed. Some projects may choose to use a traceability matrix to determine if critical requirements have been met.]
Human Resource Management
[Insert the project’s human resource management plan or provide a reference to where it is stored.]
Communications Management
[Insert the project’s communication management plan or provide a reference to where it is stored.]
Communication Matrix
[Insert the project’s communication matrix or provide a reference to where it is stored.]
Stakeholder
Messages
Vehicles
Frequency
Communicators
Feedback Mechanisms
Risk Management
[Insert the project’s risk management plan or provide a reference to where it is stored.]
Risk Log
[The Risk Log is normally maintained as a separate document. Provide a reference to where it is stored.]
Issue Management
[Insert the project’s issue management plan or provide a reference to where it is stored.]
Issue Log
[The Issue Log is normally maintained as a separate document. Provide a reference to where it is stored.]
Procurement Management
[Example: This can include information such as ensuring project team members are assigned computers, how development and test servers are procured or can go into more detail and include an acquisition strategy that details how the project will be staffed (e.g., performance based fixed price contract, CITS contractors).]
Compliance Related Planning
[Insert a list of compliance related processes the project must adhere to. For assistance with determining which compliance processes need to be followed visit
http://www2.cdc.gov/cdcup/document_library/project_assessment.asp
]
Appendix A: Project Management Plan Approval
The undersigned acknowledge they have reviewed the
[List the individuals whose signatures are desired. Examples of such individuals are Business Steward, Project Manager or Project Sponsor. Add additional lines for signature as necessary. Although signatures are desired, they are not always required to move forward with the practices outlined within this document.]
Signature:
Date:
Print Name:
Title:
Role:
Signature:
Date:
Print Name:
Title:
Role:
Signature:
Date:
Print Name:
Title:
Role:
APPENDIX B: REFERENCES
[Insert the name, version number, description, and physical location of any documents referenced in this document. Add rows to the table as necessary.]
The following table summarizes the documents referenced in this document.
Document Name and Version
Description
Location
[Provide description of the document]
APPENDIX C: KEY TERMS
[Insert terms and definitions used in this document. Add rows to the table as necessary. Follow the link below to for definitions of project management terms and acronyms used in this and other documents.
http://www2.cdc.gov/cdcup/library/other/help.htm
The following table provides definitions for terms relevant to this document.
Term
Definition
[Insert Term]
[Provide definition of the term used in this document.]
[Insert Term]
[Provide definition of the term used in this document.]
[Insert Term]
[Provide definition of the term used in this document.]
APPENDIX D: SUMMARY OF SPENDING
[You may double-click on the table to edit it according to the information applicable to this project.]
Budget ItemPY-1PYCYBYBY + 1BY + 2BY + 3BY + 4Total
Planning:
Budgetary Resources $ – $ – $ – $ –
$0.00
Outlays $ – $ – $ – $ –
$0.00
Development &
Implementation of
Project:
Budgetary Resources $ – $ – $ – $ –
$0.00
Outlays $ – $ – $ – $ –
$0.00
Total, sum of stages:
Budgetary Resources
$ – $ – $ – $ –
$0.00
Outlays
$ – $ – $ – $ –
$0.00
Operations &
Maintenance:
Budgetary Resources $ – $ – $ – $ –
$0.00
Outlays $ – $ – $ – $ –
$0.00
Total, all stages:
Budgetary Resources
$ – $ – $ – $ –
$0.00
Outlays
$ – $ – $ – $ –
$0.00
Government FTE cost $ – $ – $ – $ –
$0.00
PY: Previous Year; CY: Current Year; BY: Budget Year
[Insert appropriate disclaimer(s)]
PAGE
Revision Date:
Error! Unknown document property name.
Page 2 of 21
CDC_UP_Project_Management_Plan_Template_v1.1
_1234567890.xls
Sheet1
Budget Item PY-1 PY CY BY BY + 1 BY + 2 BY + 3 BY + 4 Total
Planning:
Budgetary Resources $ – 0 $ – 0 $ – 0 $ – 0 $0.00
Outlays $ – 0 $ – 0 $ – 0 $ – 0 $0.00
Development & Implementation of Project:
Budgetary Resources $ – 0 $ – 0 $ – 0 $ – 0 $0.00
Outlays $ – 0 $ – 0 $ – 0 $ – 0 $0.00
Total, sum of stages:
Budgetary Resources $ – 0 $ – 0 $ – 0 $ – 0 $0.00
Outlays $ – 0 $ – 0 $ – 0 $ – 0 $0.00
Operations & Maintenance:
Budgetary Resources $ – 0 $ – 0 $ – 0 $ – 0 $0.00
Outlays $ – 0 $ – 0 $ – 0 $ – 0 $0.00
Total, all stages:
Budgetary Resources $ – 0 $ – 0 $ – 0 $ – 0 $0.00
Outlays $ – 0 $ – 0 $ – 0 $ – 0 $0.00
Government FTE cost $ – 0 $ – 0 $ – 0 $ – 0 $0.00
Sheet2
Sheet3
template/Example Project Report 1
1.0. Introduction
Effective project management is considered an essential part of a company’s way to
success, as, to put it simply, its main purpose is to predict any risk that might affect a
project of a company and prepare the latter for it (Lock, 2013).
Since 2010, Netflix, world-leading subscription video on-demand streaming service,
has been producing its own content, such as series and full-length movies (Netflix,
2019). Such Original series or films could be considered as separate projects, which
are now the key to attracting new audiences and keeping existing Netflix subscribers
(Schomer, 2018). Therefore, it is critical for Netflix to make sure that all these projects
are carefully planned and are executed in a way as smooth as possible.
The aim of this report is to analyse the project management process of “Bird Box”, the
most successful Netflix movie project by far, thus gaining useful transferable
knowledge and providing recommendations for future similar projects.
1.1. Project Background
“Bird Box” is a 2018 movie produced by Netflix, which makes the film a so-called Netflix
Original, meaning it is available only on Netflix (Netflix, 2019; Netflix Media Center,
2019).
“Bird Box” is a sci-fi psychological drama thriller, which tells a story of a woman and
two children trying to survive in an apocalyptic world (Netflix, 2019). It premiered on
21st December 2018 (Netflix Media Center, 2019).
The movie is based on the eponymous novel by Josh Malerman, published in 2014
(Slauer, 2018).
Leading role in the film is performed by Sandra Bullock with the director being Susanne
Bier – both Academy Awards® winners (Netflix Media Center, 2019).
“Bird Box” became the most successful Netflix Original movie so far. Although it was
not highly appraised by critics, it generated significant amount of conversations and
feedback in social media and is the most watched Netflix Original movie at the moment
of writing (Lee, 2019).
Page 2 of 22
2.0. Project Management Landscape
According to Wysocki (2014), “a project is a sequence of unique, complex, and
connected activities that have one goal or purpose and that must be completed by a
specific time, within budget, and according to specification”. Following from this
definition, every project should have a goal and a solution.
Regarding goal, Netflix creates its own movies and series as a part of its vertical
integration strategy. Indeed, replacing licensed content with its own not only eliminates
the cost Netflix would otherwise have spent on licensing but also helps make the
service unique, thus keeping existing subscribers and attracting new ones (Ball, 2013).
Therefore, it could be stated that the goal of “Bird Box” is to support Netflix’s “worth-
to-watch, unique content” strategy and encourage more subscriptions to the service
(Nicolaou, 2019).
As for solution, firstly, the movie is based on a novel, which has already been proven
successful, thus increasing the chance of the film being well-received, too (Lawson,
2018). Secondly, Netflix hired award-winning leading actor and director to make sure
the movie was made at a high-quality level in order to truly engage audience
emotionally, thus encouraging word-of-mouth and publicity (Bushby, 2018).
Figure 1. The Four Quadrants of Project Landscape (Adapted from Wysocki, 2014)
Depending on how clear these goal and solution are, Wysocki (2014) offers a
framework, demonstrated in Figure 1, that helps define type of a project. The author
notes, however, that “clear-unclear” evaluation within this framework is rather
subjective and may change throughout the project being carried out. Moreover, as
Page 3 of 22
Rhyne (2008) points out, such frameworks for project management are rather general,
unified, thus need to be adapted to specific industries.
Regarding “Bird Box”, it appears that the goal and the solution of this project are rather
clear, thus the type of the “Bird Box” project could be defined as traditional (Wysocki,
2014).
Depending on the type of project, the latter would have to adopt a certain lifecycle
model, which, simply put, dictates a sequence in which various stages of the project
happen (Association for Project Management, 2012; Wysocki, 2014).
3.0. Project Management Life Cycle
According to Project Management Institute (2017), project life cycle “is the series of
phases that a project passes through from its start to its completion”. A typical project
life cycle usually implies four main stages – defining the concept, developing and
designing a plan, executing and basically carrying out the work, and ending and
closing the project (Burke, 2010; Larson and Gray, 2018; Maylor, 2010).
Figure 2. Project Management Life Cycle Model Approaches (Adapted from Wysocki, 2014)
Wysocki (2014) states that the choice of a specific lifecycle model would depend on
the clarity of goal and solution of the project (Figure 2). Considering that “Bird Box” is
a traditional project with both goal and solution being rather clear and straightforward,
it could be suggested that it should adopt linear lifecycle model, also known as
Page 4 of 22
waterfall method, demonstrated on Figure 3 (Association for Project Management,
2012).
Figure 3. Linear Life Cycle Model (Adapted from Wysocki, 2014)
Such model dictates that each of these stages is completed once and in the sequence
presented above. Such conditions are appropriate for a typical movie project, as they
are usual for a film project life cycle, which involves development, pre-production,
production, principal photography, wrap, post-production, and distribution stages
(Verhoeven, 2018). The latter could also be combined in a simplified life cycle model,
which includes only pre-production, production, and post-production (Katsiris, 2007).
4.0. Project Management Process Groups
Regardless of which lifecycle model a project adapts, it should be based on the five
process groups, demonstrated on Figure 2 (Association for Project Management,
2012; Project Management Institute, 2017).
Figure 4. Project Management Process Groups (Adapted from Association for Project Management,
2012; Project Management Institute, 2017)
4.1. Scoping (Initiating) Process Group
The overall aim of scoping (or initiating) process group is gaining authorisation to get
started with the project. It implies processes that help define the project, its objectives,
and what generally needs to be done, such as identifying stakeholders of “Bird Box”,
meaning those, who may affect or could be affected by the movie in question,
understanding and documenting concept of the film, and identifying significance of
“Bird Box” for Netflix (Eskerod and Jepsen, 2013; Haugan, 2011; Project Management
Institute, 2017; Wysocki, 2014).
Scope Plan Launch
Monitor &
Control
Close
Scoping
(Initiating)
Planning
Launching
(Executing)
Monitoring
&
Controlling
Closing
Page 5 of 22
Every project should have a project charter, which briefly describes the scope of the
work (HBR, 2012). Figure 5 demonstrates an example of such project charter with
flexibility matrix for “Bird Box”.
Table 1. “Bird Box” Project Charter with Flexibility Matrix
Netflix Original “Bird Box”
PROJECT CHARTER
Project Name:
Bird Box
Production Project Manager:
Susanne Bier
Production Companies:
Netflix
Bluegrass Films
Chris Morgan Productions
Commercial Project Manager:
Ted Sarandos
Estimated delivery date: November 2018
PROJECT DESCRIPTION
Project Background
“Bird Box” is a Netflix Original movie, based on a well-received anonymous book by Josh
Malerman.
Project Objective
Movie is intended to engage audience in order to keep current Netflix subscribers happy with the
streaming service, as well as attract potential customers to join Netflix. It should also positively
contribute to Netflix brand image as a provider of good-quality unique content.
Critical Success Factors
Movie should trigger active word-of-mouth and publicity, potentially become a viral trend and
discussion in social media. The number of new subscribers must keep increasing and the number
of cancellations should continue dropping.
Constrains
“High profile” lead actor should be involved, while maintaining budget reasonable. Audience should
be engaged emotionally.
Resources
3 production companies will be working on a movie; mostly standard equipment used for
production/post-production.
Project Authority
Cast, filming locations, storyboards, release date will be approved by Netflix investors and
commercial project manager.
FLEXIBILITY MATRIX
Least Flexible Moderately Flexible Most Flexible
Scope ●
Schedule ●
Resources ●
Source: (HBR, 2012; Haugan, 2011; IMDB, 2019; Netflix, 2019; Netflix Media Center, 2019;
Schomer, 2018; Sauer, 2018)
Page 6 of 22
This process group also implies hiring a project manager, however, as Rhyne (2008)
points out, such job title does not normally exist in film industry. Instead, functions of
the project manager could be performed by a number of people. Cheklich (2002) and
Brook (2005) believe that this role is usually taken by a director. Furthermore, Farrell
(1995) states that project manager responsibilities are also performed by producers.
In case of “Bird Box”, two main project managers could be identified – film director
Susanne Bier and Netflix chief content officer Ted Sarandos, who is responsible for all
Netflix Original projects (Netflix Media Center, 2019).
4.2. Planning Process Group
The aim of planning process group is to obtain clear understanding of what and when
has to be done, thus enabling project managers to select the most effective
approaches and methods to achieve success of the project (Association for Project
Management, 2015).
Planning process group of “Bird Box” is largely interlinked with scoping; hence it is
rather difficult to clearly define when scoping ends and planning begins (Rhyne, 2008).
Nevertheless, it could be said that this phase implies a more detailed specific plan of
action. In other words, while scoping is about finalising and approving an overall
strategy, planning involves establishing specific tactics, including building product
breakdown structure (PBS) and work breakdown structure (WBS), which are illustrated
on Figure 6 and Figure 7 accordingly (Haugan, 2011; Miller, 2009).
Create and produce a
Netflix Original movie
Bird Box
Story
Soundtrack and
Music
Footage
Promotion
Sceenplay
Individual script
for actors
Recorded soundtrack
for the movie
Purchased/licensed
music/songs
Recorded
scenes
Purchased
scenes
Movie
Advertising on
social media
Advertising on
Netflix
Direct mail to
Netflix subscribers
Publicity and
word-of-mouth
Figure 5. Product Breakdown Structure for “Bird Box” (Created in Microsoft Visio)
Page 7 of 22
Most researchers agree that planning process group in film industry also includes what
is called pre-production stage of filmmaking, which in turn implies finalising shooting
script, as well as creating storyboards and shoot lists, location scouting, hiring crew,
establishing what equipment to use, and finishing with necessary paperwork, e.g.
insurance and permissions (Picone, 2017; Rhyne, 2008).
Bird Box
Concept Pre-production Production Post-production Promotion Launch Closing
Initial script
Initial budget
Research for
lead actress
and main
support actors
Finalising
production
companies
Official approval
to start pre-
production
Finalise script
Shooting plan
Casting
Locations
Create storyboard
Create shoot lists
Create initial
shooting schedule
Casting for lead
actress
Casting for main
support actors
Casting for rest of
the cast
Location scouting
Finalise locations
Book shooting
locations
Hire/finalise
stunts
Finalise
budget
Finalise and
hire shooting
crew
Create list of
equipment &
costumes
Green light to
start shooting
Finalise shooting
schedule
Prepare locations
for shooting
Preparing actors
for shooting
Rehearsing the
scenes
Location 1 footage
shooting
Location 2 footage
shooting
Location 3 footage
shooting
Location 4 footage
shooting
Location 5 footage
shooting
Location 6 footage
shooting
Editing footage
Purchasing
additional footage
Final editing of all
footage
Creating
promotional clips
Posting
promotional clips
on social media
Creating text for
direct mail
promotion
Uploading movie
and movie profile
on Netflix
Movie premiere
event
Report on the
number of streams
Report on the
number of streams
Report on the
number of new
subscribers
Report on
audience
engagement
Report for
investors
Sending
promotional
emails to Netflix
subscribers
Figure 6. Work Breakdown Structure for “Bird Box” (Created in Microsoft Visio)
The next step after building the WBS, thus defining what work needs to be done, all
these tasks are scheduled. One of the most common tools for scheduling the work is
Gantt chart, which, to put it simply, demonstrates sequence and connections between
the tasks, as well as direct manager responsible for these tasks (Meredith, Mantel and
Shafer, 2016). Figure 8 illustrates “Bird Box” project schedule in a form of Gantt chart.
Page 8 of 22
Figure 7. Gantt Chart for “Bird Box” (Created in Microsoft Project)
Page 9 of 22
The Gantt chart above, apart from showing the sequence of tasks, also demonstrates
relationships between them. In order to illustrate these relationships and
dependencies, a so-called network diagram is used (HBR, 2012). With the aim of
saving space, Figure 9 presents such network diagram in a “collapsed” view, meaning
each box only provides the ID number of a task indicated in Gantt chart. Dark blue
boxes identify key milestones in the project schedule.
Figure 8. Network Diagram for “Bird Box” in collapsed view (Created in Microsoft Project)
Figure 10 demonstrates an example of how these task boxes look in a full view.
Figure 9. Example of Network Diagram for “Bird Box” in full view (Created in Microsoft Project)
Page 10 of 22
As Wysocki (2014) states, using network diagram helps represent “Bird Box” project
in a form of a story, as a graphical picture.
Bird Box Netflix
Original Movie
Project
Equipment People Finance Materials
Cameras
Monopods and
steadycams
Microphones
Audiorecorders
Production
Transportantion
Set
Editing
software
Lightning
Vagons
Personal
transport
Cars and vans
Monitors
Special effects
make-up
Location-
specific design
Cast
Project
management
Production
Stunt
Accountants
Secondary
actors
Lead actress
Extras
Directors
Producers
Chief content
officer
Cinematography
crew
Editing crew
Casting
managers
Set decorators
Costume
designers
Stylists
Sound
department
Visual effects
department
Animation
department
Location
managers
Investments Script
Story
Acting
Figure 10. Resource Breakdown Structure for “Bird Box” (Created in Microsoft Visio)
Page 11 of 22
What should also be considered during the planning process is the resources required
to execute established plans. In order to have a better understanding of the specific
resources and their number needed for the project, Project Management Institute
(2017) suggests building a resource breakdown structure (RBS), which represents all
necessary resources by category and type in hierarchical order. Figure 11
demonstrates such RBS for the Netflix movie in question.
4.2.1. Project Planning Considerations
To put it simply, both the difficulty and the task of planning is to answer questions such
as Who? What? When? How? How long? How Much? as accurately as possible in
order to minimise changes during the execution of the project plan (Lewis, 2006). The
challenge on the way to accuracy could be a general intolerance of traditional projects
to change combined with conditions of the modern project environment, which
influence traditional projects, such as “Bird Box”, even despite clarity of their goals and
solutions.
Consequently, it is important to understand that all projects happen within
contemporary project environment, which is characterised by high speed, change,
lower cost, increasing levels of complexity and uncertainty (Wysocki, 2014).
Furthermore, shortening of the product life cycle and increased customer focus should
also be taken into account (Larson and Gray, 2018).
Therefore, regardless of the type of a project, project managers should be flexible and
prepared for change and risk.
4.2.2. Planning Approach
“Bird Box” movie is a relatively large project with significant investments involved,
therefore it is unavoidable that “top-down” approach to planning would be applied,
which implies starting with defining an overall strategy for the film and identification of
key events in project lifecycle (Association for Project Management, 2015).
On the other hand, considering that some “Bird Box” stakeholders, such as lead
actors, director and creative department may have rather high influence on the project,
it could also be said that “collaborative” planning approach is in place, which ensures
Page 12 of 22
active involvement of the main stakeholders (Association for Project Management,
2015).
4.3. Launching (Executing) Process Group
Simply put, this process group implies that the plan, which had been created during
the previous phase, is executed (Haugan, 2011). Apart from activities described in
Gantt chart earlier in the report, launching of “Bird Box” project also includes
establishing team operating rules and scope change management process, as well as
maintaining communications and writing work packages (Wysocki, 2014).
4.4. Monitoring and Controlling Process Group
As simple as that, the aim of the monitoring and controlling process group is to keep
track of whether all tasks are executed as planned and whether this plan helps to
achieve established goals (HBR, 2012). In other words, this group includes tracking,
reviewing, and regulating the progress (Project Management Institute, 2017).
Consequently, it is logical to suggest that it implies establishing performance checking
and reporting systems, monitoring risk, discovering and solving problems or changes
(Wysocki, 2014).
Although during this phase it is critical to monitor adherence to the plan, the focus
should always remain on the final objective rather than the plan itself (Project
Management Institute, 2017). Therefore, it is important to clearly define what data
exactly should be collected, and how it should be analysed and reported (Larson and
Gray, 2018).
4.4.1. Scope Management
Scope management not only ensures that necessary work for “Bird Box” is accurately
defined but also controls that no extra tasks are performed (Burke, 2010). In other
words, the aim of scope management is to make sure that all tasks are relevant to the
objectives of the “Bird Box” (Association for Project Management, 2015).
One framework that helps managing scope is a so-called “Scope Triangle” (Figure 12).
In a way, it is an extended version of widely known “Iron Triangle”, which points out
Page 13 of 22
three main constrains of project management in general – time, cost, and scope
(Atkinson, 1999; Wysocki, 2014). The “Scope Triangle” also includes quality, resource
availability, and considers potential risk that may affect all of the above (Wysocki,
2014).
Another essential tool for scope management purposes is work breakdown structure,
discussed in Part 4.2. (Meredith, Mantel and Shafer, 2016).
Figure 11. Scope Triangle (Adapted from Wysocki, 2014)
This process may also include managing changes to scope baseline (Project
Management Institute, 2017). However, considering that “Bird Box” is a traditional
project, hence highly intolerant to change, any scope modifications while executing
the project plan should be minimised or avoided at all.
4.4.2. Schedule Management
Schedule management refers to both time and resource scheduling and implies
developing, maintaining, and communicating these timetables to appropriate project
stakeholders (Association for Project Management, 2012).
It is important to note that during the initiating stage, project schedule of “Bird Box” is
slightly less detailed compared to the one after executing phase, as at the beginning
of the project life cycle the amount of available details is often rather limited
(Association for Project Management, 2012). For instance, full information on the film’s
post-production schedule may only be available after production stage is completed.
Page 14 of 22
In addition to classic Gantt chart, “Bird Box” should also take advantage of industry-
specific scheduling software (Association for Project Management, 2015). For
example, film production process consists of a large number of interdependent tasks
and involves a significant number of stakeholders (Ouyang et al, 2008). Therefore,
utilising special movie production scheduling programmes could make planning and
monitoring schedules even more efficient.
4.4.3. Cost Management
Cost management is defined as the “process of estimating and justifying costs in order
to secure funds, controlling expenditure and evaluating outcomes” (Association for
Project Management, 2012). It consists of two components – planning and controlling
(Wysocki, 2014).
Cost planning (or estimating) could include different types of costs, such as direct,
indirect, fixed and variable, time-related, labour (Burke, 2010). One of the most
common ways of estimating these costs is creating budget document or a cost
breakdown structure (CBS), which is often based on work breakdown structure. Figure
13 demonstrates an example of a simple CBS for “Bird Box” movie.
Total Budget
$19,781,000
Screenplay
~ $60 700
Production and
Post-production
~ $1 800 000
Main actors
~ $12 000 000
Reservation of credits
~ $2 500 000
Pre-production
~$3 420 000
Figure 12. Cost Breakdown Structure for “Bird Box” (California Film Commission, 2017; Mendelson,
2018; Paysa, 2019; Tassi, 2019)
Nevertheless, within cost management process, a rather more important technique for
“Bird Box” is investment appraisal, which is a tool for identifying attractiveness of an
investment (Association for Project Management, 2012). Indeed, with Netflix being
ready to spend billions a year for its Original content, the budget itself is not such a
significant criterion for the movie (Morris, 2018). It appears that Netflix focuses on what
Page 15 of 22
content to invest in, rather than how much. Therefore, quality management could be
even more crucial for the service.
4.4.4. Quality Management
Quality management ensures that the end product meets stakeholders’ requirements
and is fit for its purpose (Association for Project Management, 2012). Starting point in
this process is defining conditions of satisfaction (COS), which include quality
requirements (Wysocki, 2014). Table 1 illustrates some of the main quality
requirements for “Bird Box” movie project with quality control plan, which identifies a
way to ensure that the requirements are met (Burke, 2010).
Table 2. Main Quality Requirements for “Bird Box”
Area Task Quality Requirement Control method
Pre-
production
Script Engaging, relevant to thriller
genre
Review by producers
Cast Famous names with
recognised talent and good
reputation
Supervised by casting
managers
Shooting
schedule
Convenient for main actors,
efficient
Reviewed and agreed
with appropriate
stakeholders
Production Shooting Stable picture – camera
stabiliser
Supervised by
shooting crew and
director
Location design Accurate to the script and is
carefully maintained
throughout shooting
Supervised by props
manager, set
designers, and
director
Post-
production
Editing According to the script and
within the overall concept
and genre of the movie
Supervised by
director
Video Picture quality 4K/Ultra High Resolution Review of the file by
Netflix
Sound Dolby TrueHD Review of the file by
Netflix
Source: (Adapted from Burke, 2010)
Page 16 of 22
4.4.5. Resource and Procurement Management
Resource management implies acquisition, planning, and allocating internal and
external resources required to deliver the “Bird Box” project (Association for Project
Management, 2012; Haugan, 2011).
In case of Netflix’s project in question, internal resources are basically limited to
providing the platform to promote and demonstrate “Bird Box” movie.
Acquisition of external resources for the movie mainly happens through procurement
process (Association for Project Management, 2012). “Bird Box” is produced by two
production studios, outsourced by Netflix (IMDB, 2019; Project Management Institute,
2017). In turn, these studios and separately hired film director are further outsourcing
cast and shooting locations. Moreover, budget for the movie is approved and defined
by Netflix’s investors.
4.4.6. Human Resource Management
The first and crucial part of human resource (HR) management implies recruiting
people and making sure they are motivated to do the job at a necessary level (Murdick,
1976). People within “Bird Box” project could be divided into core team, meaning
those, who are directly responsible for creating the movie, e.g. actors, director,
production crew, producers, and support team, e.g. administrative departments of
production companies, catering team, cleaners, delivery companies (CoEPM², 2016).
When hiring main members of the core team – lead actress and director – Netflix had
to properly motivate them. Motivation model, which was applied, is illustrated on Figure
13.
NEEDS OR
EXPECTATIONS
result in
DRIVING FORCE
(behaviour or
action)
to achieve
DESIRED
GOALS
which provideFULFILMENTfeedback
Figure 13. Basic Motivation Model (Adapted from Mullins, 2013)
Page 17 of 22
While there exist a large number of content theories, which help identify needs of a
person, there is one that summarises most of them – Herzberg’s two-factor theory.
The latter defines hygiene factors, meaning basic needs, such as adequate working
conditions and salary, and ‘motivators’, which include sense of achievement,
recognition, personal growth (Mullins, 2013).
Netflix has rather successfully managed to identify and fulfil especially ‘motivators’
need, when recruiting Sandra Bullock. While appealing to current trend among actors
to engage in streaming media as a proof of their progressiveness, Netflix has also
thought through to hire rather “big” names for secondary roles, e.g. John Malkovich
and Sarah Paulson, thus contributing even more to the reputation of the movie project
(Kenny, 2016; Lee, 2019).
4.4.7. Communication and Stakeholder Management
Project Managers
(Director and Chief
Content Officer)
Screenplay
writer
Novel
author
Actors
Producers
Composers
Filming
crew
Editors
Stunts
Investors
HR
Accountants
Netflix
CEO
Contractors
Netflix
current
subscribers
Potential
Netflix
ssubscribers
Government
agencies
Netflix
competitors
Figure 14. “Bird Box” Stakeholders’ Network Map (Adapted from Larson and Gray, 2018; Project
Management Institute, 2017)
Poor communication may lead to misunderstanding of requirements, unclarity of goals,
ineffective plans and schedules, in other words, may cause project to fail (Association
Page 18 of 22
for Project Management, 2012). Consequently, the aim of communication
management is to provide and support necessary links among “Bird Box” stakeholders
(Burke, 2010; Project Management Institute, 2017; Wysocki, 2014).
The process should start with identifying stakeholders of “Bird Box” project. Figure 14
demonstrates network map of stakeholders of the movie.
“Bird Box” success may only be guaranteed if all stakeholders are happy with the
project processes and results, therefore their interests are considered in the “Bird Box”
project schedule (Association for Project Management, 2015).
Proper communication could significantly enhance stakeholder management process.
Figure 15 shows justification for different means of communication that were applied
during various stages of this process for “Bird Box”. Each of the types may be effective
or not, depending on specific objectives of the communication (Eskerod and Jepsen,
2013).
Table 3. Dominating Types of Communication with Stakeholders during Project Management Process
Interpersonal communication Impersonal Communication
Scoping
(Initiating)
• Informal calls
• Face-to-face meetings
Planning • Face-to-face meetings
• Calls
Launching
(Executing)
• Face-to-face communication
on set
• Planning/monitoring
software
Monitoring
and
Controlling
• Face-to-face communication
on set
• Planning/monitoring
software
Closing
• Face-to-face meetings
• Calls
• Presentations
Source: (Collider Interviews, 2018; Eskerod and Jepsen, 2013; HeyUGuys, 2018; Kinowetter, 2018)
Page 19 of 22
4.4.8. Risk Management
“Bird Box” as a traditional project should especially be aware of any risks that may
affect it. Risk management process, illustrated in Figure 16, helps to identify and
manage such risks (Project Management Institute, 2017).
Initiate Identify Assess Plan responses
Implement
responses
Figure 155. Risk Management Process (Adapted from Association for Project Management, 2012)
Although project managers of “Bird Box” were successful with avoiding major
unpredictable changes during most of the project stages, Netflix did face a rather
manageable external risk at the very end of the project life cycle – California fires
during planned release date (Malkin, 2018). As a result of such environmental disaster,
Netflix decided to postpone movie premiere to late December, thus making it a pre-
Christmas release (Malkin, 2018).
Table 4. Risk Assessment Matrix for “Bird Box”
Risk Categories
and Risks
Scope Triangle Elements
Scope Time Cost Quality Resources
Technical N/A N/A Damaged
equipment
needs to be
replaced
Unmet
video/sound
quality
requirements
Equipment
unavailability
or
inaccessibility
Project
Management
Change of
project
manager
Change of
project
manager
N/A Missed
quality review
N/A
Organisational N/A N/A N/A N/A Unforeseen
accidents with
team
members
External N/A Environmental
disasters may
influence
schedule
Environmental
factors can
damage
expensive
equipment
Viewers’
Internet
connection
may
compress
video quality;
Viewers’
hardware
may affect
sound quality
Unforeseen
accidents with
team
members
Source: (Adapted from Wysocki, 2014)
Page 20 of 22
Apart from such external threats, risks may come from technical, organisational, and
project management areas (Wysocki, 2014). Table 2 above provides a way of
identifying different risk categories, which have high impact on “Scope Triangle”
elements of “Bird Box”.
No matter what type of risk affects “Bird Box” project, one of the best options to
manage it could be so-called “rapid-results initiatives” method, which implies executing
small, quick projects that are mini-versions of the main project’s result (HBR, 2012).
Such method has proven to be effective as, most importantly, it is results-oriented and
fast (HBR, 2012).
4.5. Closing Process Group
Closing process group, as the name suggests, is the last one in the project life cycle.
Firstly, it involved gaining approval of having met the requirements, which, in case of
“Bird Box” meant gaining approval to release the movie on Netflix (Wysocki, 2014).
Furthermore, closing the project implied conducting post-release audit of the number
of streams, as well as monitoring increase or decrease in the number of Netflix
subscribers, and writing and presenting report of the above to investors (Wysocki,
2014).
Table 5. Project Management Process Group and Knowledge Area Mapping
Knowledge
Areas
Project Management Process Groups
Scoping
(Initiating)
Planning Launching
(Executing)
Monitoring &
Controlling
Closing
Integration ● ● ● ● ●
Scope ● ●
Schedule ● ●
Cost ● ●
Quality ● ● ●
Resource ● ●
Communications ● ● ●
Risk ● ●
Procurement ● ● ● ●
Stakeholder ● ● ● ●
Source: (Adapted from Project Management Institute, 2017)
Page 21 of 22
As it has been mentioned before, although Netflix’s “Bird Box” did not necessarily find
recognition from critics, it managed to achieve record-breaking number of streams in
the first week after being released – 45 million (O’Connor, 2018). Moreover, it has
generated enormous feedback on social media with people creating funny memes and
even undergoing “#birdboxchallenge” (Herbert, 2019). Therefore, it could be
concluded that “Bird Box” project achieved established goal, hence may be defined as
rather successful.
All processes within these five process groups are defined by ten knowledge areas
(Table 3), which are fields of specialisation that are often used in project management
(Project Management Institute, 2017; Wysocki, 2014).
5.0. Conclusion
This report analysed all five project management process groups of the most
successful Netflix Original project by far, a 2018 movie “Bird Box”. Although it appears
to be a rather traditional project, some of its “Scope Triangle” elements, such as time
and cost, seemed to be relatively flexible. Moreover, the lines between these process
groups and stages of the life cycle often appeared rather blurred. Such adaptability
indeed proved to be central to successfully executing the project within rather unstable
contemporary project environment.
In addition, collaborative approach to planning, use of well-suited for film industry
software for scheduling and monitoring the execution, and proper communication with
constant catch-ups on the status of the project clearly contributed to minimising the
number of risks that affected “Bird Box” to only one, external environmental risk, i.e.
California fires, which caused a smoothly handled change in the release date.
Consequently, we may agree with the approach of Wysocki (2014) to project
management – no matter what standards the industry dictates, actual project
management should also consider common sense and unique conditions while
planning, scheduling, and executing the project.
Page 22 of 22
5.1. Recommendations
The case of “Bird Box” could suggest two major recommendations for future Netflix
projects. Firstly, it is important to choose the right strategy for attracting first-class
actors and directors. Apart from basic financial motivation, another motivator appears
to be highly influential – the desire to be in trend, i.e. having in their portfolio a project
with a major streaming service, and working with other “big” names. Not only is it
effective but it also allows to significantly decrease the budget of the movie, as major
celebrities agree to star for a lower price in exchange for high reputation of a project.
Secondly, closing stage of the project should not end with the release and financial
report but continues with monitoring and actively engaging in post-release audience
discussions and feedback, in particular on social media. It could significantly increase
publicity around a movie and Netflix in general, as well as encourage more audience
to watch it or become subscribers.
5.2. Limitations
Considering certain “backroom” industry standards, such as numerous nondisclosure
agreements, it was rather difficult to access detailed and accurate data on, for
instance, shooting schedule and cost breakdown structure. Nevertheless, the analysis
conducted in the report attempted to minimise dependency on such detailed data,
whilst focusing more on the overall approach and objectives of the project.
In addition, the applicability and relevance of standard project management practices
and frameworks for film industry specifically is sometimes questionable, as the latter
has own well-established tactics and descriptions, hence not always analysis fully
adhered to such theories.
template/Example Project Report 2
1.0 Introduction
Mascot Development project is a project undertaken as a mandatory requirement for
the module of Project Management that is being conducted by Birmingham City
University in United Kingdom. The aim of the module is to provide wide range of
theories, concepts and approaches to project management besides to critically
evaluate project management knowledge areas and critique project management
software tools.
1.1 Purpose of this document
In this document there is overall description of the Mascot Development. It includes
need to be done. On top of that, description of work experience gain from this
project was also included in this document. Whole description of the designing face
and cost is included in this document.
1.2 Intended Audience
The intended audience of Mascot Development project is all project stakeholders
steer group including the project sponsor, senior leadership management, project
team and consumers.
2.0 Assumptions and Constraints
Assumptions in project management according to Sharp (2005), is a factor that, for
planning purposes, are considered to be true, real or certain without proof or
demonstration. Additionally, assumptions in project management can be divided
2
into few which resource assumption, budget assumption and scope assumption. It
is important for one to identify the assumption and later to know the project
constraints. Goodrich (2017) stated that limitations placed upon the project that the
project manager and team to work within is known as project constraints. She
added that the common constraints usually cited in project management are scope,
schedule, and cost or known as the “iron triangle” of project management. On top
of that, the project may be constrained by quality requirements, resources and risk
tolerances. The constraints dictate the perceived quality of the project as it is
related to one and another as if one constraint changes, there will most likely be
an impact on the other constraints. As for this project, it is a great opportunity for
the company to earn revenue that is totally different from the business as usual
revenue and as this is something new in contemporary Malaysia context. Looking
at Disney, Marvel and many more, this projects would totally be a fresh local
product for Malaysia’s citizen. A lot of things later can be done once the audience
can associate and familiar with the mascots. Not only earning extra revenue,
MPRN can as well increase the listenership of their radio stations’ when the listener
associate the mascots with the radio stations’. The main constraint for the project
will be time as the time proposed for the project to be completed within 12 months.
On top of that, looking at the next constraint in this project will be the cost and
resources. Huge amount of money incurred in developing this project besides lack
of resources specifically skilled manpower to create icons for the mascots
development.
3.0 Project Landscape: Mascots Development for Media Prima Radio Networks
(MPRN)
▪ Location: Petaling Jaya, Selangor
▪ Project Manager: Danny Chin Wai Chung
3
▪ Project Owner: Media Prima Radio Networks (MPRN)
▪ Project began: December 2015
▪ Project completed: May 2017.
▪ Project cost: £53,000
Project is defined as a sequence of unique, complex and connected activities that
have an objective or goal that has start date and end date to be completed within
budget, and according to specification (Wyscoki, 2009). There are four quadrants
of project managements identified as such:
Figure 1: Contemporary Project Landscape by Wysocki (2009)
Mascot Development project is noted as traditional project. Traditional project
defined by Wyscoki (2009), as a project that is built before any work is done on the
project and have a detailed plan. The plan is based on the assumption that the
goal is clearly identified. In addition, project definition and initial scoping activities
4
contributes to the success of this approach as it is based on correct specification
of the goal made. The rationale of this project for the company is that to create a
real connection between the audiences, to communicate brand value, brand
recognition and recall, humanizing the brand and the main rationale which, to
generate new revenue. Below relatively related to development of mascots project
for MPRN:
Sequence of Activities: The development of mascots includes the development of
icons illustration. The illustrated icons were then followed by the development of
mascots and the final product delivery.
Complex Activities: The most complex activities in this project were the process of
initiating the idea and develop the icon illustration in order to develop real mascot
then.
Connected Activities: All the activities include in the project were interconnected
from the brainstorming for ideas, illustration of the icon to build the mascots, and
the following mascots development.
One Goal: The mascots project was initiated with a goal to extend MPRN business
and generate revenue from business to consumer and to further explore more
doable project in the future.
Specified Time: It took the entire project 12 months to be completed.
Within Budget: The mascots were developed with a budget of £53,000.
5
According to Specification: Danny, the project manager ensured that the mascots
developed according to the illustrated icons.
4.0 Project Management Life Cycle
According to Westland (2006), project management life cycle is an effective way
to produce a set of deliverables within clearly specified time, cost and quality
constraints. Projects differed from standard business operational activities as they
have certain criteria such as start date and end date (Akpabot, 2018). Additionally,
it has an approved budget, unique in nature, as it does not involve repetitive
processes. According to Gray and Larson (2006), project life cycle consist of four
phases that is defining, planning, executing and delivering. Different phases have
different process and all those four processes correlate one to another.
Figure 2: Project Life Cycle
6
Initiation or defining is the first phase, and during this phase a business problem or
opportunity is identified and a business case providing various solution options is
defined. For this project, it was initiated based on the idea to expand the business
model of the company. During this phase, a goal was setted up based on the
opportunity seen in today’s market. Ground research has been done in order to
ensure that this project is realistic to be executed. Once the goal has been
identified, the project manager delegated the project tasks to the team member.
Project manager according to PMBOK Guide (2017), defined as the person
assigned by the company that is responsible to lead the team and achieve the
project objectives. On top of that, project manager also involves in all
communication within the team, and to the stakeholders besides works to balance
the competing constraints on the project and resources available. The project
manager for this project ensured that all update on mascot development been
updated and ensured that the project runs accordingly. For mascots development
project, below are the team members that responsible to ensure the project runs
accordingly:
Name Roles
Seelan Paul Project Advisor, CEO MPRN
Tan Leng Ean Project Advisor, General Manager
Danny Chin Wai Chung Project Manager
Faizah Ahmad Kamari Financial Manager
Alex Poon Digital and Interactive (Icon
Illustration)
Nurul Fatin Aqilah Business Strategy
Taro Choo Jian Yaw Brand, A&P (Mascot Development
Team)
Table 1: Task and Roles
The next process is to plan for the project. All matters pertaining to the
development were discussed during this phase. The most important things that
7
were taken into consideration was the estimated time taken for the project to be
completed, the total cost of the project, the required resources, the project
sequence and project schedule. On top of that, a risk management plan was also
prepared during this phase and finally to pitch overall project plan to the senior
management level for their approval to launch the project.
To execute the mascot development project, the project manager, Danny Chin has
delegated task to its team member. The first task in executing the project is to meet
with the external party that are responsible to help with the mascot development
illustration or known as icons sketching phase. Before sharing the brief of how does
the mascot wants to be developed, the team had a small session within the team
to identify each character of the mascots to cater with the radio business based on
the listernership and audience background. The character development took about
two weeks before each ones were identified. Taro Choo, person in charge for the
brand custody later communicate with the third party company that appointed by
MPRN to icons illustration. The illustration of the icons took about three weeks and
after few amendments made, the final icons illustration finally approved by the
board of management. Along the phase, a lot of discussion and meetings been
held to ensure the plan of the mascots development going smoothly. Changes
have been made along the way, as the team doesn’t satisfy with certain progress
on the development. After final illustration agreed by the project owner, the next
step is to deliver the project.
The third party, Mascot Enterprise that was responsible to produce the mascots for
the company successfully delivered the project delivery in this project. During this
delivery phase, it is important to look at three success criteria that are cost, time
and quality (Atkinson, 1999). The final mascot managed to be delivered according
to the specification requested and according to timeline. During this phase, the
8
project manager released the hired company from the list as they have delivered
the mascots. Additionally, all documents for payment been done in this phase and
soft copy of all documents been documented for safe keeping and future
references.
5.0 Planning, Managing and Controlling
Next phase after the defining phase is to plan in-depth. For this project, this
planning phase is the most crucial phase for the project manager to plan the project
thoroughly. During this phase, the project manager has decided that the project
must be done within a year time, and came out with the budget of £5500 per
mascot. The total budget allocated for the mascot development for four radio
stations would be £53,000 including all other incurred costs. The project manager
ensured that all resources sorted accordingly in order for the project to runs
smoothly. Main resources used for the project are equipment, people, and facilities.
The project is not an easy project to be done, as to create a mascot, a skillful
designer is needed to sketch and illustrate the icons for the mascots. The company
has outsourced third party Company to create the mascot development from the
scratch. The process of turning a mascot is not an easy task, as it requires a lot of
time and little things of creativity to turn to a virtual mascot. Below are the costs
structures for this project:
Details Estimated Cost Actual Cost
Icons sketches illustration £3,000 £2,800
Mascots development £8,000 £8,074
Mascots postage from Singapore
to Malaysia
(Additional) £250
Mascots Launching (Event) £15,000 £12,460
9
Mascots (Manpower: 4 people) £100 x 4: £400 £400
Advertising and Promotions
(Media)
• TV coverage
• Newspaper
• Radio Airtime
• Outdoor (Billboard)
£25,000 £29,000
TOTAL £51,000 £52,984
Table 2: Cost Structure
Additionally, to ensure the project runs accrording to the plan project management
software can be applied in any projects. Gantt chart has been used in this project.
According to Posner and Applegarth (2002), Gantt chart is probably the simplest
project management tool to understand, the easiest to be used and the most
comprehensive as it allows you to predict the outcome of time, cost, quality and
quantity. Burke (2013) added that Gantt Chart is one of the most known to be used
for planning and control documents for communicating schedule information as it
includes the guideline for the project phases from initiating to closure. Network
analysis and precendence table has been used to see how does one task related
to one another. Below is Gantt chart and network analysis table for this project:
10
Figure 3: Gantt Chart for Mascot Development
11
Figure 4: Network Diagram, Mascot Development
6.0 Project Risk Management & Managing any Potential Scope Creep
Project risk is one of the important elements that shouldn’t be overlooked.
Firmenich (2017) stated that project risk management should be kept as simple as
possible and should be conducted as detailed as necessary. All the risk need to
be tied with mitigation plan should it happened. Risks is subject in every project as
some can be foreseen and plans can be put in place if they occur; whilst some that
cannot be identified must be dealt with as they occur (Wysocki, 2009). For this
project, the project manager and project team go through several processes
started with risk identification. During this phase, the whole team were brought
together in a meeting room to discuss and identify the specific risks. Additionally,
to develop a risk management plan is a significant part of the planning process.
Wysocki (2009) supported that it is important to plan for risks management as the
12
more complex and uncertain the project; the more important it is to have a dynamic
and maintained risk management plan. For this project the team assess the risks
through risk categories as below:
Risk
Categories and
Risk
SCOPE TRIANGLE ELEMENTS
Scope Time Cost Quality Resources
Technical New
Technology,
using designing
software
Time
constraint
Under
budget
End product
quality
Experience
level and
skill
Project
Management
Trend spotting
risk – investing
on a product
with uncertainty
of program’s
success
Schedule
and
Timeliness
Funding Mascot not
meeting
expectation
in terms of
strong
emotional
connection
with
consumers
Satff
Availability
Organizational Communication
with
stakeholders
x Uncertain
return of
investment
depending
on quality
of product
and mar
keting (IPs
mascot)
Platform
deliverables
not meeting
expectations
Finding the
right partner
for
collaboration
External Consumer
acceptance
x x Licensing
and Piracy
issues
x
Table 3: Risk Categories
Scoping in project management known as initiating phase according to Wysocki
(2009). During this phase, in developing the mascot project, the main phase done
was to establish the aim and goal for this project, which to extend the business
model of MPRN and to generate more revenue through business to consumer.
During this scoping phase, the project manager was appointed and a thorough
13
feasibility was done to ensure how relevant was this project to be executed. In
addition, stakeholders and clients’ consideration were taken into account to ensure
the deliverables was pleased. However, scope creep may occur at any point of
after the project begun. According to Abromavici (2000), one of the most sneaking
problems commonly faced by project managers are scope creep.
Khan (2006) stated that the most important function of a project manager is to
manage the scope. The claim supported by Wijetunge (2017), that managing
scope is an important competency for project manager. The successful
management of other key project management areas including time, cost and
quality based on the effectiveness of scope management. To manage project
scope, different project manager may take different approach as it can be further
sub-divided into its components that include project initiation, scope planning,
scope definition, scope verification, and scope change control (Gardiner, 2005). As
for this mascots development project, to manage potential scope creep, the project
manager must first understand the project vision and know project driver’s
priorities. Deliverables must then be defined and as a project manager, they should
expect that there would be scope creep along the project. Hence, it is important to
implement change order forms early and educate the project drivers on processes.
Danny managed the scope creep by breaking the approved deliverables into actual
work requirements when the deadline for icons illustration overdue. Not only that,
to make sure the projects well organize, the project manager breaks the project
down into major and minor milestones and be sure to follow the timeline.
7.0 Project Stakeholder Management & Managing Client Expectation
It is important for project manager to take project stakeholder into consideration.
Stakeholder in project management is defined as the ones who can affect the
14
achievement or is affected by the achievement of an organization’s goals (Vijaya,
2014). Every project is unique on its own as it depends on the style of the project
manager, type of project, the business criticallity, scope and the change
acceleration process involved in execution. In this mascot development project, the
main stakeholder are project team, Media Prima board of directors which main
investor for this project, Innogenetic Studio and Mascot Enterprise which was hired
outsource company in developing the mascots, workers that involved with the
project, media and customers. Danny, the project manager responsible to attain
the project objectives, hence he monitored the needs of the sponsors and other
stakeholders besides managing the project life cycle and the progression of the
project team. Managing stakeholder perceptions and expectations is about
generating agreement and harmony between different perspectives held by the
stakeholders. It is important to ensure that the project to move in the same direction
o achieve success. Newcombe (2000) claimed that most stakeholders look at the
project from different perspectives and hold different expectations.
According to Gardiner (2005), core competencies required by project managers
can be divided into two categories which soft skills and hard skills. The project was
well managed by Danny, as he is very good in both soft skills and hard skills to
lead, communicate, and negotiate also to solve problem complied with planning,
scheduling and controlling along the project development. Danny took an approach
to understand the stakeholders during the initiating phase whereby he ensure that
stakeholder’s expectations clash from one to another to encourage the parties to
talk to each other with a view to resolving areas of conflict. This supported by
Gardiner (2005), that through this situation, project manager often acts, as
negotiator to find the best solution that meets as many needs as possible.
15
8.0 Project Closure
Project closure is an end of project administration based on the fulfillment of
stakeholders’ needs and expectations. All tasks must be closed and all financial
details must be completed and project records must be archived and documented.
The project manager responsible to ensure that all deliverables been provided to
the stakeholder and must offer an opportunity for them to provide any feedback
(Gardiner, 2005). For this mascots development project, the project manager
closed the project by giving a week of documents compilation pertaining to the
poject and organised a post-mortem meeting a later. During the meeting, the
project has been evaluated and reviewed among the team. Feedback has been
noted during this phase such as scope creep and any mistake done. This phase is
one of the phase that shouldn’t be overlooked as this is an important opportunity
to capture lessons learned throughout the project, with respect of both project
development of staff, evolution of project management methodology and also to
reward everyone’s efforts. The project manager concluded the project is success
as the team managed to overcome critical success factor; scope, cost, and time
besides achieved project mission and managed to launch the project accordingly.
9.0 Conclusion and Recommendation
In a nutshell, the project has been successfully delivered and the preparation of a
project requires a detail project management plan and a structured management
strategy, being aware of type of project and following Project Management Life
Cycle phases in order to conduct the project efficiently. Besides that, risk and
scope creep can be happened naturally and without warning, hence it is important
to be prepared for any should it happen. Stakeholders expectations have to be
managed, not only knowing what they want before planning and doing it
accordingly, but also by analyzing if the project fulfilled their expectation,
16
by measuring the results and comparing with the initial goals. Last but not least, it
is essential for project manager to do project closue that involve project evaluation
that inludes all the parameters of the project. The project was successfully
executed with few hiccups along the way. For future recommendation, it is best for
project manager to come out with a thorough planning and consideration. On top
of that, the project manager may opt for other project management software to
create project milestones and work based system.
APPENDIX
17
Gantt Chart
18
Mascots End Product
19
template/Final Project Report[3]
Web Project
Version: 1.0
Final Project Report
Date: 2006-10-01
Web Project
Version 1.0
Revision History
Date
Version
Description
Author
2002-00-00
0.01
Initial Draft
Table of Contents
41.
Introduction
1.1
Purpose of this document
4
1.2
Intended Audience
4
1.3
Scope
4
1.4
Definitions and acronyms
4
1.4.1
Definitions
4
1.4.2
Acronyms and abbreviations
4
1.5
References
4
2.
Background and Objectives
4
3.
Organization
4
3.1
Project Manager
4
3.2
Project Group
4
3.3
Steering Group
5
3.4
Customer
5
3.5
Others
5
4.
Milestones
5
4.1
Remarks
5
5.
Project Results
5
5.1
Requirements
5
5.1.1
Requirement Compliance Matrix
5
5.1.2
Requirements Compliance Summary
6
5.1.3
Remarks
6
5.2
Work Products and Deliverables
6
5.2.1
Remarks
6
6.
Project Experiences
6
6.1
Positive Experiences
6
6.2
Improvement Possibilities
7
7.
Financials
7
7.1
Project Cost Summary
7
7.2
Work per Member
7
8.
Metrics
7
8.1
Milestone Metrics
7
8.2
Effort Metrics
7
Introduction
Web Project is the project undertaken as a mandatory requirement for the course “Distributed Software Development” that is being conducted mutually by Malardalen University in Vasteras, Sweden and University of Zagreb. The aim of the course is to provide a distributed environment to develop software. In this course we have to develop the Distributed Software in two teams. But in our project we are not distributed because we are working on the same side. But we hope that we will make this Project on time.
Purpose of this document
In this document there is overall description of the Web Project. It includes what we did. There is also description of the work experience gain from this project. Whole description of the designing face and cost is included in this document.
Intended Audience
There are some intended audiences of this project in which our steering group, customer and the Project members are included. There are also some students who want to continue this project later on.
Scope
The project is aimed to provide a central place for organizing, planning and tracking projects that are developed in a distributed environment. It therefore is a web application that should be compatible with majority of browsers to provide user friendly Interface for project administrator, project leaders and project members working far apart all around the world.
Definitions and acronyms
Definitions
Keyword
Definitions
Distributed software Development
Process in which the software is being developed by different teams working at least 30 m apart physically.
Acronyms and abbreviations
Acronym or
abbreviation
Definitions
References
“Web Project” Final Project document.
Background and Objectives
The customer needs Microsoft Project (MSP) as Web Base Project to handle the Different projects in any kind of Software House. It was previously developed by Microsoft for project Management. Bit was not the Web Based so here we made it as a Web Based.
Now we developed a project in which is just like MS Project. Here we have four main actors in the project i.e. Administrator, Project Leader, Project Member and Customer . There are different roles of all the actors depending on their positions. There are different main activities in the project like View, Delete and Edit different thins regarding to the Project.
Organization
Project Manager
Khuram Shehzad is the Manager of the group.
Project Group
Name
Responsibility
Khuram Shehzad
Project manager, Analysis, Implementation, Designing, DB Design
Ahsan Jawed
Implementation, Documentation, Analysis, DB Design
Imran Afzal
Implementation, Documentation, Designing, Analysis
Shoaib Ahmad
Implementation, Analysis, Documentation, Analysis
Abdullah Anjum
Integration, Testing, Analysis
Steering Group
Ivica Crnkovic
(MdH)
Rikard Land
(MdH)
Mario Zagar
(FER)
Igor Cavrak
(FER)
Customer
Igor Cavrak
Others
Milestones
Id
Milestone
Description
Responsible Dept./Initials
Finished week
Metr
Rem
Plan
Forecast
Actual
Week
+/-
M-001
Project Description & Plan
17-11-05
0
0
17-11-05
Y
Good
M-002
Requirement Definition
17-11-05
0
0
17-11-05
Y
Good
M-004
Project Design
24-11-05
0
0
24-11-05
Y
Good
M-005
Revised Project Plan
01-12-05
0
0
01-12-05
Y
Good
M-006
Project Status Presentation
15-12-05
0
0
15-12-05
Y
Good
M-007
Final Presentation & delivery
19-01-06
0
0
19-01-06
Y
Excellent
Remarks
Remark Id
Description
R-001
It was good experience to give a Presentation in Distributed Environment.
Project Results
Requirements
Requirement Compliance Matrix
Id
Requirement
Description
completed
Rem
Web-1
System Administration Requirements
Yes
Web -1.1
Administrator should login to do any specific task.
Yes
Web -1.2
Administrator should be able to adjust system parameters.
Yes
Web -1.3
Administrator should be able to add/ modify/ enable/ disable/ delete system users.
Yes
Web -1.4
Administrator should be able to add/ modify/ archive/ delete projects.
Yes
Web -1.5
Administrate project leaders for existing projects.
Yes
Web -1.6
Comments to different members.
Yes
Web -2
Project leader Requirements.
Yes
Web -2.1
Project leader should be able to define baseline plan.
Yes
Web -2.2
Project leader should be able to manage project group.
Yes
Web -2.3
Project leader should be able to monitor individual work.
Yes
Web -2.4
Project leader should be able to define milestones, activities, resources & financial plans etc…
Yes
Web -2.5
Project leader should be able to freeze work done report at the end of the week after finalizing the week plan.
Yes
Web -3
Project member should be able to submit week report.
Yes
Web -4
E-mail Alerts & Logging
Yes
Web -5
Look & Feel and Language
Yes
Web -6
Gand Chart
Yes
Web -7
Log File
Yes
Completed: Yes (completely implemented)
No (not implemented at all)
Partially (partially implemented, more description under Remarks subsection)
Unknown (completion status not known)
Dropped (requirement was dropped during the course of the project)
Requirements Compliance Summary
Total number of requirements
19
Number of requirements implemented
18
Requirements partially fulfilled
0
Requirements not fulfilled
1
Requirements dropped
1
Remarks
Remark Id
Description
Work Products and Deliverables
To
Output
Planned week
Promised week
Late +/-
Delivered week
Rem
Igore Cavrak
Project Description & Plan
W46
W46
No
W46
Igore Cavrak
Requirement Definition
W47
W47
No
W47
Igore Cavrak
Project Design
W49
W49
No
W49
Igore Cavrak
Revised Project Plan
W52
W52
No
W52
Igore Cavrak
Project Status Presentation
W01
W01
No
W01
Igore Cavrak
Final Presentation & delivery
W03
W03
No
W03
Remarks
Remark Id
Description
Project Experiences
Positive Experiences
The main experience we learn from this DSD Project is to work in group. We also learn about new software like PostGrade SQL.
Improvement Possibilities
We have experience that if we will organize our resource according to requirements then we can make project more successful.
Financials
Project Cost Summary
Planned Cost
250.000 SEK
Actual Cost
260.000 SEK
Work per Member
Member
W45
W46
W47
W48
W49
W50
W51
W52
W01
W02
W03
Total
Khuram Shahzad
20
24
20
22
25
35
30
30
36
34
46
322
Ahsan Jawed
15
19
18
19
22
25
28
26
30
29
32
263
Imran Afzal
13
15
16
20
19
20
24
22
23
24
30
226
Shoiab Ahmad
14
16
15
15
20
24
22
20
20
22
28
214
Abdullah Anjum
15
13
15
16
20
15
22
19
22
25
30
212
Total
77
87
84
92
106
117
126
117
131
134
166
1237
Metrics
Milestone Metrics
Completed as planned or earlier
Total
Timeliness
18
19
Achieved
Effort Metrics
Activity
Actual Effort
Planned Effort
Deviation (%)
Requirements Gathering
75
80
-6.25
Analysis
85
100
-15
Database Design
97
110
-11.81
Web Page
180
220
-18.18
Implementation
450
500
-10
Integration
150
100
50
Testing
200
150
33.33
Total
1237
1260
22.09
Effort estimation accuracy (%)
(100*(1 – abs(Actual – Planned)/Actual))
98.14%
Doc. No.: 1�
�
�
Page 2
template/Library
https://www.bcu.ac.uk/library
Account number:19142300
Password:s1hwBTt0U
Reference style：Harvard
requirements/MAN7084 Project Management Assignment 2019-2020 (2) x
HAND IN/PRESENTATION DATE: 27th May 2020 (12 pm- Midday)
HAND BACK DATE from: 26thth June 2020.
Learning outcomes and assessment criteria specific to this assignment:
1. Identify and evaluate a range of theories, concepts and approaches to Project
Management
2. Critically evaluate project management knowledge areas and critique project management software tools.
3. Apply project management concepts and understand different types of projects e.g. Traditional, Agile, Emertxe, and Extreme Projects.
4. Evaluate project closure and how to facilitate knowledge retention in future projects
Please see detailed marking scheme.
Overview
Choose a successful Project Management（As shown in PPT） within the creative sector (e.g. arts, media, design, broadcasting, luxury goods, building design, etc.) is essential to take ideas from beginning to fruition, assisting with the operationalising of new innovation and smooth delivery of essential tasks. You will need to explore project management issues within the creative sector. It aims to present a research informed approach to enable the management of resources and decision-making, in areas such as defining, planning, costing and reviewing large or small scale projects and will be delivered specifically for PG students only.
Assessment 100%
Coursework
Individual 3000 word assignment report allows you to apply your project management knowledge in a practical way based around a common-themed case study on Arts and Culture Festival or a self-determined project of your choice from within the Creative Industries Sector or that addresses the following:
1. Traditional, Agile, xPM and MPx considerations
2. The five stages of a PMLC (project management life cycle) model for the project
3. Any project planning considerations & an outline of how you would manage and control the project
4. Project risk management & managing any potential scope issues
5. Project stakeholder management & Managing client expectations
6. How you would close the project and transfer any relevant learning to future projects.
7. Conclusion and recommendations in needed.
You’re required to use relevant project management tools such as precedence table to record relevant project tasks, a Network Analysis chart, Gantt chart and Project Management Software (e.g. Microsoft Project) for the new Arts and Culture Festival or a self-determined project of your choice from within the Creative Industries Sector using Project Management Software.
It is vital to recap on the practice presentations and build on your formative feedbacks for your chosen topic area, to further demonstrate an understanding of key concepts that impact on leaders in businesses. It offers you an opportunity to draw upon your academic understanding of project management key concepts, theory and tools needed for this assignment and demonstrate your learning in a practical manner.
University Regulations:
The word limit is for your coursework assignment, and does not cover material which is submitted as an appendix. Material submitted as an appendix provides background for your coursework, but it will not be marked unless specified in the brief. Also, it is important that you cross-refer between the main text of your assignment and any appendices, in order to demonstrate the linkage, and that the Appendices do not constitute additional material unrelated to that included in the body of your assignment. If you do not refer to this work in the Appendix, then this included work in the Appendices are not marked.
Your References page will not be included in the word count, but where you quote within the assignment (e.g. Smith and Jones (2010) identified that…) will be included in the word count.
You are required to indicate the number of words used in your assignment.
If you produce less than or exceed the stipulated word count by more than 10%, a deduction of the mark awarded will be made to reflect that you have not met the assessment requirements.
Final suggestions:
1. The assignment should be word processed with 1.5 line spacing and is a report, therefore, should have the right format, do not use bullet points (except on PowerPoint slides!).
2. Use Arial size 12 point (this font and size) for your assignments.
3. State the word count used in Section 2 as stated above, should provide pages numbers on each sheet.
4. All work (slides in Section 1, Section 2 and References page) should be referenced in BCU Harvard style format – there are hand-outs available on-line at the Library website and these are available as a hardcopy in the Library if you are unsure about this.
5. Do not use Wikipedia – is not peer assessed and the work may be unreliable, and don’t rely too heavily on Internet sources but must provide sources of all materials and data use.
6. Do use current academic text books and academic journal articles (newspapers are not articles); use some post-year 2010 academic work.
4 | Page
Structure of the assessment:
Marking Criteria
0 – 39% Fail
40 – 49%
Fail
50 – 59% Pass
60 – 69%
Strong Pass (merit)
70 – 79%
Very Strong Pass
(distinction)
80 – 100%
Exceptionally Strong
Pass
(distinction)
Criterion 1 Mark:
25%
Identify and evaluate a range of theories, concepts and approaches to project management
Incomplete or very shallow analysis, presentation fails to apply relevant theories, academic and literature to address assignment task.
An insufficient range of theories discussed or not explicitly referenced.
References are poor and drawn from non – academic sources only.
A satisfactory range of project management theories are applied and references drawn from academic and quality non-academic sources.
An array theories are demonstrated in project management, with quality references drawn from international contexts including journals and textbooks.
A large array theories are demonstrated in project management, with an excellent level of wider reading including references drawn from international contexts. Project landscape explore and justified.
Extensive theories are demonstrated in project management, with significant wider reading including references drawn from international contexts including PRINCE 2 and PMBOK. Project landscape explores and justified.
Criterion 2 Mark:
25%
Critically evaluate project management knowledge areas and critique project management software tools.
Incomplete or very shallow analysis, presentation fails to apply relevant theories, academic and literature to address assignment task. No use of project management software.
Process groups mentioned although no explicit discuss or
critique. Project
Management Software used and applied although limited visual application and minor errors in the application e.g. not levelling resources.
Process groups discussed at least one model applied and levels of general critique is demonstrated, with several areas of weaknesses identified. Project management software applied with several areas visually demonstrated.
Process groups are explored in significant detail with a level of critique – highlighting some weaknesses. Project management software demonstrated and visually displayed with all main features evidenced.
Process groups are explored in extensive details and critiqued – highlighting their retrospective weaknesses. Project management software is effectively applied and all main features are demonstrated explicitly and visually.
Process groups explicitly discussed and critique extensively. Project management software used and applied with clear visual application demonstrated. No errors in the application e.g. levelling of resources where applicable is completed (no resource allocated above 100%).
Criterion 3 Mark:
25%
Apply project management concepts and understand different types of projects e.g. traditional, agile, emertxe, and extreme projects.
Incomplete or very shallow analysis, presentation fails to apply relevant theories, academic and literature to address assignment task. No exploration of various project types.
Case study not discussed or incorrectly applied.
No consideration of the wider business environment.
No project management concepts effectively applied to the case
study. Brief discussion of project management types.
Case study discussed and a suitable project identified but no consideration for the wider business environment is offered. Project management concepts sporadically discussed but not in detail with poor levels of justification. Detailed discussion of project management types.
Case study applied sufficiently and suitable project identified.
Reference to the case study is made occasionally / sporadically. Project “value” is plausible but not fully justified. Project
management concepts discussed but not fully critiqued or explored. Detailed discussion and
Engagement with the case study: Arts and Culture Festival or a self-determined project of your choice from within the Creative Industries Sector. Some business and contextual issues considered included e.g. either macro or micro business contexts. Project “value” plausibly significant and relevant project concepts applied
Excellent engagement with the case study: Arts and Culture Festival or a self-determined project of your choice from within the Creative Industries Sector. Wider business and contextual issues considered included macro and micro business environment. Project
“value” plausibly significant and relevant project concepts applied.
Critique of project management types.
Strengths and weakness of project management types explained and applied to the case study.
Comparison made between competitor Arts and Culture Festival or a self-determined project of your choice from within the Creative Industries Sectors. Strengths and weakness of project management types explained and applied to the case study.
Criterion 4 Mark:
25%
Evaluate project closure and how to facilitate knowledge retention in future projects
Incomplete or very shallow analysis, presentation fails to apply relevant theories, academic and literature to address assignment task.
Project closure not satisfactorily discussed or explained in sufficient detail.
Inadequate exploration of the learning cycle.
No specific closing steps mentioned or explained with no linkage to future projects.
Acceptable review of closure mentioning at least two of the closing sequence. Low levels of detail explanation or critique provided of the closing sequence. Learning processes only have scant attention.
Review of project closure processes and their salient features with not elements fully discussed or mentioned.
Transferable learning considered but not specific as to the target of the learning or how this will be delivered.
Strong discussion of project closure and full discussion of closing process.
Exploration of the transferable skills and learning at either the team or individual level. Consideration of the learning process and it communication.
Project start date considers closure.
Excellent review of project closure including a full discussion of the closing sequence. Discussion of transferable learning at both individual and team levels including reflection on communication and learning processes e.g. KOLB learning cycle. Project start date considers closure.
requirements/project management.ppt
DESIGND BY MUYUEHSOP
Cartier
Beyond the bounds: Cartier Palace Museum craft and restoration special exhibition
Themes
Plan
Value
Types of projects
Risk management
Reference
CONTENT
And Time Memories will highlight a recent collaboration: From 2014 to 2017, the museum and Cartier’s watch factory in La Chaux de Fonds, Switzerland, restored six 18th- and 19th-century watch and clock movements from the Forbidden City’s collection.
Themes
Chinese Inspirations
Symbols of Power
Chinese Inspirations is to feature works created with favored Chinese materials (such as lacquer and jade) and symbols (like dragons or phoenix’s) and to show how such pieces have influenced Cartier
Time Memories
Symbols of Power will showcase some 30 Cartier tiaras created for royalty in England, Belgium, Russia and India
01/06-31/07,2019
30,000 square feet
830
pieces
Dates
Location
Area
Meridian Gate (Wu men)
About 830 pieces from the archives of the French company and the museum, as well as items lent by other institutions and private collections, are to be displayed in nearly 30,000 square feet of the museum’s newly renovated Meridian Gate
plan
VALUE
The combination of brand culture and traditional Chinese culture, on the one hand, shows the profound history and cultural deposits of the brand, on the other hand, also shows the understanding and respect for Chinese culture, so as to attract more Chinese customers,and expand the brand’s popularity and influence in the Chinese market
Promote brand culture
Strengthen the influence in the Chinese market
.
Attract investors, collectors and other relevant people
Goal: increase brand awareness and profit
Solution: exhibition
RISK
Security problem
The exhibits damage
Facilities damaged
Sulotion
Increased security and regular patrols
Insured
Back-up facilities
Risk managemant
Reference
https://tw.asiatatler.com
https://www.nytimes.com/2019/05/13/fashion/jewelry-cartier-palace-museum-beijing-exhibition.html
https://en.dpm.org.cn/exhibitions/current/2019-04-17/2933.html
DESIGND BY MUYUEHSOP
WWW.DAOCER.COM
STORY LAND OURCABES+ BLOG CARERS
thank you
STORY LAND OURCABES+ BLOG CARERS
powerpoint/MAN7084 Project Management Wk_Session 10.pptx
MAN7084 Project Management
Week 10
Agile Project Management
Suhil Khan: Suhel.Khan@bcu.ac.uk
Kulbir Bains: kulbir.bains@bcu.ac.uk
Teaching Team:
Session objectives
Recap of last week activity
Agile Project Management
Q & A
Last Week’s End of Session Activity
The post-implementation audit is vitally important in improving
the practice and process of project management, yet it is always so difficult to get senior management and the client to allocate the time to authorize and participate in these audits.
Knowing that, what would you as project manager do to help alleviate this problem?
Agile Project Management
Based on testimonial data collected from over 10,000 project managers from around the world, over 70 percent of projects are best managed by processes that adapt to continual learning and discovery of the project solution.
When in doubt, leave it out.
When the pain the organization is suffering from failed projects reaches some threshold, the health of the business suffers and the bottom line is affected. If all previous corrective action plans have failed, senior management is ready to listen.
—Robert K. Wysocki, PhD, President, EII Publications, LLC
Agile Project Management
History of Agile
Extensive testimonial data suggests that more than 70 percent of all projects should have used some type of Agile Project Management (APM) model but didn’t.
Simply put, APM is a collection of PMLC models that can be used to manage projects whose goals are clearly specified but whose solutions are not known at the outset of the project, these are what we call “complex projects.”
Some of the PMLC models you are already familiar with are old (Waterfall and prototyping, for example), and these may have to be adapted to the particular situation presented by the project.
Some of the PMLC models are new (Scrum and APF, for example), and even these may have to be adapted to the situation presented by the project.
The bottom line in all of the APM PMLC models is that the best-fit project management approach is dynamic and continuously adapted to the changing project situation and environment.
History of Agile
Agile Project Management
Too many project managers have tried to force fit the wrong PMLC model because that is the only model approved for use by their management, or they did so in ignorance of other models that were better choices for a management approach.
The poor project track record of many organizations is sad testimony of those poor management decisions.
Many of you and the managers above you in the organization’s chain of command have to unlearn some marginal or unproductive project management habits to make room for more effective project management habits.
Many of Agile projects address problems and business opportunities for which there has not been an acceptable solution put forth or the business opportunity has not been successfully exploited.
These projects are characterized by high complexity and uncertainty and present the organization with a significant challenge.
The fact that these high-risk projects are addressed at all means that their successful completion is critical to the business.
These projects will challenge the creative abilities of the project manager, the client team, and the development team.
Agile Project Management
History of Agile
There is a further classification of APM PMLC models: Iterative and Adaptive. Iterative PMLC models are appropriate for projects where most of the solution has been discovered – only a few minor features have not been decided.
In many cases, alternatives will be known but a final decision not made as to which to implement.
Adaptive PMLC models are appropriate for projects where per-haps very little of the solution is known.
Understanding and integrating major functions into the solution are integral to the learning and discovery part of Adaptive PMLC models.
Agile Project Management
History of Agile
There are several Agile models to choose from:
Prototyping and Evolutionary Waterfall Development are two robust Agile PMLC models that can be used for any type of project.
The four popular choices for software development are:
1. Rational Unified Process (RUP),
2. Scrum,
3. Dynamic Systems Development Method (DSDM), and
4. Adaptive Software Development (ASD).
All four are Iterative PMLC models; these models are similar in that they are designed to facilitate software solution discovery.
5. There is a fifth Adaptive PMLC model that you will also learn about called Adaptive Project Framework (APF).
Agile Project Management
History of Agile
APF is different than the other four because it was designed for both software development and non–software development projects.
The first two applications that resulted in my developing the APF model were a process design and a product design project.
The APF model’s application to product development, process design, and process improvement projects has been successfully demonstrated.
For a given Agile project, the choice of which of the two Agile PMLC model types provides a better fit will always be subjective.
Many of the Agile models also work quite well on xPM and MPx projects.
Agile Project Management (APM)
What are Agile Projects…
APM is the new kid on the block – you might even say that the development of APM is an Agile project itself.
Its history stretches back a little more than 25 years.
As recently as 2001, Agile software development was first codified through the “Agile Manifesto” (shown in the accompanying sidebar) put forth by Martin Fowler and Jim Highsmith; there were 17 signers of the original Agile manifesto.
The Agile Manifesto has been the guiding principle in all APM models, including those discussed in this book and marks the official beginning of the Agile movement.
Most of the APM models originated with software development and, as a result, are based on very specific software development practices.
Prototyping (which pre-dates APM), Evolutionary Waterfall Development, and the Adaptive Project Framework (APF) are the only APM PMLC models designed for use on any type of project.
Agile Project Management (APM)
Implementing APM Projects..
Adding more functions and features to the solution and implementing them at the same time sounds great.
The client and the end user can benefit from whatever business value can be attained, experience the solution unfolding over short time periods, work with the solution, and provide valuable feedback to the developers about further additions and changes to the solution.
But there is another side to this story, and that is the implementation of a constantly evolving solution.
Iterations and cycles are short duration—2 to 4 weeks is typical.
The end users will give up and surrender if you expect them to change how they do their work by implementing a new solution every few weeks. How about your organization? What is its organizational velocity? Can it absorb change that fast? Most can’t or won’t. So what are the client and the project manager to do? Getting frequent client feedback is critical to discovering the complete solution and ultimately to project success, but the organization can’t absorb change as fast as the APM models would like.
There is also the question of the project team’s ability to support frequent releases. Training, documentation, and a support group are needed, let’s see, what release are you using again?
Agile Project Management (APM)
Implementing APM Projects…
Fully Supported Production Versions of Partial Solutions Are Released to the End User Quarterly or Semi-Annually
This seems to fit other organizational practices for implementing change, so it won’t be viewed as anything different than what they are already doing.
The input received from the end user and others who affect or are affected by the solution should still be gathered. It will be your most valuable information.
There is a benefit in having longer periods to experiment and get comfortable with a new tool.
You will gain valuable insight into the intuitive properties of your solution and see what the learning curve looks like.
This approach does not release the project team from the need to support the quarterly releases. I mention that so that you will remember to incorporate in your project plan the effort and support time that will have to be provided.
Agile Project Management (APM)
Implementing APM Projects…
Intermediate Non-Production Versions Are Released to a Focus Group Every 2–4 Weeks
You don’t stand idly by and wait for end-user feedback from the quarterly releases.
That flies in the face of delivering business value early and often. Instead, assemble a focus group of staff and managers who are respected by their peers and who have earned the right to critique the solution.
You should ask them to commit to reviewing and critiquing every version of the solution.
You will need to take advantage of any learning curve effects from having the same focus group members reviewing the evolving solution.
The focus group should have some of the client members of the project team on it as well as a few other key end users.
A focus group of 10 members is a good working group, but use your judgment on the size.
The decision model you choose to use might also influence size—for example, do you need an odd number for voting? The project team will work very closely with the focus group on every version of the solution—both those that are released quarterly to end users and those that are not released.
The documentation, training, and support needed by the focus group to understand the non-released solutions will be minimal.
If you choose the focus group members to be a representative sample of all user groups, they can also provide limited support to the end users for the quarterly and semi-annual production versions. That way they can become a conduit from the end users back to the project team.
Co-Located APM Project Teams…
Agile Project Management (APM)
Fully Supported Production Versions of Partial Solutions Are Released to the End User Quarterly or Semi-Annually
Every proponent of APM approaches advises using small co-located teams of highly skilled professionals who are assigned 100 percent to the project and who can work without supervision.
That’s a nice goal to strive for but not too practical or likely in today’s business environment.
I haven’t encountered a single example of a co-located team among my clients for at least five years. And the likelihood that I will is decreasing.
Most of the Iterative and all of the Adaptive PMLC models require a team of highly skilled professionals. The Adaptive project teams that do use highly skilled professionals are self-organizing teams and work effectively without supervision.
One of my colleagues is managing an APM project and has never seen, nor is she ever likely to see, her teammates.
She didn’t even have the option of selecting them, and none of them are assigned to her project 100 percent. They were available, and they are distributed across the country.
There is no money in the project budget for team members to travel. She has their pictures taped to her computer. It is obvious that the success of her project rests on team members knowing what has to be done and getting it done with little or no supervision. Openness and honesty are her critical success factors.
Co-Located APM Project Teams…
Agile Project Management (APM)
Cross-Project Dependencies …
Consider this scenario.
Harry is your only data warehouse design professional, when he finishes the data warehouse design on the Alpha Project, he is scheduled to begin the data warehouse design on the Beta Project.
This raises the following management questions:
Is Harry overcommitted?
■ If Project Alpha is delayed, what is the impact on Project Beta?
■ Who decides the project priority if there is a scheduling conflict with Harry?
■ Can Harry’s work on Project Alpha be overlapped with his work on Project Beta?
■What if Harry leaves the company?
These are difficult and complex questions to answer. But they must be answered. Your risk management plan is a good place to look for most of the answers.
Agile Project Management (APM)
Project Portfolio Management …
Many of the situations that gave rise to the preceding staffing questions can be mitigated through a project-portfolio management process.
The decisions to approve a project for the portfolio can be based on a Human Resource Management System (HRMS).
That system should include the skills inventory of all professionals, their current and future commitments, and their availability for additional project assignments.
Unfortunately, not many organisations have such systems in place. Instead, they add a project to the portfolio based on its business value.
That is all well and good, but not sufficient !
Agile Project Management (APM)
Project Portfolio Management …
What is sufficient and what you might want to adopt is the Graham-Englund Model,2 which answers the following four questions:
What should we do?
What can we do?
What will we do?
How will we do it?
The answer to the first question is a list of potential projects prioritized usually by business value.
The answers to the next two questions can be based solely on the skills inventory and the availability of those skills over the planning horizon of the portfolio and the scheduling needs of the projects in the portfolio.
The effective management of the contents of the project portfolio depends on access to a solid HRMS.
There are commercially available software systems for portfolio management under a variety of resource constraints.
For maximum effectiveness, this HRMS should be housed in a Project Support Office (PSO).
Co-location of the project team members is strongly advised in the Iterative PMLC model and required in the Adaptive PMLC model, but in its absence, Agile projects can still survive and succeed.
Agile Project Management (APM)
Project Portfolio Management …
The challenge is to deliver sound management of such projects despite the challenges of physical separation and time differences.
There are all kinds of technologies to help. Web meetings, instant messaging, and electronic whiteboards are all cost-effective alternatives.
Burdening an Agile project with non-value-added work is something to be avoided.
Agile Project Management (APM)
Iterative Project Management Life Cycle
On the certainty/uncertainty line, the models are aligned from Linear to Incremental to Iterative to Adaptive to Extreme.
Both the Iterative and Adaptive models have been proposed to address the difficulty many project managers face when they try to clearly decompose requirements and are unable to do so.
In some cases that difficulty arises from the client not having a clear picture of their needs and in other cases from the solution not being known.
In either case, some type of APM approach is called for.
Agile Project Management (APM)
Iterative Project Management Life Cycle
An Iterative PMLC model consists of a number of process groups that are repeated sequentially within an iteration with a feedback loop after each iteration is completed.
At the discretion of the client, the last process group in an iteration may release a partial solution.
Iterative approaches are used when you have an initial version of the solution, but it is known to fall short in terms of features and perhaps functions.
The iterative cycles are designed to identify, select, and integrate the missing pieces of the solution.
Think of the Iterative PMLC model as a variant of production prototyping.
The intermediate solutions are production ready, but they might not be released by the client to the end user until the final version is ready.
The intermediate versions give the client something to work with as they attempt to learn and discover additional needed features.
The client would choose to release a partial solution to the end user in an attempt to get input from them on further solution detail.
Agile Project Management (APM)
Iterative Project Management Life Cycle
The Iterative PMLC model requires a solution that identifies the requirements at the function level but might be missing some of the details at the feature level; In other words, the functions are known and will be built into the solution through a number of iterations, but the details (the features) are not completely known at the beginning of the project.
The missing features will come to light as the client works with the most current solution in a prototyping sense.
The Iterative PMLC model is a learn-by-doing model.
The use of intermediate solutions is the pathway to discovering the intimate details of the complete solution.
The Iterative PMLC model embraces several types of iteration.
Iteration can be on requirements, functionality, features, design, development, solutions, and other components of the solution.
An iteration consists of the Planning, Launching, Monitoring and Controlling, and Closing Process Groups. Closing an iteration is not the same as closing the project.
Agile Project Management (APM)
Iterative Project Management Life Cycle
The Iterative PMLC model kicks in when one of the following occurs:
Most but not all of the solution is clearly known.
You might otherwise have chosen the Incremental PMLC model but have a strong suspicion that there will be more than a minimum number of scope change requests.
You might otherwise have chosen the Adaptive PMLC model but are concerned about lack of client involvement.
There is some added risk to this decision.
Iterative Project Management Life Cycle
Agile Project Management (APM)
Most of the Solution Is Clearly Known
Some of the details of the solution are missing.
The alternatives to how those details (that is, features) might be added to the solution are probably known up to a point.
All that remains is to give the client a look at how those features might be deployed in the solution and get their approval on which alternative to deploy or their recommendations for further change. This is the simplest of the Iterative situations you will encounter.
Production prototype approaches are the usual choice. As far as the project team knows, all of the functions and sub-functions have been identified and integrated into the current solution.
As features are added, there could be changes in how the functions and sub-functions are deployed in the solution, and hence, further changes are recommended- this is the nature of an Iterative approach.
It continues in this vein until the client says you are done or until time and/or money is exhausted.
Agile Project Management (APM)
Iterative Project Management Life Cycle
Likely to Be Multiple Scope Change Requests
This may just be a hunch, or this client’s reputation is one of having made many changes in past projects. It’s better to be safe than sorry.
The off-the-shelf Incremental PMLC model does not leave room in the project schedule for receiving and processing scope change requests.
Rather than risking the consequences, choose an Iterative PMLC model that does leave room in the project schedule for client and end-user feedback or the accommodation of scope change requests
Concern About Lack of Client Involvement
Coming from the Adaptive PMLC model side of the project landscape, if you have chosen to use an Iterative PMLC model, there are some risks you need to know about.
You will have some degree of meaningful client involvement but not to the degree that you feel you will need it.
Rather than depending on meaningful client involvement, you will have to guess at what the complete solution will be.
The more involved the client is, the less you will be dependent on guessing.
You might be good at guessing or just lucky, but you will still be guessing.
The more knowledge your team has of the client systems and pro-cesses, the better off you will be.
Iterative Project Management Life Cycle
Scoping Phase of an Iterative PMLC Model
Agile Project Management (APM)
The Scoping Phase of the Iterative PMLC model takes on a bit more complexity than the Scoping Phase of the Linear or Incremental PMLC models, and it requires decisions that are not part of Linear or Incremental PMLC models.
The key input for your decision to use an Iterative PMLC model is the requirements definition expressed by the Requirements Breakdown Structure (RBS).
You and the client will review and discuss the RBS, paying particular attention to how complete you both think it is.
Except in the simplest of situations, neither you nor the client can ever know for certain that the RBS is complete, this will always be a subjective decision.
My advice is to err on the side of deciding that an RBS is less complete rather than more complete.
That is, choosing an Iterative PMLC model rather than a Linear PMLC model or choosing an Adaptive PMLC model rather than an Iterative PMLC model is the safer ground
Agile Project Management (APM)
Iterative Project Management Life Cycle
Planning Phase of an Iterative PMLC Model
Planning is done at two levels in the Iterative PMLC model; the initial Planning Phase develops a high-level plan without much detail. The reason is that the full detail is not known at the initial stage. The functionality is known, and its design and development can be planned across any number of iterations.
There are two ways to structure the high-level plan in the Iterative PMLC model.
The Complete Plan for Building the Known Solution
The first iteration in this plan may be of long duration in order to accommodate building a production version of the entire but incomplete known solution.
If you feel that this iteration will be too long, then you might consider using a tool to model the solution instead.
You will use that model throughout the entire project and create the production version of the complete solution at the end of the project.
Agile Project Management (APM)
Iterative Project Management Life Cycle
Planning Phase of an Iterative PMLC Model
The Partial Plan for the High-Priority Functions
For this approach, you will begin the partial plan by prioritizing the functions and features in the initial RBS. The rule for prioritization will most likely be business value so that the deliverables from an iteration can be released to the end user, if the client so chooses. Alternatively, the prioritization might be based on risk or complexity: high-risk functions at the top of the list or high-complexity functions at the top of the list.
By developing these functions early in the project, you ensure the successful completion of the project. In some cases, all the known functions and features will be developed in the first few iterations.
Later iterations then drill down to possible areas for further identification and development of features.
This is probably the most efficient of all the development alternatives you might consider.
Yet another strategy would be to develop the high-risk parts of the system first.
That removes one of the major variables that could adversely affect the project if left to a later iteration. A final rule may be to satisfy as many users as possible with your choice of functions or features.
Agile Project Management (APM)
Iterative Project Management Life Cycle
Launching Phase of an Iterative PMLC Model
There is a significant difference between the project team for a Traditional Project Management (TPM) project and the project team for an APM project.
The team profile for an Iterative PMLC model can be somewhat relaxed, whereas the profile for the Adaptive PMLC model should be adhered to as closely as possible.
In addition to the team differences that you have to consider, there is one major difference in the way scope change is dealt with.
In TPM projects, there must be a formal scope change management process (That is not the case in an APM project)
There is no need for a formal scope change management process in an APM project, because all of the learning and discovery that takes place during an iteration in an APM project is saved and reviewed between iterations.
The items in the Scope Bank are prioritized for integration into the solution in a later iteration.
Differences Between, a TPM Project Team and an APM Project Team
Agile Project Management (APM)
Iterative Project Management Life Cycle
Monitoring and Controlling Phase of an Iterative PMLC Model
In the Iterative PMLC model, the Monitoring and Controlling Phase begins to change.
Because of the speculative nature of the iterative strategy, much of the heavy documentation and status reporting gives way to more informal reporting.
Much of that formalism becomes non-value-added work and begins to burden the team with tasks that do not bring them any closer to the final solution.
You want to be careful not overload the architects and developers with those types of tasks.
Let them remain relatively free to pursue the creative parts of the project.
During the between-iteration reviews, you should review the status and progress of solution definition and make any needed adjustments.
Agile Project Management (APM)
Iterative Project Management Life Cycle
Closing Phase of an Iterative PMLC Model
The Closing Phase for the Iterative PMLC model is similar to the Closing Phase for the TPM PMLC model in that there are client-specified criteria that must be met in order for the iteration or cycle deliverables to be considered complete.
Those criteria were specified during iteration planning.
Each iteration has closing criteria, but only regarding the iteration deliverables for that cycle.
The only difference is that the project might end (all of the time and/or money has been used), and there might still be features not integrated into the solution.
These are noted in the final report and are to be considered whenever the next version of the solution will be commissioned.
Lessons learned take on an additional dimension.
What did the team and the client learn about doing projects following the Iterative PMLC model?
How can the approach be improved for the next iteration or project?
Agile Project Management (APM)
Adaptive Project Management Life Cycle
The Adaptive models are more appropriate for projects involving higher levels of uncertainty and complexity than the Iterative models.
In that sense, they fill a void between the Iterative and Extreme models.
Adaptive models are more useful than Iterative models in those situations where very little is known about the solution.
Keep in mind that solution discovery is still the focus of these models.
Each iteration in the Adaptive models must address not only task completion for newly defined functions and features, but also further solution definition through function and feature discovery.
It is the discovery part of the Adaptive PMLC models that sets them apart from the Iterative PMLC models.
Definition
An Adaptive PMLC model consists of a number of phases that are repeated in cycles, with a feedback loop after each cycle is completed.
Each cycle proceeds based on an incomplete and limited understanding of the solution.
Each cycle learns from the preceding cycles and plans the next cycle in an attempt to converge on an acceptable solution.
At the discretion of the client, a cycle may include the release of a partial solution.
Unlike the Iterative PMLC model where some depth of the solution is not known (features, for example), the Adaptive PMLC model is missing both depth and breadth of the solution.
Adaptive Project Management Life Cycle
Agile Project Management (APM)
With the exception of using the term “cycles” in place of “iterations,” the Process Group–level diagram for the Adaptive PMLC model is identical to the Iterative PMLC model.
But the similarity ends there, there is only one Adaptive model.
It is the Adaptive Project Framework (APF). APF was built to be applicable to any type of project. For that reason, I offer a more in-depth discussion of APF. APF thrives on learning, discovery, and change.
In time, and with enough cycles, you hope that an acceptable solution will emerge.
Adaptive Project Management Life Cycle
Adaptive PMLC model, as with other Agile approaches, the degree to which the solution is known might vary over a wide range from knowing a lot but not all (projects that are a close fit for the Iterative PMLC models) to knowing very little (projects that are a close fit for the Adaptive PMLC models).
The less that is known about the solution, the more risk, uncertainty, and complexity will be present.
To remove the uncertainty associated with these projects, the solution has to be discovered.
That will happen through a continuous change process from cycle to cycle; that change process is designed to create convergence to a complete solution.
In the absence of that convergence, Adaptive projects are frequently cancelled and restarted in some other promising direction
Agile Project Management (APM)
Adaptive Project Management Life Cycle
Scoping Phase of an Adaptive PMLC Model
The Scoping Phase of the Adaptive PMLC model is a high-level activity because not much is known about the solution.
The missing functions and features have to be discovered and learned through repeated cycles much like the Iterative SDPM strategy.
For the Adaptive PMLC model, the scoping activities merely set the boundaries and the high-level parameters that will be the foundation on which you proceed to learn and discover.
As part of the Scoping Phase deliverables, you will document requirements, as you know them; functionality, as you know it; and features, if you know any. In addition, you will specify the number of cycles and cycle length for the first cycle.
If you have enough insight into the solution, you might tentatively map out the cycle objectives at a high level.
A partial high-level Work Breakdown Structure (WBS) can help complete this exercise.
Planning Phase of an Adaptive PMLC Model
At this point in the Adaptive PMLC model, planning is done for the coming cycle.
High-level planning was done as part of the Scoping Phase. Based on the known functionality and features that will be built in the coming cycle, a detailed plan is developed.
This plan utilizes all of the tools, templates, and processes that were defined for the Planning Process Group.
Agile Project Management (APM)
Agile Project Management (APM)
Adaptive Project Management Life Cycle
Launching Phase of an Adaptive PMLC Model
The Launching Phase will be the same as discussed in the Iterative PMLC model.
The launch activities will include establishing team operating rules, the decision-making process, conflict management, team meetings, and a problem-solving approach.
The only difference will be defining the approach that will be used to establish subteams and their work plan to accommodate concurrent swim lane tasks.
Monitoring and Controlling Phase of an Adaptive PMLC Model
As you move from the Iterative PMLC model to the Adaptive PMLC model, there is a marked shift from formality to informality when it comes to this phase.
That move to informality makes room for the marked increase in creativity that the team is called upon to deliver.
Creativity and formality are not comfortable bedfellows. You need to give the team and the client the best opportunity you can to be successful and that means relaxing the need for status reporting and strict control of the schedule.
The nature of these projects is that they are focused on delivering value rather than being focused on meeting time and cost criteria.
Adaptive Project Management Life Cycle
Agile Project Management (APM)
Closing Phase of an Adaptive PMLC Model
The Closing Phase produces the typical artefacts: lessons learned, validation of success criteria, and so forth.
In addition to those, you might have items left in the Scope Bank that were not included in any cycle build.
These are to be documented and held for the next version of the solution.
Adapting and Integrating the APM Toolkit
The APMPMLC models define a world that is a fascinating challenge to the chefs and an overwhelming problem for the cooks.
The chefs will consider the current characteristics of the project goal and solution; reach into their tools, templates, and processes for the best fit; and adapt it to the project.
In many cases, their creativity will be brought to bear on their management needs.
The cooks will try to use an APMPMLC model right out of the box and fail.
Their organization may have constrained them to one of just a few established PMLC choices and sown the seeds of failure.
I’ll give them the benefit of the doubt and allow that they may well pick the best-fit tool, template, or process and then try to force fit it to the project.
Frustration and high failure rates are the predictable result.
Adapting and Integrating the APM Toolkit continue…
If you are going to be a chef, you have to be flexible and discerning about what you are doing.
There is no substitute for thinking, and you must be thinking all of the time to stay on top of an APM project.
Therefore, I’m going to describe some typical situations that demand flexibility and adaptability.
This section gives you a quick look at each part of the APM PMLC model to see how you might use Process Group tools, templates, and processes to best advantage in an APM project
Agile Project Management (APM)
Agile Project Management (APM)
Conclusion
Using Iterative and Adaptive PMLC models can be among the most challenging and fulfilling experiences you might have as a project manager.
These models have many similarities and differences.
Projects are dynamic efforts and conditions could suggest changing your choice of model and how best to use it.
There are many more choices for those who are interested.
Learning to be successful with Agile projects is as much an art as it is a science.
Agile projects are definitely calling upon you to be a chef and not a cook
Any questions?
Reading Materials
Core Textbook
Wysocki, R, K; (2009), Effective Project Management: traditional, agile, extreme–5thedition, Indianapolis, Wiley. http://
capitadiscovery.co.uk/bcu/items/1091130
Other useful Textbooks–or any Project Management book
Cobb, C, G: (2011) Making sense of agile project management: balancing control and agility. Hoboken, N:J Wiley http://
capitadiscovery.co.uk/bcu/items/1138767
Maylor, H (2010) Project Management. Harlow: Prentice Hall Financial Times http://
capitadiscovery.co.uk/bcu/items/1047967
powerpoint/MAN7084 Week 7 Project Management – Lab 1.pptx
Project Management
Week 7 Lab 1 Workshop – Project Management Tools
Project Management Tools Lab / Practical Session 1 -Overview
Session objectives
Last week recap
Assessment recap
Last week’s activity
Project Management Scoping and Project Scheduling
Questions?
Activity
2
3
Tools / Methodologies:
Work Breakdown Structure (WBS)
Gantt Charts
PERT / CPM (Program Evaluation and Review Technique /
Critical Path Method)
Project Management Tools
25
Download and practice with Project Management Software:
Download Project Libre
Windows
Link
Mac
OS
Link
Alternatively try use Microsoft Project – Free Trial https://products.office.com/en-us/project/project-professional-
desktop-software
25
Once you have the software open, now follow the next slides on your laptop and desktops screens.
6
Microsoft Project
7
Microsoft Project
8
Microsoft Project
9
Microsoft Project
The Project Software
Home Page
10
Microsoft Project – Entering Data
11
Software – Entering Data
12
Software – Gant / PERT charts
Software – Critical Path Analysis
Red bars – highlight the critical path of the precedence table… should these events experience any time delay, the overall project will be delayed.
Purple bars – highlight none critical path of the precedence table… time delays here typically do not extend the
overall project timescale.
13
14
Software – Resource Utilisation
15
Software – Resource Utilisation
Each project resource cannot be utilised more than 100%!
The earlier precedence table
Some software helps to “flatten” resources
automatically e.g. Microsoft Project. Other software, e.g. Project Libre requires this to be done manually.
16
Work Breakdown Structure (WBS):
Advantages / Limitations?
Project Management Tools
17
Work Breakdown Structure (WBS):
Project Management Tools
18
Gantt charts:
Advantages / Limitations?
Project Management Tools
19
PERT / CPM: Program Evaluation and Review Technique / Critical Path Method
Advantages / Limitations?
Project Management Tools
Project Management
Project Management Scheduling Activity
In the context of Insert your theme/industry; explore project scheduling, with the aim of applying the use of Gantt charts to enable the planning and control of respective projects.
Planning of Projects
Sequencing project activities and milestones Logical order…
Interrelation between activities will exist… Stakeholders
Scheduling (Timing)
Timing/estimates of project activities and milestones Typically referred to as activity duration…
Also incur an Interrelation between activities
Estimating Activity Duration
Crucial to success of project
They underpin a number of key performance measures:
Estimating Activity Duration
Crucial to success of project
They underpin a number of key performance measures:
Estimating Activity Duration
Use of historical data to predict for future events Trial timings
Use of probabilistic method…
Probabilistic “weighted” method
Optimistic (a) = Minimum Likely (m) = Normal Pessimistic (b) = Longest
Probabilistic “Beta weighted” method Optimistic (m) = Minimum 24hrs
Likely (n) = Normal 48hrs Pessimistic (l) = Longest 96hrs
“Beta” weighed average = m+4n+l/6
Student Activity
With reference to the principles of scheduling carry out an analysis of the primary activities for a project of your choice.
19
Any questions?
Reading Materials
Core Textbook
Wysocki, R, K; (2009), Efffective Project Management: traditional, agile, extreme – 5th edition, Indianapolis, Wiley. http://capitadiscovery.co.uk/bcu/items/1091130
Other useful Texbooks – or any Project Management book
Cobb, C, G: (2011) Making sense of agile project management: balancing control and agility. Hoboken, N:J Wiley
http://capitadiscovery.co.uk/bcu/items/1138767
Maylor, H (2010) Project Management. Harlow: Prentice Hall Financial Times http://capitadiscovery.co.uk/bcu/items/1047967
20
powerpoint/MAN7084 Week-Session 3 PM Process Groups.pptx
Week/Session 3
Project Management Process Groups
Input Session
Teaching Team:
Kulbir Bains – kulbir.bains@bcu.ac.uk
Suhel Khan – suhel.khan@bcu.ac.uk
MAN7084 Project Management
Session objectives
Last week recap
Assessment recap
Project Management Process Groups
Questions?
Activity
Project Management Landscape
Examine the different types of projects:
traditional; agile, extreme and emertxe.
Projects are not viewed in isolation
The enterprise/organisation will have collections of all types of projects running in parallel and drawing on the same limited resources, therefore, management have to make a decision.
Every project must have a goal and a solution.
A number of metrics can be use to quantify these characteristics, but the simplest and most intuitive will be two values: clear and complete or not clear and incomplete.
Two values for each characteristic generate the four- quadrant matrix.
Project Management Landscape
Examine the different types of projects: traditional; agile, extreme and emertxe.
These values are theoretical, not quantifiable,
and their interpretation is certainly more personal/expert opinion
A given project can display various degrees of clarity.
The message in this landscape is that the transition from quadrant
to quadrant is continuous and fluid.
To further label these projects:
Traditional projects are found in Quadrant 1;
Agile projects are found in Quadrant 2;
Extreme projects are found in Quadrant 3; and
Emertxe (pronounced ee-MERT-zee)
projects are found in Quadrant 4.
Project Management Landscape
Every project that ever existed or will exist, falls into only one of these
four quadrants at any point in time.
This landscape is not affected by external changes of any kind, but It is a robust landscape that will remain in place regardless.
The quadrant in which the project lies will provide an initial guide to choosing a best-fit project management life cycle (PMLC) model and adapting its tools, templates, and processes to the specific characteristics of the project.
As the project work commences and the goal and solution become clearer, the project’s quadrant can change, and perhaps the PMLC will then change as well; how- ever, the project is always in one quadrant.
The decision to change the PMLC for a project already underway may be a big change and needs to be seriously considered due to the costs, benefits, advantages, and disadvantages are associated with a mid-project change of PMLC.
Examine the different types of projects: traditional; agile, extreme and emertxe.
Project Management Landscape
You may have heard of the term “Iron Triangle.” It refers to the relationship between Time, Cost, and Scope.
These three variables form the sides of a triangle and are an interdependent set.
If any one of them changes, at least one other variable must also change to restore
balance to the project.
Consider the following constraints that operate on every project:
– Scope ■ Quality ■ Cost ■ Time ■ Resources ■ Risk
Except for Risk these constraints form an interdependent set—a change in one constraint can require a change in one or more of the other constraints in order to restore the equilibrium of the project.
In this context, the set of five parameters form a system that must remain in balance for the project to be in balance.
The Scope Triangle
Project Management Landscape
Scope
Scope is a statement that defines the boundaries of the project.
It tells not only what will be done, but also what will not be done. In the information systems industry, scope is often referred to as a functional specification.
In the engineering profession, it is generally called a statement of work.
Scope may also be referred to as a document of understanding, a scoping statement, a project initiation document, or a project request form
Whatever its name, this document is the foundation for all project work to follow.
It is critical that the scope be correct.
The Scope Triangle
Project Management Landscape
Quality
The following two types of quality are part of every project:
Product quality—The quality of the deliverable from the project. As used here
“product” includes tangible artefacts like hardware and software as well as
business processes.
The traditional tools of quality control, are used to ensure product quality.
Process quality—The quality of the project management process itself.
The focus is on how well the project management process works and how it can be improved.
Continuous quality improvement and process quality management are the tools used to measure process quality.
The Scope Triangle
Project Management Landscape
The Scope Triangle
Cost
The financial cost of doing the project is another variable that defines the project.
It is best thought of as the budget that has been established for the project.
This is particularly important for projects that create deliverables that are sold either commercially or to an external customer.
Cost is a major consideration throughout the project management life cycle.
The first consideration occurs at an early and informal stage in the life of a project.
The client can simply offer a figure about equal to what he or she had in mind for the project.
Depending on how much thought the client put into it, the number could be fairly close to or wide of the actual cost for the project.
Project Management Landscape
Time
The client specifies a time frame or deadline date for the project completion. To a certain extent, cost and time are inversely related to one another.
The time a project takes to be completed can be reduced, but costs increase as a result.
Time is an interesting resource.
It can’t be inventoried. It is consumed whether you use it or not. The objective for the project manager is to use the future time allotted to the project in the most effective and productive ways possible.
Future time (time that has not yet occurred) can be a resource to be traded within a project or
across projects.
Once a project has begun, the main resource available to the project
manager to keep the project on schedule or get it back on schedule is time.
A good project manager realizes this and protects the future time resource carefully.
The Scope Triangle
Project Management Landscape
Resources
Resources are assets such as people, equipment, physical facilities, or inventory that have limited availabilities, can be scheduled, or can be leased from an outside party.
Some are fixed; others are variable only in the long term. In any case, they are central to the scheduling of project activities and the orderly completion of the project.
For systems development projects, people are the major resource.
Another valuable resource for systems projects is the availability of computer processing time (mostly for testing purposes), which can present significant problems to the project manager with regard to project scheduling.
The Scope Triangle
Project Management Landscape
The Scope Triangle
Risk
Risk is not an integral part of the scope triangle, but it is always present and spans all parts of the project both external as well as internal, and therefore it does affect the management of the other five constraints.
Projects are dynamic systems
that must be kept in balance
Project Management Landscape
The geographic area inside the triangle represents the scope and quality of the project.
Lines representing time, cost, and resource availability bound scope and quality.
Time is the window of time within which the project
must be completed.
Cost is the financial budget available to complete the
project.
Resources are any consumables used on the project.
People, equipment availability, and facilities are
examples.
The Scope Triangle
Project Management Landscape
The project plan will have identified the time, cost, and resource availability needed to deliver the scope and quality of a project.
In other words, the project is in equilibrium at the completion of the project planning session and approval of the commitment of resources and dollars to the project.
The scope triangle offers a number
of insights into the changes that
can occur in the life of the project.
The Scope Triangle
Project Management Landscape
Project classification
There are many ways to classify a project such as:
By size (cost, duration, team, business value, number of departments affected, and so on)
By type (new, maintenance, upgrade, strategic, tactical, operational)
By application (software development, new product development, equipment installation, and so on)
By complexity and uncertainty
Project Management Landscape
Today’s Project Environment
The modern project environment is branded by high speed, high change,
lower costs, complexity, uncertainty, and a host of other factors.
This presents a daunting challenge to the project manager.
High Speed
The faster products and services get to market, the greater will be the resulting value to the business.
Current competitors are watching and responding to unmet opportunities, and new competition is waiting and watching to seize upon any opportunity that might give them a foothold or expansion in the market.
Any weakness or delay in responding may just give them that advantage. This need to be fast translates into a need for the project management approach to not waste time—to rid itself, as much as possible, of spending time on non-value added work.
Many of the approaches you will study are built on that idea, the window of opportunity is narrowing and constantly moving
Project Management Landscape
Today’s Project Environment
High Change
Clients are often making up their minds or changing their minds about what they want.
The environment is more the cause of high change than is any ignorance on the part of the client.
The business world is dynamic, it doesn’t stand still just because you are managing a project.
The best-fit project management approach must recognise the realities of frequent change,
accommodate it, and embrace it.
For experienced project managers as well as “wannabe” project managers, the road to breakthrough performance is uncertain and they need to be courageous, creative, and flexible.
If you simply rely on a routine application of someone else’s methodology, you are sure to fall short of the mark.
Project Management Landscape
Lower Cost
With the reduction in management layers (a common practice in many organisations) the
professional staff needs to find ways to work smarter, not harder.
Project management includes a number of tools and techniques that help the professional manage increased workloads.
Staffs need to have more room to do their work in the most productive ways possible. Burdening them with overhead activities for which they see little value is a sure way
to failure.
Drucker asks, “Why employ middle managers?” As technology advances and acceptance of
these ideas grows, we have seen the thinning of the layers of middle management.
Do not expect them to come back; they are gone forever, the effect on project managers is predictable and significant.
Hierarchical structures are being replaced by organisations that have a greater dependence on projects and project teams, resulting in more demands on project managers.
Today’s Project Environment
Project Management Landscape
Today’s Project Environment
Increasing Levels of Complexity
All of the simple problems have been solved but those that remain are getting more complex with each passing day.
At the same time that problems are getting more complex, they are
getting more critical to the enterprise.
They must be solved, we don’t have a choice. Not having a simple method for managing such projects is no excuse.
They must be managed, and we must have an effective way of managing them.
Project Management Landscape
More Uncertainty
With increasing levels of complexity comes increasing levels of uncertainty. The two are inseparable.
Adapting project management approaches to handle uncertainty means that the approaches must not only accommodate change, but also embrace it and become more effective as a result of it.
Change is what will lead the team and the client to a state of certainty with respect to a viable solution to its complex problems.
Therefore, project manager must have management approaches that expect change and benefit from it
Today’s Project Environment
Review of Last Week’s Activity
Continue to explore a suitable project for your module assessment
• Compare and contrast the two definitions of a project – which do you prefer?
• Where would you be able to bring about cost savings as a program manager for an organisation you are familiar with?
• Discuss these using the standard project constraints.
Project Management Landscape
Today’s Project Environment
Understanding the project landscape Wysocki (2014:3), provides a highly
practical framework / landscape in which we can begin to classify projects:
the extent a project has a clear or unclear goal
the extent a project has a clear or unclear solution.
Viewing projects through this simple framework;
we can begin to categorise all past, current and
future projects in one of the four quadrants.
The quadrant where the project lies provides an initial Perspective as to which specific project management life cycle (PMLC) can be adopted to best manage the project
Project Management Landscape
Today’s Project Environment
The scope triangle
Viewing projects through this simple framework help to categorise all past, current and future projects in one of the four quadrants.
The quadrant where the project lies provides an initial perspective as to which specific project management life cycle (PMLC) can be adopted to best manage the project.
Project Management Process Groups
Define the 5 Process Groups
The project landscape helps determine which Project Management Life Cycle (PMLC) model works best.
All PMLCs are constructed from five Process Groups:
Scoping;
Planning;
Launching;
Monitoring & Controlling; and
Closing.
The five Process Groups were originally defined by the
Project Management Institute (PMI) in their standards guidelines called:
“A Guide to the Project Management Body of Knowledge (PMBOKGuide)”.
24
Project Management Process Groups
Define the 5 Process Groups
A valid project management methodology must answer, whatever project management life cycle model that is used must contain all of the following Process Groups:
Scoping Process Group (which PMI calls the Initiating Process Group)
Planning Process Group
Launching Process Group (which PMI calls the Executing Process Group)
Monitoring and Controlling Process Group
Closing Process Group
These five Process Groups are the building blocks of every (Project Management Life Cycle).
In the simplest of cases, Linear TPM, the Process Groups will each be completed once and in the sequence listed here.
In more complex situations, some or all of the Process Groups might be repeated a number of times.
Project Management Process Groups
The Scoping Process Group
The PMBOKGuide includes scoping in the Initiating Process Group.
However, the term initiating can be confusing if you are new to project management.
The term scoping to be clearer. Scoping comes before Planning.
This Process Group includes all processes related to answering two questions:
“What business situation is being addressed?” and
“What does the business need to do?”
It does not include any processes related to doing any project work.
That project work is defined in the Planning Process Group to be done later in the project life cycle.
The Scoping Process Group also includes establishing the business success criteria that will be the metrics used to answer the question “How will you know you did it?”
Define the 5 Process Groups
Project Management Process Groups
Define the 5 Process Groups
The Scoping Process Group
The Scoping Process Group includes the following processes:
Identifying stakeholders
Recruiting the project manager
Eliciting the true needs and high-level requirements of the client
Documenting the client’s needs
Writing a one-page description of the project
Gaining senior management approval to plan the project.
As you can see, the successful completion of the Scoping Process Group is to gain the approval of senior management to move to the next phase of the project.
Be advised, however, that not all projects are approved to go to the Planning Phase.
In every PMLC, the next phase will be defined by the Planning Process Group.
For some models that planning will include the entire project, and for others it will encompass only the first cycle or iteration of the project.
Project Management Process Groups
Define the 5 Process Groups
The Planning Process Group
The Planning Process Group includes all processes related to answering two questions: “What will you do?” and “How will you do it?” These processes are as follows:
Defining all of the work of the project
Estimating how long it will take to complete the work
Estimating the resources required to complete the work
Estimating the total cost of the work
Sequencing the work
Building the initial project schedule
Analysing and adjusting the project schedule
Writing a risk management plan
Documenting the project plan
Gaining senior management approval to launch the project
Project Management Process Groups
Define the 5 Process Groups
The Launching Process Group
The PMBOKGuide calls this the Executing Process Group, it is that and more.
The Launching Process Group includes all processes related to recruiting and organizing the team and establishing the team operating rules.
These processes are preparatory to executing the project.
The Launching Process Group also includes all of the processes related to getting the project work started.
These would be the executing processes.
The Launching Process Group includes the following processes:
Recruiting the project team
Writing a project description document
Establishing team operating rules
Establishing the scope change management process
Managing team communications
Finalizing the project schedule
Writing work packages
Project Management Process Groups
Define the 5 Process Groups
The Launching Process Group
All of these processes relate more to the art of project management than to the science of project management. During the execution of this Process Group, the entire team may be coming together for the first time.
There will be client members and your delivery team members present.
Perhaps they are mostly strangers to one another.
At this point, they are nothing more than a group.
They are not yet a team but must become one in very short order.
The project manager will conduct that first team meeting with care, giving team members an opportunity to introduce themselves to each other and explain what they bring to the project.
Project Management Process Groups
Define the 5 Process Groups
The Monitoring and Controlling Process Group
The Monitoring and Controlling Process Group includes all processes related to answering the question, “How will you know you did it?” The Monitoring and Controlling Process Group includes all processes related to the ongoing work of the project. These processes are as follows:
Establishing the project performance and reporting system
Monitoring project performance
Monitoring risk
Reporting project status
Processing scope change requests
Discovering and solving problems.
Here is where the real work of the project takes place.
It occupies the project manager with activities internal to the project team itself and with activities external to the project team and dealing with the client, the sponsor, and your senior management.
As problems and change requests arise, the strength of your relationship with your client will in large measure contribute to the success or failure of the project.
Project Management Process Groups
The Closing Process Group
The Closing Process Group includes all processes related to the completion of the project-
, including answers to the question, “How well did you do?”
These processes are as follows:
Gaining client approval of having met project requirements
Planning and installing deliverables
Writing the final project report
Conducting the post-implementation audit.
The end is finally coming into sight, the client is satisfied that you have met the acceptance criteria, and it’s time to install the deliverables and complete the administrative closedown of the project.
Project Management Process Groups
Explore the ten project management Knowledge Areas
The ten Knowledge Areas are part of the PMBOKGuide and all are present in every project management life cycle.
They define the processes within each Process Group and often are part of more than one Process Group.
1.Project Integration Management
This Knowledge Area addresses the glue that links all of the deliverables from the Process Groups into a unified whole.
Also, the linkage begins with the project description document and extends to the project plan and its execution, including monitoring progress against the project plan and the integration of changes, and finally through to project closure.
Project Management Process Groups
Explore the ten project management Knowledge Areas
2. Project Scope Management
The major focus of the Project Scope Management Knowledge Area is the identification and documentation of client requirements.
Other ways exist to approach requirements gathering and documentation.
The choice of which approach or approaches to use depends on several factors.
Following requirements gathering and documentation – you choose the best-fit project management life cycle and develop the Work Breakdown Structure (WBS) that defines the work to be done to deliver those requirements.
That prepares the team and the client with the information they need to estimate time, cost, and resource requirements.
The Project Scope Management Knowledge Area overlaps the Scoping and the Planning Process Groups.
Project Management Process Groups
Explore the ten project management Knowledge Areas
3. Project Time Management
Project Time Management includes both a planning component and a control component.
The planning component provides time estimates for both the duration of a project task (that is, how long will it take in terms of clock time to complete the task) and the actual effort or labour time required to complete the task.
The duration is used to estimate the total time needed to complete the project.
The labour time is used to estimate the total labour cost of the project.
The control component is part of the Monitoring and Controlling Process Group and involves comparing estimated times to actual times as well as managing the schedule and cost variances.
Project Management Process Groups
Explore the ten project management Knowledge Areas
4. Project Cost Management
Project Cost Management includes both a planning component and a control component.
The planning component includes building the project budget and mapping those costs into the
project schedule.
This provides a means of controlling the consumption of budget across time.
Variance reports and earned value reports are used in the Monitoring and Controlling Process Group.
Project Management Process Groups
Explore the ten project management Knowledge Areas
5.Project Quality Management
Good quality management is probably one of the Knowledge Areas that gets a rather casual
treatment by the project manager and the team.
A good quality management program contains the following three processes:
Quality planning process
Quality assurance process
Quality control process
The focus on quality is usually on the product or deliverable that is produced. If it meets specific physical and performance characteristics, it will be validated as fit for use and can be released to the client.
Validation that a product is fit for use is the result of the product passing certain tests at various points in the product development
life cycle.
Passing these tests allows the product to pass to the next stage of development, failure to pass a test leads to reworking the
product until it passes or to outright rejection if reworking the product to remove whatever defects were discovered does not make
good business sense.
Quality in this context means the product meets the following criteria:
It’s fit for use.
It meets all client requirements.
It delivers on time, within budget, and according to specification.
Project Management Process Groups
Explore the ten project management Knowledge Areas
5. Project Quality Management
Quality Planning Process
There will be standards that the product and the process will have to meet.
These may be external to the organization (federal or agency quality requirements) or internal (company policies and guidelines).
In addition, there will be project-specific requirements that must be met and quality planning must integrate all of these into a cohesive program.
Quality Assurance Process
– Quality assurance includes activities that ensure compliance to the plan.
Quality Control Process
– This process involves the actual monitoring of the project management monitoring and
reporting tools.
Project Management Process Groups
6. Project Human Resource Management
Some would suggest that the job of the project manager is to manage the work of the project.
They would add that it is not the job of the project manager to manage the members of the team, and management of the team members is the province of their line manager.
In a ideal world, this might be acceptable management practice, but in the contemporary project world, the situation is quite different.
More than likely your request for a certain profile of skills and experiences among your team members will not be met by those who are assigned to work on your project.
Skill shortages, unavailability of a specifically skilled person, and other factors will result in a less-than-adequate team.
The line manager is responsible for assigning people to projects in accordance with each person’s skill and competency profile as well as his or her career and professional development plans.
Once a person is assigned to a project, it is then the project manager’s responsibility to make assignments in accordance with the person’s skill and competency profile and their professional development plans.
Explore the ten project management Knowledge Areas
Project Management Process Groups
7. Project Communications Management
At the heart of many of the top ten reasons why projects fail is poor communications.
As many as 70 percent of the IS/IT project failures can be traced back to poor communications.
It is not difficult to plan an effective communications management process, but it seems to be very difficult to execute that plan.
A good communications management process will have provisions in the process that answer the following questions:
Who are the project stakeholders?
What do they need to know about the project?
How should their needs be met?
Explore the ten project management Knowledge Areas
Project Management Process Groups
Explore the ten project management Knowledge Areas
7. Project Communications Management
Who Are the Project Stakeholders?
Any person or group that has a vested interest in the project is a stakeholder.
Those who are required to provide some input to the project affect the project and are therefore stakeholders.
They may not be willing stakeholders, but they are stakeholders nevertheless.
Those who are affected by the project are stakeholders.
Often they are the same group requesting the project, in which case they will be willing stakeholders.
There will also be unwilling stakeholders who are affected by the project but had little or no say in how the project actually delivered against stated requirements.
The project manager needs to be aware of all these stakeholder groups and communicate appropriately to them.
Project Management Process Groups
Explore the ten project management Knowledge Areas
7. Project Communications Management
What Do They Need to Know about the Project?
There will be a range of concerns and questions coming from every stakeholder group. Some of the more commonly occurring are as follows:
What input will I be required to provide the project team?
How can I make my needs known?
When will the project be done?
How will it affect me?
Will I be replaced?
How will I learn how to use the deliverables?
Your communications management plan will be effective only if it accounts for each group and their individual needs.
Project Management Process Groups
Explore the ten project management Knowledge Areas
How Should Their Needs Be Met?
This depends on the purpose of the communication.
If it’s to inform, there will be many alternatives to choose from.
If it’s to get feedback, you have fewer alternatives from which to choose.
7. Project Communications Management
Project Management Process Groups
Explore the ten project management Knowledge Areas
How Should Their Needs Be Met?
This depends on the purpose of the communication.
If it’s to inform, there will be many alternatives to choose from.
If it’s to get feedback, you have fewer alternatives from which to choose.
Project Management Process Groups
Explore the ten project management Knowledge Areas
8. Project Risk Management
In project management, a risk is some future event that happens with some probability and results in a change, either positive or negative, to the project. For the most part, risk is associated with loss, at least in the traditional sense.
A risk event is associated with a loss of some type, the result might be a cost increase, a schedule slippage, or some other catastrophic change, and the cost of loss can be estimated.
The estimate is the mathematical product of the probability that the event will occur and the severity of the loss if it does.
This estimate will force the project manager to make a choice about what to do, if anything, to mitigate the risk and reduce the loss that will occur.
This estimate is the basis of a series of choices that the project manager has to make. First of all, should any action be taken?, and if the cost of the action exceeds the estimated loss, no action should be taken. Simply hope that the event doesn’t occur.
The second choice deals with the action to be taken, if action is called for, what form should it take? Some actions may simply reduce the probability that the event will occur.
Other actions will reduce the loss that results from the occurrence of the event. It is usually not possible to reduce either the probability or the loss to zero.
Whatever actions are taken will only tend to reduce the loss in the final analysis.
Project Management Process Groups
Explore the ten project management Knowledge Areas
8. Project Risk Management
Risk management is a broad and deep topic,
A number of reference books on the topic are available.
The risk analysis and management process should answer the following questions:
What are the risks?
What is the probability of loss that results from them?
How much are the losses likely to cost?
What might the losses be if the worst happens?
What are the alternatives?
How can the losses be reduced or eliminated?
Will the alternatives produce other risks?
To answer these questions, the following sections define risk management in four phases:
identification of risk; assessment of risk; risk response planning, and monitoring and controlling.
Project Management Process Groups
8. Project Risk Management
There are four risk categories:
Technical Risks Project
Management Risks
Organizational Risks
External Risks
Activity
Use the blank sheet/space to identify any risk on each category
Project Management Process Groups
Explore the ten project management Knowledge Areas
There are four risk categories:
Technical Risks Project
Management Risks
Organizational Risks
External Risks
8. Project Risk Management
Risk Mitigation
The next step in risk management is
to plan, as much as possible,
the responses that will be used if
the identified risks occur
For all the risks listed in the risk identification that you choose to act upon, you should have some type of
action in mind.
It’s not enough to simply list the risks; you need to plan to do something about the risk events should they occur.
Project Management Process Groups
Explore the ten project management Knowledge Areas
9.Project Procurement Management
The Project Procurement Management Knowledge Area consists of processes that span the Planning, Launching, Monitoring and Controlling, and Closing Process Groups.
An effective procurement management life cycle consists of the following five phases:
. Vendor solicitation (2). Vendor evaluation (3). Vendor selection (4). Vendor
(5). Contracting and (5). Vendor management.
As a project manager, you will always have projects for which you must obtain hardware, software, or services from outside sources.
This process is known as procurement, which requires the professional project manager to have a basic understanding of the acquisition procedure so that he or she can ensure that the organisation is getting the right materials at the best cost or the best services at the best cost.
Project Management Process Groups
Explore the ten project management Knowledge Areas
9. Project Procurement Management
Vendor Solicitation
After you’ve done your requirements gathering and have made the decision that you need an outside vendor.
Then you can begin to prepare procurement documents for solicitation. These documents, called Requests for Proposals (RFPs), are what vendors use to determine if and how they should respond to your needs.
The clearer the RFP, the better off you and the vendor are, because you will be providing basic information about what you want (don’t forget about the earlier discussion of needs versus wants).
The more specific you are, the better the chance that the vendor will be able to respond to you quickly and efficiently.
Project Management Process Groups
Explore the ten project management Knowledge Areas
9. Project Procurement Management
Vendor Evaluation
Before you even start reading the responses to your proposal, set the standards for choosing a given vendor.
The criteria may be based on technical expertise, experience, or cost, but whatever criteria you use, it must remain the same for all of the vendors.
If you are a public company, every vendor you’ve turned down will ask for a copy of the winning bid.
If they think they have a better bid, all sorts of nasty things may occur. If, however, you have a standards chart, you can point out that everyone was rated with the same criteria and that the winner had the best overall number.
By determining your criteria for vendor selection early in the process, it is easier to make a decision and then defend it if need be.
Project Management Process Groups
Explore the ten project management Knowledge Areas
9. Project Procurement Management
Vendor Selection
The result of vendor evaluation usually does not produce a single best choice.
There will most likely be several competing vendors for all or parts of the work. So you have another decision to make and that is which vendor or vendors will win your business.
Selecting the vendor is a critical decision.
There is no guarantee that even if you diligently follow the evaluation process, you will end up with a vendor that you are comfortable with and whom you can select with confidence.
Some selection processes may result in failure.
Project Management Process Groups
Explore the ten project management Knowledge Areas
9. Project Procurement Management
Vendor Contracting
Contract management involves the following:
The vendor must supply you with deliverable dates so that you can deter-mine whether the project is on time.
The vendor should also supply a WBS detailing how the vendor breaks down the scope of the project and showing the tasks that make up the completion of a deliverable.
The project manager should hold regular status meetings to track progress. These meetings should be formal and occur on specified dates.
The status meetings should occur at least once a week, although in the early stages of the project, you may choose to have them more often.
Project Management Process Groups
Explore the ten project management Knowledge Areas
9. Project Procurement Management
Vendor Management
Vendor management means including them in every team activity for which it makes sense to have them involved.
Starting a contract on the right foot avoids a lot of subsequent frustration for both parties.
A good start-up allows the project team and contractor team working relationship to be established early on so that they can function as a unified team throughout the project.
Communication needs to be established early among all relevant stakeholders in order to optimize the development environment before the implementation starts.
Conducting meetings and having face-to-face discussions are the easiest and best ways to set clear expectations and gain a mutual understanding of the requirements and expected performance.
It is important to remember that the individuals who created and sent the RFP response may not be the same individuals who will actually work on the project.
Project Management Process Groups
Explore the ten project management Knowledge Areas
10. Project Stakeholder Management
Project Stakeholder Management was introduced in the PMBOKGuide, 5th Edition, as the tenth Knowledge Area.
It covers stakeholder identification, planning, management, and control. The PMBOKGuide defines a stakeholder as anyone who either affects or is affected by the project or its deliverables.
In this book, I will expand on that general definition and have occasion to discuss the following seven stakeholder types:
Sponsors
Clients
Customers
Business process engineers
Resource managers
Project managers
Business analysts
These seven stakeholders form an interdependent set.
Project Management Process Groups
Explore the ten project management Knowledge Areas
Process Groups and Knowledge Areas are closely linked.
What the Mapping Means
This mapping shows how interdependent the
Knowledge Areas are with the Process Groups.
For example, eight of the ten Knowledge
Areas are started during the Planning
Process Group and executed during the
Monitoring and Controlling Process
Group.
That gives clear insight into the
importance of certain deliverables in
the project plan and guidance as to
the content of the project plan
Project Management Process Groups
Understand the relationship between the five
Process Groups and ten Knowledge Areas
How to Use the Mapping
The mapping provides an excellent blueprint for designing your project management approach to a project. For example, Procurement Management spans the Planning, Launching, Monitoring and Controlling, and Closing Process Groups. Therefore, a PMLCmodel for Procurement Management will be effective if it has components in each of those Process Groups.
Using Process Groups to Define PMLCs
Many who are new to project management make the mistake of calling the Process Groups a project management methodology. This is incorrect. However, by properly sequencing and perhaps repeating some Process Groups, you can define PMLCsthat are project management methodologies.
So the Process Groups are the building blocks of project management methodologies. Similarly, by selecting and adapting the processes within a Process Group, you can establish the specific processes that drive a PMLC. So the processes within a Process Group are the detailed building blocks of the phases of the PMLC.
Choosing and adapting a best-fit PMLC to the RBS.
Although you may have easily arrived at a best-fit approach and best-fit PMLC model based on the confidence you have with the RBS.
Any Questions ?
End of Session Activity
Formative Assessment on Arts and Culture Festival or a self-determined project of your choice from within the Creative Industries Sector.
Select Teams of up to 4 students and prepare for formative presentation.
•Present the project for next week.
End of Session Activity
Formative Assessment Present the project for next week.
Case Study Review of 1) Arts and Culture Festival or 2) a self-determined project of your choice from within the Creative Industries Sector Event.
Acting as a senior Project Managers; you should identify a project which would plausibly generate “value” for Arts and Culture Festival or a self-determined project of your choice from within the Creative Industries Sector event.
Agree in the team what type of project you wish to undertake.
1.Describe the project and outline why it would generate value. You will use this project throughout the module so make sure you select a project which interests you.
2.Secondly, summarise one of the five process groups of your choice –linking it to Arts and Culture Festival or a self-determined project of your choice from within the Creative Industries Sector event.
Group Presentation –10 minutes per group –Formative Assessment
Reading Materials
Core Textbook:
Wysocki, R, K; (2009), EfffectiveProject Management: traditional, agile, extreme–5thedition, Indianapolis, Wiley. http://
capitadiscovery.co.uk/bcu/items/1091130
Other useful Textbooks–or any Project Management book
Cobb, C, G: (2011) Making sense of agile project management: balancing control and agility. Hoboken, N:J Wiley http://
capitadiscovery.co.uk/bcu/items/1138767
Maylor, H (2010) Project Management. Harlow: Prentice Hall Financial Times http://capitadiscovery.co.uk/bcu/items/1047967
powerpoint/MAN7084 Week-Session 4 Version.pptx
MAN7084 Project Management
Week/Session 4
Project Management Case-study
(Review Formative Presentation Session)
Teaching Team:
Kulbir Bains – kulbir.bains@bcu.ac.uk
Suhel Khan – suhel.khan@bcu.ac.uk
Session objectives
Brief Recap of Last Week
Questions
Formative Team Presentations
General Feedback
Project Management Landscape
Today’s Project Environment
The Four quadrants of the projects landscape
Understanding the project landscape (Wysocki 2014:3) provides a highly pragmatic framework / landscape in which we can begin to classify projects:
the extent a project has a clear or unclear goal and
the extent a project has a clear or unclear solution.
Viewing projects through this simple framework help to categorise all past, current and future projects in one of the four quadrants.
The quadrant where the project lies provides an initial perspective as to which specific project management life cycle (PMLC) can be adopted to best manage the project.
The Four quadrants of the projects landscape
Project Management Process Groups
Define the 5 Process Groups
The project landscape helps determine which
Project Management Life Cycle (PMLC) model works best.
All PMLCs are constructed from five Process Groups:
1. Scoping;
2. Planning;
3. Launching;
4. Monitoring & Controlling; and
5. Closing
The five Process Groups were originally defined by the Project Management
Institute (PMI) in their standards guidelines.
Known as “A Guide to the Project
Management Body of Knowledge” (PMBOK) Guide).
Project Management Process Groups
Define the 5 Process Groups
A valid project management methodology must answer, whatever project management life cycle model that is used, must contain all of the following Process Groups:
Scoping Process Group (which PMI calls the Initiating Process Group)
Planning Process Group
Launching Process Group (which PMI calls the Executing Process Group)
Monitoring and Controlling Process Group
Closing Process Group
These five Process Groups are the building blocks of every PMLC (Project Management Life Cycle).
In the simplest of cases, Linear TPM, the Process Groups will each be completed once and in the sequence listed here.
In more complex situations, some or all of the Process Groups might be repeated a number of times.
Project Management Landscape
The Scope Triangle
The geographic area inside the triangle represents the scope and quality of the project.
Lines representing time, cost, and resource availability bound scope and quality.
Time is the window of time within which the project must be completed.
Cost is the financial budget available to complete the
project.
Resources are any consumables used on the project.
People, equipment availability, and facilities are examples.
Project Management Landscape
The Scope Triangle
Risk
Risk is not an integral part of the scope triangle, but it is always present and spans all parts of the project both external as well as internal, and therefore it does affect the management of the other five constraints
Projects are dynamic systems that must be kept in equilibrium.
Project Management Landscape
Today’s Project Environment
Viewing projects through this simple framework help to categorise all past, current and future projects in one of the four quadrants.
The quadrant where the project lies provides an initial perspective as to which specific project management life cycle (PMLC) can be adopted to best manage the project.
Project Management Process Groups
Explore the ten project management Knowledge Areas
Project Risk Management
There are four risk categories:
Technical Risks Project
Management Risks
Organizational Risks
External Risks
Project Management Process Groups
Explore the ten project management Knowledge Areas
8. Project Risk Management
Risk Mitigation
The next step in risk management is to plan, as much as possible, the responses that will be used if the identified risks occur.
For all the risks listed in the risk identification that you choose to act upon, you should have some type of action in mind.
It’s not enough to simply list the risks; you need to plan to do something about the risk events should they occur.
There are four risk categories:
Technical Risks Project
Management Risks
Organizational Risks
External Risks
What the Mapping Means
This mapping shows how interdependent the Knowledge Areas are with the Process Groups.
For example, eight of the ten Knowledge Areas are started during the Planning Process Group and executed during the Monitoring and Controlling Process Group.
That gives clear insight into the importance of certain deliverables in the project plan and guidance as to the content of the project plan.
Process Groups and Knowledge Areas are closely linked.
Understand the relationship between the five Process Groups
and ten Knowledge Areas
Project Management Process Groups
Project Management Process Groups
Understand the relationship between the five Process Groups and ten Knowledge Areas
How to Use the Mapping
The mapping provides an excellent blueprint for designing your project management approach to a project, example, like Procurement Management spans the Planning, Launching, Monitoring and Controlling, and Closing Process Groups.
Therefore, a PMLC model for Procurement Management will be effective if it has components in each of those Process Groups.
Using Process Groups to Define PMLCs
Many who are new to project management make the mistake of calling the Process Groups a project management methodology.
This is incorrect; but by properly sequencing and perhaps repeating some Process Groups, you can define PMLCs that are project management methodologies.
So the Process Groups are the building blocks of project management methodologies, by selecting and adapting the processes within a Process Group, you can establish the specific processes that drive a PMLC.
So the processes within a Process Group are the detailed building blocks of the phases of the PMLC.
Choosing and adapting a best-fit PMLC to the RBS.
Although you may have easily arrived at a best-fit approach and best-fit PMLC model based on the confidence you have with the RBS.
Project Management Process Groups
Any questions?
Session Activity
Formative Assessment on any Industry/Sector or a self-determined project of your choice.
Team Practice presentation
Good luck
powerpoint/MAN7084 Week2 Project Management Landscape.pptx
MAN7084 Project Management
Week 2
Project Management Landscape
(Student Input Session)
Teaching Team:
Kulbir Bains – kulbir.bains@bcu.ac.uk
Suhel Khan – suhel.khan@bcu.ac.uk
Session objectives
Last week recap
Assessment recap
Last week’s activity
Project Management Landscape
Questions?
Activity
Project Management
What a project management is:
As the application of processes, methods, knowledge, skills and experience to achieve the project objectives.
Also, as the vehicles of change in an organisation, they are not the repetitive business-as-usual type of activity.
Is essentially aimed at producing an end product or deliverable that will effect some change for the benefit of the organisation.
Project start with the initiation, planning and control of a range of tasks required to deliver this end product.
Projects are different sizes and are directed at the achievement of benefits.
Projects operate within a predetermined budget and timespan and there is usually risk involved which needs to be managed.
Project Management
Last Week Recap Continue….
Project Management is complicated in the fact that various professional bodies exist.
We researched these to understand their differences.
Accounting bodies are complimentary yet approach the subject differently.
Some of the main bodies are:
PRINCE 2 – UK / EU • PMBOK / PMI – US – which this module is based upon
APM – UK
Project Management
APM Body of Knowledge online (see last week slides)
APM, the Chartered body for the project profession, has created a unique digital resource that
allows users to explore areas essential in the management of projects, programmes and portfolios.
It is structured around several sections including definitions of the core terms and techniques.
APM Body of Knowledge online is the result of a collaborative project involving over 1,000
practitioners and specialists from across all sectors, and is designed to assist all those using project
management in their work or studies
The APM Body of Knowledge forms the basis of APM’s qualifications, accreditation, research and
publications.
It defines the boundaries of project, programme and portfolio management, and the functions undertaken as part of these endeavours.
Last Week Recap Continue….
Project Management
PRINCE2 (an acronym for PRojects IN Controlled Environments)
is a de facto process based method for effective project management.
Used extensively by the UK Government, PRINCE2 is also widely recognised and used in the private sector, both in the UK and internationally.
The PRINCE2 method is in the public domain, and offers non-proprietorial best practice guidance on project management.
Key features and focused of PRINCE2:
Business justification
Defined organisation structure for the project management team
Product-based planning approach
Emphasis on dividing the project into manageable and controllable stages
How flexibility can be applied appropriately at all levels of the project
PRINCE2 History
First established as PRINCE in 1989 by CCTA (the Central Computer and Telecommunications Agency), office later renamed the OGC
(the Office of Government Commerce).
In June 2010, the Office of Government Commerce Best Practice Management functions moved into the Cabinet Office.
PRINCE was originally based on PROMPT, a project management method created by Simpact Systems Ltd in 1975, and adopted by CCTA in 1979 as the standard to be used for all Government information system projects.
When PRINCE was launched in 1989, it effectively superseded PROMPT within Government projects.
PRINCE remains in the public domain and copyright is retained by the Crown.
PRINCE2 was published in 1996, having been contributed to by a consortium of some 150 European organisations
PMBOK (Project Body of knowledge)
What is a project?
It’s a temporary endeavour undertaken to create a unique product, service or result.
A project is temporary in that it has a defined beginning and end in time,
and therefore defined scope and resources.
A project is unique, not a routine operation, but a specific set of operations designed to accomplish a particular goal.
Project team often includes people who don’t usually work together – sometimes from different organisations and across multiple geographies.
PMBOK – Project Management Body of Knowledge (PMBOK® )
Can use developed software to improved business process, like construction of a building, bridge, the relief effort after a natural disaster, the expansion of sales into a new geographic market — all are projects.
Is expertly managed to deliver the on-time, on-budget results, learning and integration that organisations need.
Project management, then, is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.
PMBOK – Project Management Body of Knowledge
Who are Project Managers?
They are organised, passionate and goal-oriented, understand what projects have in common, play strategic role in how organisations succeed, learn and change.
They are change agents, make project goals their own, use their skills and expertise to inspire a sense of shared purpose within the project team.
They enjoy new challenges and have the responsibility of driving business results.
They work well under pressure and are comfortable with change, challenge and complexity in dynamic environments and results oriented for business.
They can shift readily between the “big picture” and the small-but-crucial details, knowing when to concentrate on each.
Project managers cultivate the people skills needed to develop trust and communication among all of a project’s stakeholders: its sponsors, those who will make use of the project results
Recap Assessment
The module is assessed by a Case Study (3000 word report) in Week 15
3000 word individual report/assignment allows you to apply your project management knowledge in a practical way based around a common-themed case study on an Arts and Culture Festival, or a self-determined project of your choice from within the Creative Industries Sector or that addresses the following:
1.Traditional, Agile, xPM and MPx considerations
2.The five stages of a PMLC (project management life cycle) model for the project
3. Any project planning considerations & an outline of how you would manage and
control the project.
4. Project risk management & managing any potential scope creep
5. Project stakeholder management & Managing client expectations
6. How you would close the project and transfer any relevant learning to future projects.
7. Remember to add a conclusion and critical set of recommendations.
Recap End of Last Session Activity
Explore a suitable project for your module assessment
Identify a project within an industry and organisation relevant to you which can be used for your assessment.
A project can be past, present or future – even artificial but it is important you understand the key aspects of the project e.g. purpose, complexity, intended outcome, an idea of the resources required, etc.
What are your findings?
Today’s session
Project Management Landscape
Project Management
Define what project management refers to:
2.Recognise the project management landscape; and
3.Examine the different types of projects: traditional; agile, extreme and emertxe.
Project Definition (Wysocki 2014)
A sequence of finite dependent activities whose successful completion results in the delivery of the expected business value that validated doing the project” (Wysocki2014:3).
For more definitions – see Project Management Bodies
Project Management Landscape
Recognise the project management landscape
A project comprises a number of activities that must be completed in
some specified order, or sequence.
For now, an activity is a defined chunk of work. The sequence of the activities is based on technical requirements, not on management prerogatives.
To determine the sequence, it is helpful to think in terms of inputs and outputs. The output of one activity or set of activities becomes the input to another activity or set of activities.
Specifying a sequence based on resource constraints or statements, such as “Pete will work on activity B as soon as he finishes working on activity A,” should be avoided because this establishes an artificial relationship between activities. What if Pete wasn’t available at all?
Resource constraints aren’t ignored when you actually schedule activities. The decision of what resources to use and when to use them comes later in the project planning process.
Project Management Landscape
Recognise the project management landscape
The activities in a project are unique.
Something is always different each time the activities of a project are repeated.
Usually the differences are random in nature—for example, a part is delayed, someone is sick, or a power failure occurs.
These random variations are the challenge for the project manager and what contributes to the uniqueness of the project.
Complex Activities:
The activities that make up the project are not simple, repetitive acts, like mowing the lawn, painting the rooms in a house, washing the car, or loading the delivery truck.
Instead they are complex; example, designing an intuitive user interface to an application system is a complex activity.
(Case-Study: BP Oil Spill – Complexity).
Project Management Landscape
Recognise the project management landscape
Connected Activities:
The logical or technical relationship between pairs of activities.
There is an order to the sequence in which the activities that make up the project must be completed.
They are considered connected because the output from one activity is the input to another, for example, you must design the computer program before you can program it.
You could have a list of unconnected activities that must all be complete in order to complete the project. For example, consider painting the interior rooms of a house. With some exceptions, the rooms can be painted in any order.
The interior of a house is not completely painted until all its rooms have been painted, but they can be painted in any order.
Painting the house is a collection of activities, but it is not considered a project according to the definition.
Project Management Landscape
Recognise the project management landscape
One Goal
Projects must have a single goal, may be very large, complex projects, may be divided
into several subprojects, each of which is a project in its own right.
This division makes for better management control; for example, subprojects can be defined at the department, division, or geographic level.
This artificial decomposition of a complex project into subprojects often simplifies the scheduling of resources and reduces the need for interdepartmental
communications while a specific activity is worked on.
The downside is that the projects are now interdependent. Even though interdependency adds another layer of complexity and communication, it can be handled.
Case-Study: Columbia Shuttle (Complexity & Communication).
Project Management Landscape
Specified Time:
Recognise the project management landscape
Projects are finite with continuous processes, have a specified completion date.
This date can be self-imposed by management or externally specified by a client or government agency, the deadline is beyond the control of anyone working on the project.
The project is over on the specified completion date whether or not the project work has been completed.
Being able to give a firm completion date requires that a start date also be known. Absent a start date, the project manager can only make statements like, “I will complete the project 6 months after
I start the project.” In other words, the project manager is giving a duration for the project, and Senior management wants a deadline.
Project Management Landscape
Recognise the project management landscape
Within Budget
Projects also have resource limits, such as a limited amount of people, money, or machines that are dedicated to the project.
These resources can be adjusted up or down by management, but they are considered fixed resources by the project manager, for example, suppose a company has only one web designer at the moment.
That is the fixed resource that is available to project managers, Senior management have the authority to change the number of resources, but not the case with the project manager.
If the one web designer is fully scheduled, the project manager has a resource conflict that he or she cannot resolve.
Resource constraints become operative when resources need to be scheduled across several projects
Project Management Landscape
Recognise the project management landscape
According to Specification
The client, or the recipient of the project’s deliverables, expects a certain level of functionality and quality from the project.
The expectations can be self-imposed, like the specification of the project completion date, or client-specified, such as producing the sales report on a weekly basis.
Although the project manager treats the specification as fixed, the reality of the situation is that any number of factors can cause the specification to change.
For example, the client may not have defined the requirements completely at the beginning of the project, or the business situation may have changed (which often happens in projects with long durations).
It is unrealistic to expect the specification to remain fixed through the life of the project.
Project Management Landscape
Recognise the project management landscape
According to Specification
Systems specification can and will change, thereby presenting special challenges to the project manager.
Specification satisfaction has been a continual problem for the project man-ager and accounts for a large percentage of project failures.
Project managers deliver according to what they believe are the correct specifications only to find out that the customer is not satisfied.
Somewhere there has been an expectation or communications disconnect. The Conditions of Satisfaction (COS) process is one way of managing potential disconnects.
Project Management Landscape
Recognise the project management landscape
A Business-focused Definition of a Project
The major shortcoming of the preceding definition of a project is that, it isn’t focused on the purpose of a project, which is to deliver business value to the client and to the organization.
A lots of examples exist of projects that meet all of the constraints and conditions specified in the definition, but the client is not satisfied with the results.
Reasons for this dissatisfaction are discussed throughout the book. Therefore, a better definition for your consideration.
A project is a sequence of finite dependent activities whose successful completion results in the delivery of the expected business value that validated doing the project.
Time for a Break
Back in 15 / 20 Minutes
Remember to complete the register during this time.
Thank you.
Project Management Landscape
Examine the different types of projects: traditional; agile, extreme and emertxe.
Projects are not viewed in isolation.
The organisation will have collections of all types of projects running in parallel and drawing on the same limited resources, so you will need a way of describing that landscape and providing a foundation for management decision making.
Every project must have a goal and a solution.
You could use a number of metrics to quantify these characteristics, but the simplest and most intuitive will be two values: clear and complete or not clear and incomplete.
Two values for each characteristic generate the four-quadrant matrix.
Project Management Landscape
Examine the different types of projects: traditional; agile, extreme and emertxe.
These values are conceptual, not quantifiable, and their interpretation is certainly more subjective than objective.
A given project can exhibit various degrees of clarity. The message in this landscape is that the transition from quadrant to quadrant is continuous and fluid.
To further label these projects;
Traditional projects are found in Quadrant 1
Agile projects are found in Quadrant 2;
Extreme projects are found in Quadrant 3, and
Emertxe (pronounced ee-MERT-zee) projects are found in Quadrant 4.
Project Management Landscape
Examine the different types of projects:
traditional; agile, extreme and emertxe.
Every existing or will falls into only one of these four quadrants at any point in time.
This landscape is not affected by external changes of any kind. It is a robust landscape that will remain in
place regardless.
The quadrant in which the project lies will provide an initial guide to choosing a best-fit project
management life cycle (PMLC) model and adapting its tools, templates, and processes to the specific
characteristics of the project.
As the project work commences and the goal and solution become clearer, the project’s quadrant can change, and perhaps the PMLC will then change as well; regardless, the project is always in one quadrant.
The decision to change the PMLC for a project already underway may be a big change and needs to be seriously considered. Costs, benefits, advantages, and disadvantages are associated with a mid-project change of PMLC.
Project Management Landscape
Recognise the project management landscape
Defining a Program: A program is a collection of related projects.
The projects may have to be completed in a specific order for the program to be considered complete.
Because programs comprise multiple projects, they are larger in scope than a single project, (e.g. a construction company contracts a program to build an industrial technology park with several separate projects).
Unlike projects, programs can have many goals.
Project Management Landscape
Recognise the project management landscape
Defining a Portfolio:
A simple definition of a project portfolio is that it is a collection of projects that share some common link to one another.
The operative phrase in this definition is “share some common link to one another, that link could take many forms.
At the organisational level, the link might be nothing more than the fact that all the projects belong to the same company.
While that will always be true, it is not too likely the kind of link you are looking for. It is too general to be of any management use.
Project Management Landscape
Recognise the project management landscape
Defining a Portfolio:
Some more useful and specific common links might be any one of the following:
The projects may all originate from the same business unit; e.g. information technology.
The projects may all be new product development projects.
The projects may all be research and development projects.
The projects may all be infrastructure maintenance projects from the same business unit.
The projects may all be process improvement projects from the same business unit.
The projects may all be staffed from the same human resource pool.
The projects may request financial support from the same budget.
Project Management Landscape
The Scope Triangle
You may have heard of the term “Iron Triangle.”
It refers to the relationship between Time, Cost, and Scope.
These three variables form the sides of a triangle and are an interdependent set. If any one of them changes, at least one other variable must also change to restore balance to the project.
Consider the following constraints that operate on every project:
Scope ■Quality ■Cost ■Time ■Resources ■Risk
Except for Risk these constraints form an interdependent set—a change in one constraint can require a change in one or more of the other constraints in order to restore the stability of the project.
In this context, the set of five parameters form a system that must remain in balance for the project to be in balance.
Project Management Landscape
The Scope Triangle
Scope
Scope is a statement that defines the boundaries of the project.
It tells not only what will be done, but also what will not be done.
In the information systems industry, scope is often referred to as a functional specification.
In the engineering profession, it is generally called a statement of work.
Scope may also be referred to as a document of understanding, a scoping statement, a project initiation document, or a project request form.
Whatever its name, this document is the foundation for all project work to follow.
It is critical that the scope be correct.
Project Management Landscape
The Scope Triangle (Add Video on Product/process quality)
Quality
The following two types of quality are part of every project:
Product quality – The quality of the deliverable from the project.
As used here “product” includes tangible artefacts like hardware and software as well as business processes.
The traditional tools of quality control, are used to ensure product quality.
Process quality — The quality of the project management process itself.
The focus is on how well the project management process works and how it can be improved.
Continuous quality improvement and process quality management are the tools used to measure process quality.
Project Management Landscape
The Scope Triangle
Cost
The financial cost of doing the project is another variable that defines the project, best thought of as the budget that has been established for the project.
This is particularly important for projects that create deliverables that are sold either commercially or to an external customer.
Cost is a major consideration throughout the project management life cycle. The first consideration occurs at an early and informal stage in the life of a project.
The client can simply offer a figure about equal to what he or she had in mind for the project.
Depending on how much thought the client put into it, the number could be fairly close to or wide of the actual cost for the project.
Project Management Landscape
The Scope Triangle
Time
The client specifies a time frame or deadline date within which the project must be completed.
To a certain extent, cost and time are inversely related to one another.
The time a project takes to be completed can be reduced, but costs increase as a result.
Time is an interesting resource, it can’t be inventoried, it is consumed whether you use it or not.
The objective for the project manager is to use the future time allotted to the project in the most effective and productive ways possible.
Future time (time that has not yet occurred) can be a resource to be traded within a project or across projects.
Once a project has begun, the prime resource avail-able to the project manager to keep the project on schedule or get it back on schedule is time.
A good project manager realizes this and protects the future time resource carefully.
Project Management Landscape
The Scope Triangle
Resources
Resources are assets such as people, equipment, physical facilities, or inventory that have limited availabilities, can be scheduled, or can be leased from an outside party.
Some are fixed; others are variable only in the long term. In any case, they are central to the scheduling of project activities and the orderly completion of the project.
For systems development projects, people are the major resource.
Another valuable resource for systems projects is the availability of computer processing time (mostly for testing purposes), which can present significant problems to the project manager with regard to project scheduling.
Project Management Landscape
The Scope Triangle
Risk
Risk is not an integral part of the scope triangle, but it is always present and spans all parts of the project both external as well as internal, and therefore it does affect the management of the other five constraints.
Projects are dynamic systems that must be kept in equilibrium.
Project Management Landscape
The Scope Triangle
The geographic area inside the triangle represents
the scope and quality of the project.
Lines representing time, cost, and resource
availability bound scope and quality.
(Organisation’s resources refer to as ?)
Time is the window of time within which the project must be completed.
Cost is the financial budget available to complete the project.
Resources are any consumables used on the project.
People, equipment availability, and facilities are examples.
Project Management Landscape
The Scope Triangle
The project plan will have identified the time, cost, and resource
availability needed to deliver the scope and quality of a project.
In other words, the project is in equilibrium at the
completion of the project planning session and
approval of the commitment of resources and dollars
to the project.
The scope triangle offers a number of insights
into the changes
that can occur in the life of the project.
Project Management Landscape
Project classification
There are many ways to classify a project such as:
By size (cost, duration, team, business value, number of departments affected, and so on)
By type (new, maintenance, upgrade, strategic, tactical, operational)
By application (software development, new product development, equipment installation, and so on)
By complexity and uncertainty.
Project Management Landscape
Today’s Project Environment
The contemporary project environment is regarded as, by high speed, high change,
lower costs, complexity, uncertainty, and a host of other factors. This presents a daunting challenge to the project manager.
High Speed
The faster products and services get to market, the greater will be the resulting value to the business.
Why – Competitors are watching and responding to unmet opportunities, others are waiting and watching to seize upon any opportunity that might give them a foothold or expansion in the market.
Any weakness or delay in responding may just give them that advantage.
This need to be fast translates into a need for the project management approach to not waste time—to rid itself, as much as possible, of spending time on non-value-added work.
Many of the approaches you will study are built on that evidence. The window of opportunity is narrowing and constantly moving
Project Management Landscape
Today’s Project Environment
High Change
Clients are often making up their minds or changing their minds about what they want.
The environment is more the cause of high change than is any ignorance on the part of the client.
The business world is dynamic, it doesn’t stand still just because you are managing a project.
The best-fit project management approach must recognize the realities of frequent change, accommodate it, and embrace it.
For experienced project managers as well as “wannabe” project managers, the road to breakthrough performance is paved with uncertainty and with the need to be courageous, creative, and flexible.
If you simply rely on a routine application of someone else’s methodology, you are sure to fall short of the mark.
Project Management Landscape
Today’s Project Environment
Lower Cost
With the reduction in management layers (a common practice in many organizations) the professional staff needs to find ways to work smarter, not harder.
Project management includes a number of tools and techniques that help the professional manage increased workloads.
Your staffs need to have more room to do their work in the most productive ways possible.
Burdening them with overhead activities for which they see little value is a sure way to failure.
Drucker asks, “Why employ middle managers?” As technology advances and acceptance of these ideas grows, we have seen the thinning of the layers of middle management.
Do not expect them to come back; they are gone forever, and the effect on project managers is predict-able and significant.
Hierarchical structures are being replaced by organizations that have a greater dependence on projects and project teams, resulting in more demands on project managers.
Project Management Landscape
Today’s Project Environment
Increasing Levels of Complexity
All of the simple problems have been solved.
Those that remain are getting more complex with each passing day, at the same time, problems are get-ting more complex and critical to the enterprise.
They must be solved, we don’t have a choice and not having a simple method for managing such projects is no excuse.
They must be managed, and we must have an effective way of managing them.
Project Management Landscape
Today’s Project Environment
More Uncertainty
With increasing levels of complexity comes increasing levels of uncertainty. The two are inseparable.
Adapting project management approaches to handle uncertainty means that the approaches must not only accommodate change, but also embrace it and become more effective as a result of it.
Change is what will lead the team and the client to a state of certainty with respect to a viable solution to its complex problems.
In other words, we must have project management approaches that expect change and benefit from it.
End of Session
Continue to explore a suitable project for your module assessment
Compare and contrast the two definitions of a project –which do you prefer?
Where would you be able to bring about cost savings as a program manager for an organisation you are familiar with?
Discuss these using the standard project constraints.
Research the project for next week.
Activity
Any questions?
Reading Materials
Core Textbook
Wysocki, R, K; (2009), EfffectiveProject Management: traditional, agile, extreme–5thedition, Indianapolis, Wiley. http://
capitadiscovery.co.uk/bcu/items/1091130
Another Text:
Other useful Textbooks–or any Project Management book
Cobb, C, G: (2011) Making sense of agile project management: balancing control and agility. Hoboken, N:J Wiley http://
capitadiscovery.co.uk/bcu/items/1138767
Maylor, H (2010) Project Management. Harlow: Prentice Hall Financial Times http://
capitadiscovery.co.uk/bcu/items/1047967
Gray and Larson (2008) Project Management: The Managerial Process, McGraw-Hill
powerpoint/MAN7084 Wk_Session 5.pptx
Week/Session 5
Project Scoping & Project Scheduling
(Student Input Session)
MAN7084Project Management
Session objectives
Brief recap of last Week
Project Management Scoping and Project Scheduling
Questions?
Activity
Project Management Tools
Tools / Methodologies:
Work Breakdown Structure (WBS)
Gantt Charts
PERT / CPM (Program Evaluation and Review Technique / Critical Path Method)
Project Management Landscape
You may have heard of the term “Iron Triangle.”
It refers to the relationship between Time, Cost, and Scope.
These three variables form the sides of a triangle and are an interdependent set.
If any one of them changes, at least one other variable must also change to restore balance to the project. Consider the following constraints that operate on every project:
Scope ■ Quality ■ Cost ■ Time ■ Resources ■ Risk
Except for Risk these constraints form an interdependent set — a change in one constraint can require a change in one or more of the other constraints in order to restore the equilibrium of the project.
In this context, the set of five parameters form a system that must remain in balance for the project to be in balance.
The Scope Triangle
Project Management Landscape
The following two types of quality are part of every project:
Product quality:
The quality of the deliverable from the project, as used here “product” includes tangible artefacts like hardware and software as well as business processes.
The traditional tools of quality control, are used to ensure product quality (i.e. Flowchart, Check Sheet, Cause and Effect Fish Bone etc.)
Process quality:
The quality of the project management process itself, the focus is on how well the project management process works and how it can be improved.
Continuous quality improvement and process quality management are the tools used to measure process quality.
The Scope Triangle
Quality
Project Management Landscape
The Scope Triangle
Risk is not an integral part of the scope triangle, but it is always present and spans all parts of the project both external as well as internal, but does affect the management of the other five constraints.
Projects are dynamic systems that must be kept in equilibrium.
Risk
Project Management Landscape
The Scope Triangle
The geographic area inside the triangle represents the scope and quality of the project.
Lines representing time, cost, and resource availability bound scope and quality.
Time is the window of time within which the project must be completed.
Cost is the financial budget available to complete the project.
Resources are any consumables used on the project.
People, equipment availability, and facilities are examples.
Project Management Landscape
The Scope Triangle
The project plan will have identified the time, cost, and resource availability needed to deliver the scope and quality of a project.
In other words, the project is in equilibrium at the completion of the project planning session and approval of the commitment of resources and dollars to the project.
The scope triangle offers a number of insights into the changes that can occur in the life of the project.
Project Management Landscape
Today’s Project Environment
1) The extent a project has a clear or unclear goal and
2) The extent a project has a clear or unclear solution.
By viewing projects through this simple framework;
We can begin to categorise all past, current and future projects in one of the four quadrants.
The quadrant where the project lies provides an initial perspective as to which specific project management life cycle (PMLC) can be adopted to best manage the project.
Understanding the project landscape Wysocki (2014:3) provides a highly pragmatic framework landscape in which we can begin to classify projects:
Project Management Landscape
Viewing projects through this simple framework; we can begin to categorise all past, current and future projects in one of the four quadrants.
The quadrant where the project lies provides an initial perspective as to which specific project management life cycle (PMLC) can be adopted to best manage the project.
Project Management Process Groups
The project landscape helps determine which Project Management Life Cycle (PMLC) model works best.
Define the 5 Process Groups
All PMLCs are constructed from five Process Groups:
1. Scoping
2. Planning
3. Launching
4. Monitoring & Controlling – and
5. Closing.
The five Process Groups were originally defined by the Project Management Institute (PMI)
Standards guidelines, called:
A Guide to the Project Management Body of Knowledge (PMBOKGuide).
Project Management Process Groups
Define the 5 Process Groups
A valid project management methodology must answer, whatever project management life cycle model that is used must contain all of the following Process Groups:
Scoping Process Group (which PMI calls the Initiating Process Group)
Planning Process Group
Launching Process Group (which PMI calls the Executing Process Group)
Monitoring and Controlling Process Group
Closing Process Group
These five Process Groups are the building blocks of every PMLC (Project Management Life Cycle).
In the simplest of cases, Linear TPM, the Process Groups will each be completed once and in the sequence listed here.
In more complex situations, some or all of the Process Groups might be repeated a number of times.
Project Management Process Groups
Although you may have easily arrived at a best-fit approach and best-fit PMLC model based on the confidence you have with the RBS.
Choosing and adapting a best-fit PMLC to the Resources Breakdown Structure
(RBS).
Project Management Project Scheduling
Understanding interconnectivities of clients/project scoping
The Scoping Process Group defines all of the:
tools, templates, and processes needed to answer two questions:
What will you do?” and
How will you know you did it?”
If you don’t know where you are going, how will you know when and if you ever get there?
Projects can get off to a terrible start simply because there never was a clear understanding of exactly what was to be done.
A definition of completeness was never documented and agreed to.
Project Management Project Scheduling
Understanding interconnectivities of clients/project scoping
Knowing your client, your organisation’s environment/ the market situation and tools to adapt, templates, and processes to them is part of the art of scoping.
Almost all of the scoping effort involves an interaction and collaboration between the client who is requesting a service or product and the project manager who is providing the service or product.
That collaboration can be very informal (the “back of the napkin” approach) or very formal (a planned Scoping Meeting).
In both cases, a document is prepared that answers the questions:
What will you do? and
How will you know you did it?
The nature of that relationship will contribute to how the scoping effort proceeds and how successful it is likely to be.
Project Management Project Scheduling
Understanding interconnectivities of clients/project scoping
The following tools, templates, and processes can be used:
Conditions of Satisfaction
Project Scoping Meeting
Requirements expected
Facilitated Group Sessions
Interviews
Prototyping
Requirements Workshops
Project Overview Statement
Approval to plan the project
Project Management Project Scheduling
Understanding interconnectivities of clients / project scoping
Clients often expect more than project managers are prepared for or capable of delivering, this lack of communication starts at the beginning of a project and extends all the way to the end.
The project manager assumes he or she knows what the client is asking for and the client assumes the project manager understands what they are asking for.
In many cases that is simply not true and little is done to check the validity of either of those assumptions
Conducting Conditions of Satisfaction
It is a tool that establishes a language of communication and understanding between the project manager and the client.
Understand at the outset that the tool is easy to explain and understand, but demands constant attention if it is to make a difference.
Project Management Project Scheduling
Understanding interconnectivities of clients/project scoping
Wants versus Needs
The root cause of many communications problems originates from disconnects between what the client says they want and what they really need.
If the project manager doesn’t pay attention, that disconnect may not be very obvious at the beginning of the scoping phase but only become obvious later when correcting it may be costly.
The disconnect may come about because the client is so swept up in a excitement over the technology (for example, they may be hooked with what they see on the web).
They convinced themselves they have to have it without any further thought of exactly what it is they really need.
Project Management Project Scheduling
Understanding interconnectivities of clients / project scoping
Wants versus Needs
Wants and needs are closely linked to one another but are fundamentally different.
Experience client wants tend to be associated with a solution to a problem that they envision.
Needs tend to be associated with the actual problem.
If wants are derived from a clear understanding of needs, then it is safe to proceed based on what the client wants, but you cannot always know that this is the case.
By continuing this practice of asking why, you will eventually get to the root of the problem and needs will then become clear.
This is not unlike a Root Cause Analysis.
The solution to that problem will be what the client really needs.
Your job as project manager is to convince the client that what they want is what they really need.
Project Management Project Scheduling
Understanding interconnectivities of clients/project scoping
Conducting Conditions of Satisfaction
You should always begin every scoping exercise with a Conditions of Satisfaction (COS) session.
The COS is a structured conversation between the client (the requestor) and the likely project manager (the provider).
The deliverable from the COS is a one-page document (with attachments) called the Project Overview Statement (POS).
The POS is a template that is used to clearly state what is to be done.
It is signed by the requestor and the provider as a record of their COS session.
When the POS is approved by senior management, the Scoping Phase is complete and the project moves to the Planning Phase.
Project Management Project Scheduling
Understanding interconnectivities of clients/project scoping
Wants versus Needs
The process of developing the COS involves the following four parts:
Request — A request is made by the client.
Clarification — The provider explains what he or she heard as the request ( this conversation continues until the client is satisfied that the provider clearly understands the request) both parties have now established a clear understanding of the request in the language of the requestor.
3. Response — The provider states what he or she is capable of doing to satisfy the request.
4. Agreement — The client restates what he or she understands the provider will provide.
The conversation continues until the provider is satisfied that the client clearly understands what is being provided, at this point, both parties have established a clear understanding of what is being provided in the language of the provider.
Project Management Project Scheduling
Understanding interconnectivities of clients/project scoping
Establishing Clarity of Purpose
By the time you leave the COS session, both you and the client have stated your positions and know that the other party understands your position.
You have established the beginnings of a common language with common terminology, that is critically important.
You and the client will have planted the seeds for a continuing dialogue.
As the project work progresses, any changes that come up can be dealt with effectively because the effort to understand each other has been made up front.
The final step in the COS process is to negotiate to closure on exactly what will be done to meet the request; usually some type of compromise will be negotiated.
The final agreement is documented in the POS, more than likely, the parties will not come to an agreement on the first pass.
Project Management Project Scheduling
Understanding interconnectivities of clients / project scoping
Specifying Business Outcomes
As indicated in the previous section, it is a good idea to specify within the COS exactly what outcomes demonstrate that the COS has been met.
The outcomes have been called success criteria, explicit business outcomes, and objectives, among other names. Whatever term you use, you are referring to a quantitative metric that signals success.
That metric is discussed in more detail later in the chapter, for now just understand that it is a quantitative measure (for example, profit, cost avoidance, and improved service levels) that defines success.
Project Management Project Scheduling
Understanding interconnectivities of clients / project scoping
Conducting COS Milestone Reviews
The COS is not a static agreement.
It is a dynamic agreement that becomes part of the continual project monitoring process.
Situations change throughout the project life cycle and so will the needs of the client, that means that the COS will change.
Review the COS at every major project status review and project milestone.
Does the COS still make sense?
If not, change it and adjust the project plan accordingly.
Project Management Project Scheduling
Understanding interconnectivities of clients/project scoping
The Project Scoping Meeting
You have a variety of ways to scope a project.
At one extreme is a formal multiple-day meeting and at the other extreme is scoping on the back of a napkin over a cup of coffee at the local coffee stand.
Both extremes and all of the variants in between are valid. It all depends. This section suggests the best way to scope a project based on my experiences.
The Project Scoping Meeting is your first substantive encounter with the cli-ent.
You may have conducted a COS session and agreed on a high-level scope for the project but need more detail in order to write a POS.
The Project Scoping Meeting takes the COS deliverable to the next level of detail.
In this meeting, the core project team will be present, as will the client, several key managers, staff, a facilitator, and representative users of the project deliverables.
Project Management Project Scheduling
Understanding interconnectivities of clients/project scoping
Purpose
The Scoping Meeting has two purposes.
To create the Requirements Breakdown Structure (RBS).
To draft the POS.
The RBS is used to help the team decide which project management approach is the best fit for this type of project.
Project Management Project Scheduling
Understanding interconnectivities of clients/project scoping
Attendees
Project Scoping Meeting attended by 15–20 people is large but manageable.
An experienced meeting facilitator could manage a group of more than 20 people, but it requires breakout groups and their coordination.
This is definitely the territory of a skilled facilitator and that is not the project manager.
The project manager needs to focus on the scoping of the project, not on conducting the Scoping Meeting.
The two activities require different skillsets.
Project Management Project Scheduling
Understanding interconnectivities of clients / project scoping
The following three groups need to be represented at the Scoping Meeting:
The client group — Decision makers as well as operations-level staff should be represented. Among them should be the individual(s) who suggested the project.
The project manager and core members of the project team —The core members are the experienced professionals who will be with the project from beginning to end.
For larger projects, they will be the future sub-project managers and activity managers. In some cases, critical but scarce skilled professionals might also be present.
The facilitator group – This group might comprise two or three individuals who are experienced in conducting Scoping and Planning Meetings.
The following three groups need to be represented at the Scoping Meeting:
Description of the end state (led by the client representative)
Requirements elicitation and decomposition (led by the facilitator)
Discussion of the gap between the current and end states
Choose the best-fit project management approach to close the gap (led by the project manager)
Draft and approve the POS (whole group)
Adjourn
Understanding interconnectivities of clients / project scoping
Project Management Project Scheduling
Project Management Project Scheduling
Understanding interconnectivities of clients / project scoping
Project Scoping Meeting Deliverables
RBS creation
Assessment of completeness of RBS
Project classification
Determination of best-fit PMLC model
The POS
Project Management Project Scheduling
Understanding interconnectivities of clients/project scoping
Creating the RBS
These high-level requirements form a necessary and sufficient set for achieving project success.
That is usually enough detail for POS purposes.
Requirements decomposition can take place after the POS has been approved and the project is deemed feasible.
Either the Project Scoping Meeting or the Project Planning Meeting will be the appropriate event at which requirements decomposition can be done.
If you expect requirements decomposition to be complex, take several days, and consume too many resources, you might want to wait until after the POS has been approved and your project idea is judged to be feasible before you spend the resources needed to generate the RBS.
Project Management Project Scheduling
Understanding interconnectivities of clients / project scoping
Creating the RBS
Project Management Project Scheduling
Understanding interconnectivities of clients / project scoping
Creating the RBS
Function — At the discretion of the project manager, the highest level of decomposition may be at the function level.
This level comprises the functions that must be performed in order for a solution to be acceptable.
It is important to understand that the RBS reflects what is known about the solution at the time the RBS is first defined.
Activity — Activities are otherwise known as process steps.
Feature — At the lowest level of decomposition are features.
These are the visible enhancements and characteristics of the entity that they describe.
This initial list of functions may or may not be complete, neither you nor the client can be expected to know if that list is complete.
You might know that it is incomplete, but you wouldn’t know that it is complete. How could you? For the sake of generating the RBS, you have to proceed on the basis that the initial list will be complete.
If it turns out that it is not, you will discover that as part of doing the project
Project Management Project Scheduling
Understanding interconnectivities of clients / project scoping
Creating the RBS
Sub-function: At the next level of decomposition are sub-functions.
For some functions, you may not have any idea of what those sub-functions might be and that is okay.
In any case, the project team should make every effort to identify the sub-functions that further define a function.
Once these sub-functions have been developed, the function they define will now be complete.
This is the same as the premise underlying the WBS architecture and is very intuitive.
For many adaptive projects, additional sub-functions will be discovered as part of doing the project.
Process — Complex functions and sub-functions can be further described with the business processes that comprise them.
These are the business processes that are commonly used in today’s organisations.
To make them more understandable, the functions might be decomposed into sub-functions and the business processes that comprise the sub-functions then decomposed to processes.
Project Management Project Scheduling
Understanding interconnectivities of clients / project scoping
Creating the RBS
Business Process Engineers —These are the technical person(s) who have stewardship responsibilities for the design and implementation of the associated business processes that are affected by or affect the deliverables.
Resource Managers —These are the managers of any resources that will be needed in the production of the product or services delivered by the project.
Project Manager —These are the enablers. They are the facilitators of the requirements elicitation and decomposition process. They are responsible for managing the resources to produce the project deliverables.
Business Analysts —These professionals are familiar with the customer processes and user practices and the processes they will be using to apply the products or services delivered by the project.
They will often act as support to the project manager and as an interface with the customer or the user group.
Their primary responsibility is to help the project manager and customer transform stated business needs into business requirements.
Project Management Project Scheduling
Understanding interconnectivities of clients / project scoping
Creating the RBS
36
Project Management Project Scheduling
Understanding interconnectivities of clients / project scoping
Creating the RBS
Project Management Tools
Work Breakdown Structure (WBS):
Project Management Tools
Work Breakdown Structure (WBS):
Project Management Tools
Gantt charts:
Core Textbook
Wysocki, R, K; (2009), Efffective Project Management: traditional, agile, extreme–5thedition, Indianapolis, Wiley. http://capitadiscovery.co.uk/bcu/items/1091130
Other useful Tex-books–or any Project Management book
•Cobb, C, G: (2011) Making sense of agile project management: balancing control and agility. Hoboken, N:J Wiley http://capitadiscovery.co.uk/bcu/items/1138767
•Maylor, H (2010) Project Management. Harlow: Prentice Hall Financial Times http://capitadiscovery.co.uk/bcu/items/1047967
Reading Materials
Any questions?
End of Session Activity
Download and practice with Project Management Software:
Download Project Libre
Alternatively try use Microsoft Project –Free Trial (BCU Desktop)
https://
products.office.com/en-us/project/project-professional-desktop-software
https://
en.softonic.com/download/projectlibre/mac/post-download?sl=1
Windows Link
Mac OS Link
https://
en.softonic.com/download/projectlibre/mac/post-download?sl=1
Reading Materials
Wysocki, R, K; (2009), EfffectiveProject Management: traditional, agile, extreme–5thedition, Indianapolis, Wiley. http://capitadiscovery.co.uk/bcu/items/1091130
Other useful Texbooks–or any Project Management book
•Cobb, C, G: (2011) Making sense of agile project management: balancing control and agility. Hoboken, N:J Wiley http://capitadiscovery.co.uk/bcu/items/1138767
•Maylor, H (2010) Project Management. Harlow: Prentice Hall Financial Times http://capitadiscovery.co.uk/bcu/items/1047967
Core Textbook
powerpoint/MAN7084 Wk_Session 6.pptx
Week/Session 6
Recruiting the Project Team
MAN7084 Project Management
Session objectives
Brief recap of last week
Project Management Team Recruitment and Team Performance
Recap of Assignment
Q & A
Last week Student – Progress Check
With reference to the principles of scheduling carry out an analysis of the primary activities for a project of your choice
Project Management Landscape -Recap
Quality
The following two types of quality are part of every project:
Product quality: The quality of the deliverable from the project. As used here “product” includes tangible artefacts like hardware and software as well as business processes.
– The traditional tools of quality control, are used to ensure product quality.
Process quality: The quality of the project management process itself, focused is on how well the project management process works and how it can be improved.
– Continuous quality improvement and process quality management are the tools used to measure
process quality.
The Scope Triangle –Recap
Project Management Landscape
The Scope Triangle
Risk
Risk is not an integral part of the scope triangle – but,
It always present and spans all parts of the project both external as well as internal
Therefore, it does affect the management of the other five constraints.
Projects are dynamic systems that must be kept in equilibrium.
The Scope Triangle
Project Management Landscape
The geographic area inside the triangle represents the scope and quality of the project.
Lines representing time, cost, and resource availability bound scope and quality.
Time is the window of time within which the project must be completed.
Cost is the financial budget available to complete the project.
Resources are any consumables used on the project; People, equipment availability, and facilities are examples.
Project Management Landscape
The Scope Triangle
The project plan will have identified the time, cost, and resource availability needed to deliver the scope and quality of a project.
In other words, the project is in equilibrium at the completion of the project planning session and approval of the commitment of resources and dollars to the project.
The scope triangle offers a number of insights into the changes that can occur in the life of the project
Project Management Landscape
Today’s Project Environment
Understanding the project landscape (Wysocki2014:3) provides a highly pragmatic framework / landscape in which we can begin to classify projects:
1) the extent a project has a clear or unclear goal and
2) the extent a project has a clear or unclear solution.
Viewing projects through this simple framework;
we can begin to categorise all past, current and future projects in one of the four quadrants.
The quadrant where the project lies provides an initial perspective as to which specific project management life cycle (PMLC) can be adopted to best manage the project.
Today’s Project Environment
Project Management Landscape
Viewing projects through this simple framework; we can begin to categorise all past, current and future projects in one of the four quadrants. The quadrant where the project lies provides an initial perspective as to which specific project management life cycle (PMLC) can be adopted to best manage the project.
Define the 5 Process Groups
The project landscape helps determine which Project Management Life Cycle (PMLC) model works best.
Project Management Process Groups
All PMLCs are constructed from five Process Groups:
1.Scoping;
2.Planning;
3.Launching;
4.Monitoring & Controlling; and
5.Closing.
The five Process Groups were originally defined by the Project Management Institute (PMI) in their standards guidelines called A Guide to the Project Management Body of Knowledge (PMBOKGuide).
Project Management Process Groups
Define the 5 Process Groups
A valid project management methodology must answer, whatever project management life cycle model that is used must contain all of the following Process Groups:
Scoping Process Group (which PMI calls the Initiating Process Group)
Planning Process Group
Launching Process Group (which PMI calls the Executing Process Group)
Monitoring and Controlling Process Group
Closing Process Group
These five Process Groups are the building blocks of every PMLC(Project Management Life Cycle).
In the simplest of cases, Linear TPM, the Process Groups will each be completed once and in the sequence listed here.
In more complex situations, some or all of the Process Groups might be repeated a number of times.
Choosing and adapting a best-fit PMLC to the RBS.
Although you may have easily arrived at a best-fit approach and best-fit PMLC model based on the confidence you have with the RBS.
Project Management Process Groups
Recruiting the Project Team
Project Management Recruitment
Project Management Recruitment
What is a team?
Belbin Group or Team formation,
Adopted from: (Mullins, 2013:302)
Project Management Recruitment
Effective Teams
Effective communication channels
Clear goals and aims
Good planning/SMART objectives
Ownership of tasks and challenges
Support and encouragement
Defined roles and responsibilities
Effective team leaders
Do any of these aspects align with motivational theories?
Project Management Recruitment
Benefits of an Effective Team
Trust and co-operation
Recognition
Motivated team/organisational goals
Alignment to team/Organisational goals
Willing staff
Confident and capable team members
Welcome new ideas
Able to react to change
Building an effective team
Project Management Recruitment
Tuckman Team Development Model
Project Management Recruitment
How to motivate a team
Individuals have different motivations
Teams, work together for the benefit of all, willing, encourage each other.
Content theories – what motivates – achievement of objectives, social – belonging to a team,
Tangible rewards – what they symbolise, may be motivational /demotivation to all
Process theories – how to motivate
Project Management Recruitment
Manager’s Role in Motivating Individuals and Teams
What are manager’s responsible for within organisation
How can you recognise what motivates individuals?
How can you motivate individuals?
How ca you motivate the team?
John Adair (1979) Action Centred Leadership Model (adopted from Mullins 2010)
Project Management Recruitment
The critical roles and chemistry that must exist between and among the project manager and the team members.
The selection of you as the project manager and your team members will not be perfect—there are always risks with any personnel decision.
In addition to choosing you as the project manager the project team will have two or three separate components. Clients (internal or external to the company) and the core team are required.
Contract team members are required only when the project outsources segments of the project work.
When recruiting and building an effective team, you must consider:
Project Management Recruitment
Be aware of the characteristics that should be part of an effective project team.
The following sections describe the responsibilities of each of the three components of the project team.
Also provided are a checklist that should assist you in your selection process and guidelines for organising the project in an organisation.
Core team
Client team
Contract team
The project team has the following three separate components:
Project Management Recruitment
Core Team Members
Core team members are with the project from cradle to grave.
They have major role to play in the project,
Bring a skillset that has broad applicability across the range of work undertaken in the project.
They might also have responsibility for key tasks or sets of tasks in the project.
Although the ideal assignment for Agile Project Management (APM) and Extreme Project Management (xPM) projects is full-time, that is rarely the case in today’s business environment.
In matrix organisations, professional staff can be assigned to more than one project at a time.
This case is especially true when a staff member possesses a skill not commonly found in the staff.
They will be assigned to several projects concurrently.
A core team member will have some percentage of his or her time allocated to the project — it is not likely you will get them full-time.
Project Management Recruitment
When to Select the Core Team Members
Because the core team will be needed for the Joint Project Planning Session (JPPS),
its members should be identified as early as possible.
The core team is usually identified at the beginning of the scoping phase.
– This means that the members can participate in the early definition and planning of the project.
The following characteristics have been identified by project managers
as being the most important for core team members to possess:
Commitment to the project – This is critical to the success of the project.
The project manager must know that each core team member places a high priority on fulfilling his or her roles and responsibilities in the project.
The core team must be proactive in fulfilling those responsibilities and not need constant reminders of schedules and deliverables from the project manager.
Project Management Recruitment
Meaning that success and failure are equally the reward and blame of each team member.
Having shared responsibility means that you will never hear one team member taking individual credit for a success on the project, or blaming another team member for a failure on the project.
All share equally in success and failure.
Also, when a problem situation arises, all will pitch in to help in any way.
If one team member is having a problem, another will voluntarily be there to help.
3. Flexibility
Team members must be willing to adapt to the situation.
“That is not my responsibility” doesn’t go very far in project work.
Schedules may have to change at the last minute to accommodate an unexpected situation.
It is the success of the project that has priority, not the schedule of any one person on the project team.
2. Shared responsibility
Project Management Recruitment
Core Team Members
4. Task-oriented – In the final analysis:
It is the team members’ ability to get their assigned work done according to the project plan that counts.
Ability to work within schedules and constraints
Part of being a member of the team is your ability to consistently complete assignments within the planned time frame instead of offering excuses for failing to do so.
Team members will encounter a number of obstacles, such as delays caused by others, but;
They will have to find a way around those obstacles.
The team depends on its members to complete their work according to plan.
Project Management Recruitment
5. Trust and mutual support
These are the hallmarks of an effective team, and every member must convey these qualities.
Team members must be trusting and trustworthy.
Are they empathetic and do they readily offer help when it is clear that help is needed?
Their interaction with other team members will clearly indicate whether they possess these characteristics. Individuals who do not will have a difficult time working effectively on a project team.
Core Team Members
6. Team-oriented
To be team-oriented means to put the welfare of the team ahead of your own.
Behaviours as simple as the individual’s use of “I” versus “we” in team meetings and conversations with other team members are strong indicators of team orientation.
Project Management Recruitment
7. Open-minded
The open-minded team member will welcome and encourage other points of view and other solutions to problem situations.
His or her objective is clearly to do what is best for the team and not look for individual kudos.
The most important attribute is to not hide problems – get them out in the open ASAP and give other team members a chance to help.
Core Team Members
8. Ability to work across structure and authorities
In contemporary organizations, projects tend to cross organizational lines.
Cross-departmental teams are common.
Projects such as these require the team member to work with people from a variety of business disciplines.
Many of these people will have a different value system and a different approach than the team member might be used to.
Adaptability, flexibility, and openness are desirable assets.
Project Management Recruitment
The team member must be able to leverage technology in carrying out his or her project responsibilities.
Projects are planned using a variety of software tools, and the team member must have some familiarity with these tools.
Many project managers will require the team member to input task status and other progress data directly into the project management software tool.
9. Ability to use project management tools
Core Team Members
Project Management Recruitment
Client Team
You may have no choice about who the client assigns to your team.
Be cautious, however, that individuals might get this assignment merely because they aren’t too busy back in their home departments.
There may be a good reason why they weren’t too busy. (I’ll let you guess why that might be.)
When to Select the Client Team
These people need to be assigned in time to participate in the Project Kick-Off Meeting.
Many of them might have been part of the JPPS, and that would be a bonus.
They are probably assigned to the project for some percentage of their time rather than full time.
In some cases, they might join the team when work on their area of responsibility is being done.
If that is the case, they should still be identified along with others and kept informed of project status.
Project Management Recruitment
All you will likely be able to do is profile the skills and experiences of the client team members you will need.
Perhaps specification by position title would be preferred by both the client and the project manager.
Also, you would like to have client members with some decision-making authority.
If not, the client members will have to return to their supervisor or manager for decisions.
That can slow project progress.
Selection Criteria
The business-to-business environment is changing, and many changes are permanent.
Therefore, organizations are routinely outsourcing processes that are not part of their core business or core expertise.
As a result, project managers have been forced to use contract team members instead of their company’s own employees for one or both of the following reasons:
Shortage of staff
Shortage of skills
Contract Team Members
Project Management Recruitment
These shortages have made it possible for a whole new type of business to grow
Tech-temps is the name I associate with this new business opportunity.
The day of the small contractor and niche market player is here to stay.
To the project manager, this creates the need to effectively manage a team whose membership will probably include outside contractors.
Some may be with the project for only a short time.
Others may be no different from full-time core team members except that they are not company employees.
Selection Criteria (Contract Team Members)
Shortage of skills
Typically, contract team members are available to work on the project for only short periods of time.
A contract team member may possess a skill that is needed for just a brief time, and he or she is assigned to the project for that time only.
As soon as the assigned task is completed, he or she leaves the project.
Refer to Chapter 3 for additional discussion of Procurement Management.
Project Management Recruitment
Selection Criteria for Project Management
In small groups as Project Manager(s) what 3 out of 9 characteristics that have been identified most important for core team members to possess.
Be PREPARED TO DISCUSS YOUR FINIDINGS TO GROUP AS A WHOLE? (10 MINS)
Project Management Recruitment
BREAK 20 MINS
In most systems development efforts, it is unlikely that professionals would be assigned full-time to the project team, rather, people will join the project team only for the period of time during which their particular expertise is needed.
The project manager must be aware of the implications to the project when contract professionals are used, which may include the following:
There may be little or no variance in the time contracted team members are available, so the tasks on which they work must remain on schedule.
They must be briefed on their role in the project and how their task relates to other tasks in the project.
Commitment of contract members is typically a problem because their priorities probably lie elsewhere.
Quality of work may be an issue because of poor levels of commitment.
They just want to get the job done and get on with their next assignment. Often anything will do.
Contract team members will often require more supervision than core team members.
Implications of Adding Contract Team Members
Contract team members present the project manager with a number of challenges:
Project Management Recruitment
Selection Criteria
Project Management Recruitment
If as a project manager, you’ve made the decision to buy rather than build a project team,
you must determine who will get your business.
Contract team members are usually employed or represented by agencies that cater to technical professionals who prefer freelancing to full-time employment.
These professionals are available for short-term assignments in their area of specialisation.
To employ these professionals, you must make the following decisions: what process you’re going to follow, who should be invited to submit information, and how you’re going to evaluate the information received.
The evaluation often takes the form of a score sheet (The score sheet contains questions grouped by major features and functions, with weights attached to each answer).
A single numeric score is then calculated to rank vendor responses (see next slide).
Non-quantitative data such as client relations and client services are also collected from reference accounts provided by the vendor.
Here are the steps you might take as a project manager to engage the services of a contract team member:
Identify the types of skills and the number of personnel needed, and the time frame within which they will be required.
Identify a list of companies that will be invited to submit a proposal.
Write the Request for Proposal (RFP).
Establish the criteria for evaluating responses and selecting the vendor(s).
Distribute the RFP.
Evaluate the responses.
Reduce the list of vendors to a few who will be invited onsite to make a formal presentation.
Conduct the onsite presentations.
Choose the final vendor(s), and write and sign the contract.
Selection Criteria Continue….
Project Management Recruitment
Developing a Team Development Plan
After you’ve assembled your team and assessed each member’s characteristics, you may discover several
areas in which the team is noticeably weak.
Although your job as project manager is to manage the work of the project not to be a career or professional development manager, you still have to get the project done, and any imbalance on the team can be a barrier to your success.
As project manager, identify the high-risk areas that are not covered by at least one team member who can deal with those types of risks.
As part of your risk management plan, put a development plan in place for selected members of the team.
What form might that development plan take? Here are two possibilities:
Project Management Recruitment
You might want to use a conflict-resolution management behaviour called masked behaviour.
That training involves creating an awareness of the behaviour that is lacking and practicing it under supervision.
(For example, technology professionals are generally not very good people persons)
Sensitivity training for these team members might include listening skills, learning how to be a team player, acceptance of change, diversity training, and other related interpersonal skills training
You might consider sensitivity training for all or some of the team.
Briefly, it means that you find the person on your team whose normal behaviour is as close as possible to the missing behaviour.
That person then role-plays as though his or her normal behaviour were the missing behaviour.
Project Management Recruitment
Decision Making
Team members make decisions continuously as they engage in the work of the project, and
Some of those decisions are obvious and straightforward and may not require the involvement of other team
Members
However, other decisions are more complex and may require the involvement and active participation of the team, the client, and even people outside of the project.
Directive:
The person with the authority (the project manager for the project and the task manager for the task) makes the decision for all team members.
Although this approach is certainly expedient, it has obvious drawbacks.
The only information available is the information that the decision maker possesses, which may or may not be correct or complete.
An added danger is that those who disagree or were left out of the decision may be resistant or unwilling to carry it out.
A directive approach is often used when time is of the essence and a decision is needed immediately.
It makes no sense to hold a committee meeting to get everyone’s input before proceeding.
The three major types of decision-making models are as follows:
Project Management Recruitment
Decision Making
Participative—
In this model, everyone on the team contributes to the decision-making process.
A interaction is created as the best decision is sought, because everyone has an opportunity to participate, commitment will be much stronger than in the directive approach.
Obviously, there is an additional benefit to team building — empowerment of the team.
Highly recommended to use this participative approach whenever possible.
Because the team members have a chance to participate in the decision-making process,
– they will be much more committed to the decision that is made and more likely to support it during implementation.
– the project manager is much better off using this approach than a directive approach.
Project Management Recruitment
Decision Making
Consultative:
This middle-ground approach combines the best of the other two approaches.
The person in authority makes the final decision, but this decision is made only after consulting with all members to get their input and ideas.
This approach is participative at the input stage but directive at the point of decision making. In some cases, when expediency is required, this approach is a good one to take.
Rather than having to involve the entire team, the project manager can decide whose input should be sought and then make the decision based on that input.
This is a very good strategy, and it can have positive effects on those whose input was sought.
Project Management Recruitment
Selecting a model to use in a specific situation is generally a function of the gravity and time sensitivity of the pending decision.
Some organisations have constructed categories of decisions, with each category defined by some financial parameters, such as the value of the decision, or by some scope parameters, such as the number of business units or clients affected by the decision.
The person responsible for making the decision is defined for each decision category—the more serious the category, the higher the organizational level of the decision maker.
Some decisions might be made by an individual team member, some by a task manager, some by the project manager, some by the client, and some by senior management.
Yet others might require a group decision, using either a participative or a consultative approach.
Project Management Recruitment
Decision Making
Conflict Resolution
The next area for which operating rules are needed deals with how the team resolves conflicts.
Conflicts arise when two or more team members have a difference of opinion, when the client takes issue with an action to be taken by the project team, or in a variety of other situations involving two parties with different points of view.
In all of these examples, the difference must be resolved.
Clearly, conflict resolution is a much more sensitive situation than the decision-making rule because it is confrontational and situational, whereas the decision-making rule is procedural and structured.
Depending on the particular conflict situation, the team might adopt one of the following three conflict resolution styles:
Some people will do anything to avoid a direct confrontation.
Some agree even though they are opposed to the outcome.
This style cannot be tolerated on the project team.
Each person’s input and opinion must be sought.
It is the responsibility of the project manager to ensure that this happens.
A simple device is to ask all of the team members in turn what they think about the situation and what they suggest should be done about it.
Summary:
Avoidant Approach
Often this approach will defuse any direct confrontation between two individuals on the team.
Some people avoid confrontation at all costs; others seem to seek it out.
Some team members play devil’s advocate at the least provocation.
At times this is advantageous — testing the team’s thinking before making the decision.
At other times it tends to raise the level of stress and tension, when many team members will see it as a waste of time and not productive.
The project manager must be able to identify these combative team members and act to mitigate the chances of these combative situations arising.
Summary:
Combative Approach
https://
www.youtube.com/watch?v=rBSCvPYGnTc
What is a PROJECT? (Recap)
Project Management
https://
www.youtube.com/watch?v=9LSnINglkQA
Overview of Project Management
Reflect on your group presentations and start to think about
a PROJECT you would work on towards the INDIVIDUAL
ASSIGNMENT
Project Management
powerpoint/MAN7084 Wk_Session 8 Monitoring and Controlling Projects.pptx
MAN7084 Project Management
Week 8: Monitoring and Controlling Projects
Teaching Team:
Project Management
Suhil Khan: Suhel.Khan@bcu.ac.uk
Kulbir Bains: kulbir.bains@bcu.ac.uk
Project Management
Brief recap of last week
Project Management Monitoring
Controlling Projects
Recap of Assignment
Project Management Recruitment -Recap
Normally, contract team members are available to work on the project for only short periods of time.
A contract team member may possess a skill that is needed for just a brief time, and he or she is assigned to the project for that time only.
As soon as the assigned task is completed, he or she leaves the project. (See Chapter 3 for additional discussion of Procurement Management).
Implications of Adding Contract Team Members
Contract team members present the project manager with a number of challenges.
In most systems development efforts, it is unlikely that professionals would be assigned full-time to the project team.
Rather, people will join the project team only for the period of time during which their particular expertise is needed.
The project manager must be aware of the implications to the project when contract professionals are used, which may include the following:
There may be little or no variance in the time contracted team members are available, so the tasks on which they work must remain on schedule.
They must be briefed on their role in the project and how their task relates to other tasks in the project.
Commitment of contract members is typically a problem because their priorities probably lie elsewhere.
Quality of work may be an issue because of poor levels of commitment. They just want to get the job done and get on with their next assignment
Contract team members will often require more supervision than core team members.
Implications of Adding Contract Team Members Continue…
Project Management Recruitment -Recap
Selection Criteria
Project Management Recruitment -Recap
If as a project manager, you’ve made the decision to buy rather than build a project team, you must determine who will get your business.
Contract team members are usually employed or represented by agencies that cater to technical professionals who prefer freelancing to full-time employment.
These professionals are available for short-term assignments in their area of specialisation.
To employ these professionals, you must make the following decisions: what process you’re going to follow, who should be invited to submit information, and how you’re going to evaluate the information received.
The evaluation often takes the form of a score sheet
The score sheet contains questions grouped by major features and functions, with weights attached to each answer.
A single numeric score is then calculated to rank vendor responses.
Non-quantitative data such as client relations and client services are also collected from reference accounts provided by the vendor.
Here are the steps you might take as a project manager to engage the services
of a contract team member:
Identify the types of skills and the number of personnel needed, and the time frame within which they will be required.
Identify a list of companies that will be invited to submit a proposal.
Write the Request for Proposal (RFP).
Establish the criteria for evaluating responses and selecting the vendor(s).
Distribute the RFP.
Evaluate the responses.
Reduce the list of vendors to a few who will be invited onsite to make a formal presentation.
Conduct the onsite presentations.
Choose the final vendor(s), and write and sign the contract
Project Management Recruitment -Recap
Developing a Team Development Plan
After you’ve assembled your team and assessed each member’s characteristics, you may discover several areas in which the team is noticeably weak.
Although your job as project manager is to manage the work of the project not to be a career or professional development manager
– you still have to get the project done, and any imbalance on the team can be a barrier to your success.
As project manager, identify the high-risk areas that are not covered by at least one team member who can deal with those types of risks.
As part of your risk management plan, put a development plan in place for selected members of the team.
What form might that development plan take; = here are two possibilities:
Project Management Recruitment -Recap
You might want to use a conflict-resolution management behaviour called masked behaviour.
Briefly, it means that you find the person on your team whose normal behaviour is as close as possible to the missing behaviour.
Project Management Recruitment -Recap
That person then role-plays as though his or her normal behaviour were the missing behaviour.
You might consider sensitivity training for all or some of the team.
That training involves creating an awareness of the behaviour that is lacking and practicing it under supervision.
(Example, technology professionals are generally not very good people persons).
Sensitivity training for these team members might include listening skills, learning how to be a team player, acceptance of change, diversity training, and other related interpersonal skills training.
Project Management Recruitment -Recap
Decision Making
Team members make decisions continuously as they engage in the work of the project.
Some of those decisions are obvious and straightforward and may not require the involvement of other team members
other decisions are more complex and may require the involvement and active participation of the team,
the client, and even people outside of the project.
The three major types of decision-making models are as follows:
Directive — In this model, the person with the authority (the project manager for the project and the task manager for the task) makes the decision for all team members.
Although this approach is certainly useful, it has obvious drawbacks.
The only information available is the information that the decision maker possesses, which may or may not be correct or complete.
An added danger is that those who disagree or were left out of the decision may be resistant or unwilling to carry it out.
A directive approach is often used when time is of the essence and a decision is needed immediately.
It makes no sense to hold a committee meeting to get everyone’s input before proceeding
Project Management Recruitment -Recap
Decision Making
Participative — In this model, everyone on the team contributes to the decision-making process.
An interaction is created as the best decision is sought.
Because everyone has an opportunity to participate, commitment will be much stronger than in the directive approach.
Obviously, there is an additional benefit to team building—empowerment of the team.
Using this participative approach whenever possible is highly recommended
Because the team members have a chance to participate in the decision-making process, they will be much more committed to the decision that is made and more likely to support it during implementation.
From a political perspective, the project manager is much better off using this approach than a directive approach.
Project Management Recruitment -Recap
Decision Making
Consultative —This middle-ground approach combines the best of the other two approaches.
The person in authority makes the final decision, but this decision is made only after consulting with all members to get their input and ideas.
This approach is participative at the input stage but directive at the point of decision making.
In some cases, when expediency is required, this approach is a good one to take.
Rather than having to involve the entire team, the project manager can decide whose input should be sought and then make the decision based on that input.
This is a very good strategy, and it can have positive effects on those whose input was sought.
Project Management Recruitment -Recap
Selecting a model to use in a specific situation is generally a function of the seriousness and time sensitivity of the pending decision.
Some organisations have constructed categories of decisions, with each category defined by some financial parameters:
such as the value of the decision, or by some scope parameters, such as the number of business units or clients affected by the decision.
The person responsible for making the decision is defined for each decision category—the more serious the category, the higher the organizational level of the decision maker.
Some decisions might be made by an individual team member, some by a task manager, some by the project manager, some by the client, and some by senior management.
Yet others might require a group decision, using either a participative or a consultative approach.
Project Management Recruitment -Recap
Conflict Resolution
The next area for which operating rules are needed deals with how the team resolves conflicts.
Conflicts arise when two or more team members have a difference of opinion
When the client takes issue with an action to be taken by the project team, or in a variety of other situations involving two parties with different points of view.
In all of these examples, the difference must be resolved.
Clearly, conflict resolution is a much more sensitive situation than the decision-making rule because it is confrontational and situational, whereas the decision-making rule is procedural and structured.
Depending on the particular conflict situation, the team might adopt one of the following two conflict resolution styles:
Project Management Recruitment -Recap
Avoidant:
Some people will do anything to avoid a direct confrontation, they agree even though they are
opposed to the outcome.
This style cannot be tolerated on the project team (each person’s input and opinion must be sought)
It is the responsibility of the project manager to ensure that this happens (everyone have a say)
A simple device is to ask all of the team members in turn what they think about the situation and what they suggest should be done about it – often this approach will defuse any direct confrontation between two individuals on the team.
2. Combative
Some people avoid confrontation at all costs; others seem to seek it out.
Some team members play devil’s advocate at the least provocation.
At times this is advantageous—testing the team’s thinking before making the decision.
At other times it tends to raise the level of stress and tension, when many team members will see it as a waste of time and not productive.
The project manager must be able to identify these combative team members and act to mitigate the chances of these combative situations arising.
Project Management Control
The project plan is a system as defined by the scope triangle.
As such, it can get out of balance, and a get-well plan must be put in place to restore balance to the system.
The longer the project manager waits to put the fix in place, the longer it will take to restore balance.
The controls you will learn are designed to discover out-of-balance situations early and put get-well plans in place quickly.
You can use a variety of reports as control tools, most can be used in numeric and tabular form, but I suggest using graphics wherever possible.
A well-done graphic is essential.
It does not require a lengthy explanation and certainly doesn’t require a lot of reading.
Be aware of the fact that senior managers don’t have a lot of time to dwell on your report.
Give them what they need as briefly as possible.
Graphics are particularly effective in that regard.
Senior managers generally aren’t interested in reading long reports only to find out that everything is on schedule.
Project Management Control
Although they will be pleased that your project is on track, their time could have been spent on other pursuits that require their attention.
When projects are not on schedule, they want to know this as soon as possible and see what corrective action you plan to take or how they can help.
Project Management Control
Templates
Here are some of the reporting tools:
Current period reports
Cumulative reports
Exception reports
Stoplight reports
Variance reports
Gantt charts
Burn charts
Milestone trend charts
Earned value analysis (EVA)
Integrated milestone trend charts and EVA
Project status meetings
Problem escalation strategies
Which do you feel are most useful and why?
Review in small groups for 5 minutes
Project Management Control
Progress Reporting
After project work is under way, you want to make sure that it proceeds according to plan.
To do this, you need to establish a reporting system that keeps you informed of the many variables that describe how the project is proceeding as compared to the plan.
A reporting system has the following characteristics:
Provides timely, complete, and accurate status information
Doesn’t add so much overhead time as to be counterproductive
Is readily acceptable to the project team and senior management
Has an early warning system of pending problems
Is easily understood by those who have a need to know
To establish this reporting system, you can choose from among the hundreds of reports that are standard fare in project management software packages.
Once you decide what you want to track, these software tools offer several suggestions and standard reports to meet your needs.
Most project management software tools enable you to customize their standard reports to meet even the most specific needs.
Project Management Control
Progress Reporting
Types of Project Status Reports
There are five types of project status reports: current period, cumulative, exception, stoplight, and variance.
Each of these report types is described here.
Current Period Reports
These reports cover only the most recently completed period.
They report progress on activities that were open or scheduled for work during the period.
Reports might highlight activities completed, as well as the variance between scheduled and actual completion dates.
If any activities did not progress according to plan, the report should include the reasons for the variance and the appropriate corrective measures that will be implemented to fix the schedule slippage
Project Management Control
Cumulative Reports
These reports contain the history of the project from the beginning to the end of the current report period.
They are more informative than the current period reports because they show trends in project progress.
For example, a schedule variance might be tracked over several successive periods to show improvement.
Reports can be at the activity or project level.
Progress Reporting
Exception Reports
Exception reports indicate variances from the plan.
These reports are typically designed for senior management to read and interpret quickly.
Reports that are produced for senior management merit special consideration.
Senior managers do not have a lot of time to read reports that tell them everything is on schedule and there are no problems serious enough to warrant their attention.
Project Management Control
In such cases, a one-page, high-level summary report that says everything is okay is usually sufficient.
It might also be appropriate to include a more detailed report as an attachment for those who might want more information.
The same might be true of exception reports.
That is, the one-page exception report tells senior managers about variances from the plan that will be of interest to them, and an attachment provides more details for the interested reader
Stoplight Reports
Stoplight reports are a variation that can be used on any of the previous report types.
Here is a technique you might want to try: When the project is on schedule and everything seems to be proceeding as planned, put a green sticker on the top-right corner of the first page of the project status report.
This sticker will signal to senior managers that everything is progressing according to plan, and they need not even read the attached report
Project Management Control
Progress Reporting
Variance Reports
Variance reports do exactly what their name suggests — they report differences between what was planned and what actually happened.
The tabular version of the report has the following three columns:
The planned number
The actual number
The difference, or variance, between the two
A variance report can be in one of the following two formats:
The first is a numeric format containing rows that show the actual, planned, and variance values for those variables requiring such calculations.
Typical variables that are tracked in a variance report are schedule and cost.
Example, the rows might correspond to the activities open for work during the report period, and the columns might be the planned cost to date, the actual cost to date, and the difference between the two.
The impact of departures from the plan is signified by larger values of this difference (the variance).
Project Management Control
Progress Reporting
The second format is a graphical representation of the numeric data.
It might be formatted so that plan data is shown for each report period of the project,
denoted with a curve of one colour, and the actual data is shown for each report
period of the project, denoted by a curve of a different colour.
The variance need not be graphed at all because it is merely the difference
between the two curves at some point in time.
One advantage of the graphical version of the variance report is that it shows
any variance trend over the report periods of the project,
whereas the numeric report generally shows data only for the current
report period.
Project Management Control
Progress Reporting
Typical variance reports are snapshots in time (the current period) of the status of an entity being tracked.
Most variance reports do not include data points that report how the project reached that status.
Those that show trends are primitive earned value reports.
These are discussed later in this chapter.
Project variance reports can be used to report project as well as activity variances.
For the sake of the managers who will have to read these reports, It is recommend that, one report format be used regardless
of the variable being tracked.
Your upper management will quickly become comfortable with a reporting format that is consistent across all projects or activities within a project.
It will make life a bit easier for you, as the project manager, too.
Here are five reasons why you should measure duration and cost variances:
Project Management Control
Catch deviations from the curve early —The cumulative actual cost or actual duration can be plotted
against the planned cumulative cost or cumulative duration.
As these two curves begin to display a variance from one another, the project manager should put corrective measures in place to bring the two curves together.
This re-establishes the agreement between planned and actual performance, as described in detail in the “Earned Value Analysis” section later in this chapter.
Dampen oscillation—Planned versus actual performance should display a similar pattern over time.
Wild fluctuations between the two are symptomatic of a project that is not under control.
Such a project will get behind schedule or overspend in one report period, be corrected in the next period, and go out of control in the next period.
Variance reports can provide an early warning that such conditions are likely, giving the project manager an opportunity to correct the anomaly before it gets serious.
Smaller oscillations are easier to correct than larger oscillation (repetitive variation).
Project Management Control
3. Allow early corrective action — As just suggested, the project manager would prefer to be alerted to a schedule or cost problem early in the development of the problem, rather than later.
Early problem detection may offer more opportunities for corrective action than later detection.
4.Determine weekly schedule variance — I have found that progress on activities open for work should be reported on a weekly basis.
This is a good compromise on report frequency and gives the project manager the best opportunity for corrective action plans before a situation escalates to a point where it will be difficult to recover any schedule slippages.
Progress Reporting
5. Determine weekly effort (person hours/day) variance —The difference between the planned effort and actual effort has a direct impact on both planned cumulative cost and the schedule.
If the effort is less than planned, it may suggest potential schedule slippage if the person is not able to increase his or her effort on the activity in the following week.
Alternatively, if the weekly effort exceeded the plan and the progress was not proportionately the same, a cost overrun situation may be developing.
Project Management Control
Progress Reporting
Early detection of out-of-control situations is important. The longer you wait to discover a problem, the longer it will take for your solution to bring the project back to a stable condition.
How and What Information to Update
As input to each of these report types, activity managers and the project man-ager must report the progress made on all activities that were open for work (in other words, those that were to have work completed on them during the report period) during the period of time covered by the status report. Recall that your planning estimates of activity duration and cost were based on little or no information. Now that you have completed some work on the activity, you should be able to provide a better estimate of duration and cost. This is reflected in a re-estimate of the work remaining to complete the activity. That update information should also be provided.
Project Management Control
Determine a set period of time and day of week—The project team will have agreed on the day of the week and time of day by which all updated information is to be submitted.
A project administrator or another team member is responsible for ensuring that all update information is on file by the report deadline.
Report actual work accomplished during this period — What was planned to be accomplished and what was actually accomplished are often two different things.
How and What Information to Update
Rather than disappoint the project manager, activity managers are likely to report that the planned work was actually accomplished.
Their hope is to catch up by the next report period.
Project managers need to verify the accuracy of the reported data, rather than simply accept it as accurate.
Spot-checking on a random basis should be sufficient.
Record historical data and re-estimate remaining work (in-progress work only) —The following two kinds of information are reported:
Project Management Control
All work completed prior to the report deadline is historical information.
It enables variance reports and other tracking data to be presented and analysed.
The other kind of information is future-oriented.
For the most part, this information consists of re-estimates of duration and cost and estimates to completion (both cost and duration) of the activities still open for work.
Report start and finish dates—These are the actual start and end dates of activities started or completed during the report period.
Record days of duration accomplished and remaining—First reported is how many days have been spent so far working on this activity.
The second number is based on the re-estimated duration as reflected in the time-to-completion number.
Project Management Control
How and What Information to Update
Report resource effort (hours/day) spent and remaining (in-progress work only)
Whereas the preceding numbers report calendar time, these two numbers report labour time over the duration of the activity. One reports labour completed over the duration already accomplished.
The other reports labour to be spent over the remaining duration.
Report percent complete
Percent complete is the most common method used to record progress
It is the way people tend to think about what has been done in reference to the total job to be completed.
Percent complete isn’t the best method to report progress, however, because it is a subjective evaluation.
What goes through a person’s mind when you ask him or her, “What percent complete are you on this activity?”
The first thing is most likely, “What percent should I be?” This is followed closely by, “What’s a number that we can all be happy with?”
Project Management Control
To calculate the percent complete for an activity:
You need something countable.
Different approaches have been used to calculate percent complete, including the following:
Duration
Resource work
Cost
Project Management Control
Frequency of Gathering and Reporting Project Progress
A logical frequency for reporting project progress is once a week, usually on Friday afternoon.
For some projects, such as refurbishing a large jet airliner, progress is recorded after each shift, three times a day.
I’ve seen others that were of such a low priority or long duration that they were updated once a month.
For most projects, start gathering the information around noon on Friday.
Let people extrapolate to the end of the workday.
Variances
Variances are deviations from plan.
Think of a variance as the difference between what was planned and what actually occurred.
There are two types of variances: positive variances and negative variances.
Project Management Control
Positive Variances
Positive variances are deviations from the plan – indicating that an ahead-of-schedule situation has occurred or that an actual cost was less than a planned cost.
This type of variance is good news to the project manager, who would rather hear that the project is ahead of schedule or under budget.
Positive variances bring their own set of problems, however, which can be as serious as negative variances.
Positive variances can result in rescheduling to bring the project to completion early, under budget, or both.
Resources can be reallocated from a head-of-schedule projects to behind-schedule projects.
Positive variances also can result from schedule slippage! Consider budget.
Being under budget means that not all dollars were expended, which may be the direct result of not having completed work that was scheduled for completion during the report period.
Project Management Control
Negative Variances
Negative variances are deviations from the plan indicating that a behind-schedule situation has occurred or that an actual cost was greater than a planned cost.
Being behind schedule or over budget is not what the project manager or reporting manager wants to hear.
Negative variances are not necessarily bad news, however. For example, you might have overspent because you accomplished more work during the report period than was planned.
In overspending during this period, you could have accomplished the work at less cost than was originally planned.
You can’t tell by looking at the variance report.
You will need the details available in the EVA reports
Project Management Control
Gantt Charts
Graphical Charts
A Gantt chart is one of the most convenient, most frequently used, and easiest-to-grasp representations of project activities that I have encountered.
The chart is formatted as a two-dimensional representation of the project schedule, with activities shown in the rows and time shown across the horizontal axis.
It can be used during planning, for resource scheduling, and for status reporting.
The only downside to using a Gantt chart is that it does not contain dependency relationships between tasks or activities.
Some project management software tools provide an option to display these dependencies, but the result is a graphical report that is so cluttered with lines representing the dependencies that the report is next to useless.
In some cases, dependencies can be guessed at from the Gantt chart, but in most cases, they are lost.
Project Management Control
Graphical Charts (Gantt Charts)
Stoplight Reports
As mentioned earlier in the chapter, stoplight reports are a very effective way to communicate status instinctively without burdening senior managers with the need to read anything.
The explanation will, of course, be in the attached report if the managers are interested in reading the details.
Project Management Control
Graphical Charts
Gantt Charts
Graphical Charts
Burn Charts
Burn charts are another instinctive tool that displays the cumulative consumption of any
resource over time, expressed either as a percentage of the resource allocated to the
project or the quantity of the resource.
If you are displaying the quantity, there should be a horizontal
line showing the maximum quantity of the resource available.
.
Burn charts are very simple, but their management value can be increased by showing the planned resource consumption along with the actual resource consumption (as shown here).
For a more sophisticated display of resource use against the
plan, earned value analysis (EVA) would be used
Project Management Control
Project Management Control
Graphical Charts
Milestone Trend Charts
Milestones are significant events that you want to track in the life of the project.
These significant events are zero-duration activities and merely indicate that a certain condition exists in the project.
For example, a milestone event might be the approval of several different component designs.
This event consumes no time in the project schedule.
It simply reflects the fact that those approvals have all been granted.
The completion of this milestone event may be the predecessor of several build-type activities in the project plan.
Milestone events are planned into the project in the same way that activities are planned into the project.
They typically have finish-to-start (FS) relationships with the activities that are their predecessors and their successors.
Project Management Control
Managing Project Status Meetings
To keep close track of progress on the project, the project manager needs information from his or her team on a timely basis.
This information will be provided during a project status meeting.
At a minimum, you need to have a status meeting at least once a week.
On some of my major projects, daily status meetings were the norm for the first few weeks, and when the need for daily information wasn’t as critical, I switched to twice a week and finally to weekly status meetings.
Who Should Attend Status Meetings?
To use the status meetings correctly and efficiently, it’s important to figure out who should be in attendance.
This information should be a part of your communication plan.
Project Management Control
At first your status team may include only those team members who are needed in the Planning Phase.
If the other team members don’t need to know the information, don’t make them come to a meeting and sit there
without a good reason.
You are going to distribute meeting minutes any-way, so the team members who aren’t needed at the actual meeting will be informed about what transpired.
When choosing who should attend, keep the following points in mind:
Project Management Control
Find a project and review how it was monitored and controlled
Case Study Review of 1) Arts and Culture Festival or 2) a self-determined project of your choice from within the Creative Industries Sector Event.
Identify a project in a sector of interest.
Estimate where information is not available, how the project was probably monitored and controlled for issues such as scope creep and variance.
Feedback your findings next week–10 minutes per group –Formative Assessment
Project Management Control
Managing Project Status Meetings
There will be times in a status meeting when two team members get into a discussion and the other people in the meeting aren’t needed.
If this happens, ask them to conduct a sidebar meeting so that your own status meeting can continue.
A sidebar meeting is one in which a limited number of people need to participate, and problems can resolved more effectively away from your status meeting.
Having everyone in the room listen to these sidebar topics isn’t useful.
When Are Status Meetings Held?
Usually, status meetings are held toward the end of the week.
Just make sure it’s the same day each week.
People get used to preparing information for a status meeting if they know exactly when the meeting will occur
Project Management Control
Managing Project Status Meetings
What Is the Purpose of a Status Meeting?
You hold a status meeting to get information to the whole team.
On large projects, the participants in the status meeting may be representatives of their department.
You can’t have all the people on a 250-person project team come into a meeting once a week, so make sure that someone is there to represent the rest of the people in their section.
The purpose of the meeting is to encourage the free flow of information, and that means ensuring that the people who need to have information to do their jobs get the information at the status meeting.
Remember once again that you are going to distribute minutes of the meeting later, so that will take care of the people who aren’t in attendance.
End of Session Activity
Find a project and review how it was monitored and controlled
Case Study Review of 1) Arts and Culture Festival or 2) a self-determined project of your choice from within the Creative Industries Sector Event.
Identify a project in a sector of interest.
Estimate where information is not available, how the project was probably monitored and controlled for issues such as scope creep and variance.
Feedback your findings next week–10 minutes per group –Formative Assessment
powerpoint/MAN7084 Wk_Session 9 Closing Projects Traditional Project Mgt.pptx
MAN7084 Project Management
Week 9:
Closing Project (Traditional Projects Management)
Suhil Khan: Suhel.Khan@bcu.ac.uk
Kulbir Bains: kulbir.bains@bcu.ac.uk
Teaching Team:
Last Session Recap
Project Management Closing Projects
Controlling Projects…
Q & A
Project Management
Session Objectives
Find a project and review how it was monitored and controlled
Case Study Review of 1) Arts and Culture Festival or 2) a self-determined project of your choice from within the Creative Industries Sector Event.
Identify a project in a sector of interest.
Estimate where information is not available, how the project was probably monitored and controlled for issues such as scope creep and variance.
Feedback your findings next week– 10 minutes per group – Formative Assessment
Last Week’s End of Session Activity
Project Management Control – Recap
Frequency of Gathering and Reporting Project Progress
Negative Variances
Negative variances are deviations from the plan indicating that a behind-schedule situation has occurred or that an actual cost was greater than a planned cost.
Being behind schedule or over budget is not what the project manager or reporting manager wants to hear.
Negative variances are not necessarily bad news, however, for example, you might have overspent because you accomplished more work during the report period than was planned.
In overspending during this period, you could have accomplished the work at less cost than was originally planned.
You can’t tell by looking at the variance report.
You will need the details available in the EVA reports
Project Management Control
Gantt Charts
Graphical Charts
A Gantt chart is one of the most convenient, most frequently used, and easiest-to-grasp representations of project activities that I have encountered.
The chart is formatted as a two-dimensional representation of the project schedule, with activities shown in the rows and time shown across the horizontal axis.
It can be used during planning, for resource scheduling, and for status reporting.
The only downside to using a Gantt chart is that it does not contain dependency relationships between tasks or activities.
Some project management software tools provide an option to display these dependencies, but the result is a graphical report that is so cluttered with lines representing the dependencies that the report is next to useless.
In some cases, dependencies can be guessed at from the Gantt chart, but in most cases, they are lost.
Stoplight Reports
As mentioned earlier in the chapter, stoplight reports are a very effective way to communicate status instinctively without burdening senior managers with the need to read anything.
The explanation will, of course, be in the attached report if the managers are interested in reading the details.
Project Management Control
Graphical Charts
Gantt Charts
Graphical Charts
Burn Charts
Burn charts are another instinctive tool that displays the cumulative consumption of any
resource over time, expressed either as a percentage of the resource allocated to the
project or the quantity of the resource.
If you are displaying the quantity, there should be a horizontal
line showing the maximum quantity of the resource available.
Burn charts are very simple, but their management value can be
increased by showing the planned resource consumption along with
the actual resource consumption (as shown here).
For a more sophisticated display of resource use against the
plan, earned value analysis (EVA) would be used
Project Management Control Recap
Project Management Control
Graphical Charts
Milestone Trend Charts
Milestones are significant events that you want to track in the life of the project.
These significant events are zero-duration activities and merely indicate that a certain condition exists in the project.
For example, a milestone event might be the approval of several different component designs.
This event consumes no time in the project schedule.
It simply reflects the fact that those approvals have all been granted.
The completion of this milestone event may be the predecessor of several build-type activities in the project plan.
Milestone events are planned into the project in the same way that activities are planned into the project.
They typically have finish-to-start (FS) relationships with the activities that are their predecessors and their successors.
Project Management Control
Managing Project Status Meetings
To keep close track of progress on the project, the project manager needs information from his or her team on a timely basis.
This information will be provided during a project status meeting.
At a minimum, you need to have a status meeting at least once a week.
On some of my major projects, daily status meetings were the norm for the first few weeks, and when the need for daily information wasn’t as critical, I switched to twice a week and finally to weekly status meetings.
Who Should Attend Status Meetings?
To use the status meetings correctly and efficiently, it’s important to figure out who should be in attendance.
This information should be a part of your communication plan.
Project Management Control-Recap
Managing Project Status Meetings
There will be times in a status meeting when two team members get into a discussion and the other people in the meeting aren’t needed.
If this happens, ask them to conduct a sidebar meeting so that your own status meeting can continue.
A sidebar meeting is one in which a limited number of people need to participate, and problems can resolved more effectively away from your status meeting.
Having everyone in the room listen to these sidebar topics isn’t useful.
When Are Status Meetings Held?
Usually, status meetings are held toward the end of the week.
Just make sure it’s the same day each week.
People get used to preparing information for a status meeting if they know exactly when the meeting will occur
Project Management Control-Recap
Managing Project Status Meetings
What is the Purpose of a status Meetings
You hold a status meeting to get information to the whole team.
On large projects, the participants in the status meeting may be representatives of their department.
You can’t have all the people on a 250-person project team come into a meeting once a week, so make sure that someone is there to represent the rest of the people in their section.
The purpose of the meeting is to encourage the free flow of information, and that means ensuring that
the people who need to have information to do their jobs get the information at the status meeting.
Remember once again that you are going to distribute minutes of the meeting later, so that will take care of the people who aren’t in attendance.
Project Management Closure
The client decides when the project can move to the Closing Phase.
This is not an arbitrary decision, but one based on the acceptance criteria initiated during project planning and maintained throughout the project.
Whenever a scope change request has been approved, the acceptance criteria are updated to reflect that.
In most cases, the acceptance criteria are nothing more than a checklist that reflects the client requirements.
After all of the items have been checked as satisfactorily completed, the project is ready to move to the closing activities.
Gaining Approval to Close the Project
Project Management Closure
Closing a project is all too often a sigh of relief on the part of the development team and the client team.
The punishment has finally ended, and everyone can return to their normal jobs.
There are probably project responsibilities that are behind schedule and waiting for you to get started on them.
Is that how you remember project closings? Or do you remember them as celebrations of success?
How to close a project
Using Tools, Templates, and Processes to Close a Project
By using the following tools, templates, and processes you can turn a project closing into an ordered and defined process:
Acceptance test procedures (ATP)
Implementation strategies
Project documentation
Post-implementation audit
Final project report
Project Management Closure
Writing and Maintaining Client Acceptance Procedures
The worst time to negotiate the completion of a project is at its eleventh hour.
If you wait until then, you are at the mercy of the client.
A company that I worked for developed Internet and intranet solutions for their clients using fixed bid contracts.
The company was very sloppy about scope change control and did not formally establish project completion criteria.
As a result, the company was always facing last-minute changes from the client.
Profit margins were seriously eroded as a result.
In fact, they had trapped themselves on more than one occasion and ended up spending more to complete projects than they received from their clients; the message is clear.
The process of writing and maintaining client acceptance test procedures begins during requirements gathering, is documented during project planning, is maintained during project execution, and is applied as the only criteria for moving to the project Closing Phase
Project Management Closure
Closing the project is routine once you have the client’s approval of the deliverables.
It involves the following six steps:
Getting client acceptance of deliverables
Ensuring that all deliverables are installed
Ensuring that the documentation is in place
Getting client sign-off on the final report
Conducting the post-implementation audit
Celebrating the success
This chapter describes each of these steps in more detail.
Closing a Project
Project Management Closure
1. Getting client acceptance of deliverables
The client decides when the project is done.
It is your job as the project manager to demonstrate that the deliverables (whether products or services) meet client specifications.
For small projects, this acceptance can be very informal and ceremonial, or it can be very formal, involving extensive acceptance testing against the client’s performance specifications.
Ceremonial Acceptance
Ceremonial acceptance is an informal acceptance by the client.
It does not have an accompanying sign-off of completion or acceptance.
It simply happens.
The following two situations fall under the heading of ceremonial acceptance:
Project Management Closure
The first involves deadline dates at which the client must accept the project as complete, whether or not it meets the specifications.
For example, if the project is to plan and conduct a conference, the conference will happen whether or not the project work has been satisfactorily completed.
1. Getting client acceptance of deliverables
The second involves a project deliverable requiring little or no checking to determine whether specifications have been met—for example, planning and taking a vacation.
A colleague of mine shared the following example with me.
The project involved recommending or not recommending the renewal of a hosted IT service.
There really was no client to satisfy—just a decision to be made.
The project ended on a ceremonial note following the filing of the recommendation.
Project Management Closure
Getting client acceptance of deliverables Formal
Acceptance
Formal acceptance occurs in projects for which you and the client have written an acceptance test procedure (ATP).
In many cases, especially for projects that involve computer applications development, writing an ATP may be a joint effort of the client and appropriate members of the project team.
It typically is done very early in the life of the project.
This ATP requires that the project team demonstrate compliance with every feature in the client’s performance specification.
A checklist is used and requires a feature-by-feature sign-off based on performance tests.
These tests are conducted jointly and administered by the client and appropriate members of the project team
Project Management Closure
The second step of closing a project is to go live with the deliverables.
This commonly occurs in computer systems work.
The installation can involve phases, cutovers, or some other rollout strategy.
In other cases, it involves nothing more than flipping a switch.
Either way, some event or activity turns things over to the client.
This installation triggers the beginning of a number of close-out activities that mostly relate to documentation and report preparation.
After installation is complete, the deliverables move to support and maintenance, and the project is officially closed.
There are four popular methods to install deliverables, and the subsections that follow discuss them.
Installing Project Deliverables
Project Management Closure
2. Installing Project Deliverables
Phased Approach
The phased approach decomposes the deliverable into meaningful chunks and implements the chunks in the appropriate sequence.
This approach would be appropriate in cases where resource limitations prevent any other approach from being used.
Cut-Over Approach
The cut-over approach replaces the old deliverable with the new deliverable in one action.
To use this approach, the testing of the new system must have been successfully completed in a test environment that is exactly the same as the production environment.
Parallel Approach
In the parallel approach, the new deliverables are installed while the old deliverables are still operational.
Both the old and the new deliverables are simultaneously in production mode.
In cases where the new system might not have been completely tested in an environment exactly like the production environment, this approach will make sense.
It allows the new system to be compared with the old system on real live data.
Project Management Closure
By-Business-Unit Approach
In the by-business-unit approach, the new deliverables are installed in one business unit at a time,
usually in the chronological order that the system is used.
Like the phased approach, this approach is appropriate when resource constraints prohibit a full implementation at one time.
Similar to the by-business-unit approach would be a geographic approach where the system is installed at one geographical location at a time.
This facilitates geographic differences, too.
Installing Project Deliverables
3. Documenting the Project
Documentation always seems to be the most difficult part of the project to complete.
There is little glamour in writing documentation.
That does not diminish its importance, however, there are at least five reasons why you need to write documentation.
Those five reasons are described here
Project Management Closure
3. Documenting the Project
Reference for Future Changes in Deliverables
Even though the project work is complete, there will most likely be further changes that warrant follow-up projects.
By using the deliverables, the client will identify improvement opportunities, features to be added, and functions to be modified.
The documentation of the project just completed is the foundation for the follow-up projects.
Historical Record for Estimating Duration and Cost on Future Projects, Activities, and Tasks
Completed projects are a terrific source of information for future projects, but only if the data and other documentation from them is archived so that it can be retrieved and used.
Estimated and actual durations and costs for each activity on completed projects are particularly valuable for estimating these variables on future projects.
Project Management Closure
3. Documenting the Project
Training Resource for New Project Managers
History is a great teacher, and nowhere is that more significant than on completed projects.
Such items as how the Work Breakdown Structure (WBS) was determined; how change requests were analysed and decisions reached; problem identification, analysis, and resolution situations; and a variety of other experiences are invaluable lessons for the newly appointed project manager.
Input for Further Training and Development of the Project Team
As a reference, project documentation can help the project team deal with situations that arise in the current project.
How a similar problem or change request was handled in the past is an excellent example, especially if the causes of the problem or change are included.
Project Management Closure
4. Getting client sign-off on the final report
Project Overview Statement (POS)
Project proposal and backup data
Original and revised project schedules
Minutes of all project team meetings
Copies of all status reports
Design documents
Copies of all change notices
Copies of all written communications
Outstanding issues reports
Final report
Sample deliverables (if appropriate)
Client acceptance documents
Post-implementation audit report
In many organisations, project documentation can be used as input to the performance evaluations of the project manager and team members.
Given all that documentation can do for you, to be most effective and useful, the documentation for a given project should include but not be limited to the following parts:
Project Management Closure
4. Getting client sign-off on the final report
For a given project, the project manager has to determine what documentation is appropriate.
Always refer back to value-added considerations.
If the project has potential value for future projects, as many projects do, then include it in the documentation.
Note also that the preceding list contains very little that does not arise naturally in the execution of the project.
All that is added is the appointment of someone to maintain the project notebook.
This job involves collecting the documents at the time of their creation and ensuring that they are in an easily retrievable form (electronic is a must).
Project Management Closure
5. Conducting the post-implementation audit
The post-implementation audit is an evaluation of the project’s goals and activity achievement as measured against the project plan, budget, time deadlines, quality of deliverables, specifications, and client satisfaction.
The log of the project activities serves as baseline data for this audit.
The following six important questions should be answered:
Was the project goal achieved?
Does it do what the project team said it would do?
Does it do what the client said it would do?
The project was justified based on a goal to be achieved.
That goal either was or wasn’t achieved, and the reasons for this must be provided in the audit.
This can be addressed from two different perspectives.
The provider may have suggested a solution for which certain results were promised.
Did that happen? Conversely, the requestor may have promised that if the provider would only provide, say, a new or improved system, then certain results would occur.
Did that happen?
Project Management Closure
5. Conducting the post-implementation audit
2. Was the project work done on time, within budget, and according to specification?
Recall from the scope triangle discussed in Chapter 1 that the constraints on a project are time, cost, and the client’s specification, as well as resource availability and quality.
Here you are concerned with whether the specification was met within the budgeted time and cost constraints.
3. Was the client satisfied with the project results?
It is possible that the answers to the first two questions are yes, but the answer to this question is no.
How can that happen?
Simple: the Conditions of Satisfaction (COS) changed, but no one was aware that they had.
The project manager did not check with the client to see whether the needs had changed, or the client did not inform the project manager that such changes had occurred.
Project Management Closure
5. Conducting the post-implementation audit
4. Was business value realized? (Check the success criteria.)
The success criteria were the basis on which the business case for the project was built,
and were the primary reason why the project was approved.
Did you realize that promised value?
When the success criteria measure improvement in profit, market share, or
other bottom-line parameters, you may not be able to answer this question until some time after the project is closed.
5. What lessons were learned about your project management methodology?
Companies that have or are developing a project management methodology will want to use completed projects to assess how well the methodology is working.
Different parts of the methodology may work well for certain types of projects or in certain situations, and these should be noted in the audit.
These lessons will be valuable in tweaking the methodology or simply noting how to apply the methodology when a given situation arises.
This part of the audit might also consider how well the team used the methodology, which is related to, yet different from, how well the methodology worked.
Project Management Closure
5. Conducting the post-implementation audit
6. What worked? What didn’t?
The answers to these questions are helpful hints and suggestions for future project managers and teams.
The experiences of past project teams are real “diamonds in the rough”—you will want to pass them on to future teams.
The post-implementation audit is seldom done, which is unfortunate because it has great value for all stakeholders.
Some of the reasons for skipping the audit include the following:
Managers don’t want to know—They reason that the project is done and what difference does it make whether things happened the way you said they would? It is time to move on.
Managers don’t want to pay the cost—The pressures on the budget (both time and money) are such that managers would rather spend resources on the next project than on those already completed.
It’s not a high priority—Other projects are waiting to have work done on them, and completed projects don’t rate very high on the priority list.
There’s too much other billable work to do—Post-implementation audits are not billable work, and people have billable work on other projects to do.
Project Management Closure
6. Celebrating Success
There must be some recognition for the project team at the end of the project.
This can be as simple as individual thank-you notes, a commemorative mug, a T-shirt, a pizza party, or tickets to a ball game; or it can be something more formal, such as bonuses.
I recall that when Release 3 of the spreadsheet package Lotus 1-2-3 was delivered, each member of the project team was presented with a videotape showing the team at work during the last week of the project.
That was certainly a nice touch and one that will long be remembered by every member of the team.
Even though the team may have started out as a “herd of cats,” the project they have just completed has honed them into a real team.
Bonding has taken place, new friendships have formed, and mentor relationships have been established.
The individual team members have grown professionally through their association with one another, and now it is time to move on to the next project. This can be a very traumatic experience for them, and they deserve closure.
That is what celebrating success is all about.
My loud and continual message to the senior management team is this:
Don’t pass up an opportunity to show the team your appreciation.
This simple act on the part of senior management promotes loyalty, motivation, and commitment in their professional staff.
Project Management Closure
6. Celebrating Success Cont…
End of Session Activity
The post-implementation audit is vitally important in improving the practice and process of project management, yet it is always so difficult to get senior management and the client to allocate the time to authorize and participate in these audits.
Knowing that, what would you as project manager do to help alleviate this problem?
End of Session Activity
Any questions?
Reading Materials
Core Textbook
Wysocki, R, K; (2009), Effective Project Management: traditional, agile, extreme – 5th edition, Indianapolis, Wiley. http://
capitadiscovery.co.uk/bcu/items/1091130
Other useful Textbooks – or any Project Management book
Cobb, C, G: (2011) Making sense of agile project management: balancing control and agility. Hoboken, N:J Wiley http://
capitadiscovery.co.uk/bcu/items/1138767
Maylor, H (2010) Project Management. Harlow: Prentice Hall Financial Times http://capitadiscovery.co.uk/bcu/items/1047967
powerpoint/MAN7084 Wk_Session11.pptx
MAN7084 Project Management
Week 11
Extreme (xPM) & Emertxe (MPx) Project
Teaching Team:
Suhil Khan: Suhel.Khan@bcu.ac.uk
Kulbir Bains: kulbir.bains@bcu.ac.uk
Session objectives
Recap on Agile Project (WK10)
Extreme (xPM) & Emertxe (MPx) Project
Q & A
Agile Project Management -Recap
Based on testimonial data collected from over 10,000 project managers from around the world, over 70 percent of projects are best managed by processes that adapt to continual learning and discovery of the project solution.
When in doubt, leave it out.
When the pain the organization is suffering from failed projects reaches some threshold, the health of the business suffers and the bottom line is affected.
If all previous corrective action plans have failed, senior management is ready to listen.
—Robert K. Wysocki, PhD, President, EII Publications, LLC
Agile Project Management -Recap
History of Agile
There are several Agile models to choose from. Prototyping and Evolutionary Waterfall Development are two robust Agile PMLC models that can be used for any type of project.
The four popular choices for software development are:
1. Rational Unified Process (RUP),
2. Scrum,
3. Dynamic Systems Development Method (DSDM), and
4. Adaptive Software Development (ASD).
All four are Iterative PMLC models. These models are similar in that they are designed to facilitate software solution discovery.
5.There is a fifth Adaptive PMLC model that you will also learn about called Adaptive Project Framework (APF).
Agile Project Management – APM
Iterative Project Management Life Cycle
The Iterative PMLC model requires a solution that identifies the requirements at the function level but might be missing some of the details at the feature level.
In other words, the functions are known and will be built into the solution through a number of iterations, but the details (the features) are not completely known at the beginning of the project.
The missing features will come to light as the client works with the most current solution in a prototyping sense.
The Iterative PMLC model is a learn-by-doing model.
Agile Project Management – APM
The use of intermediate solutions is the pathway to discovering the intimate details of the complete solution.
The Iterative PMLC model embraces several types of iteration.
Iteration can be on requirements, functionality, features, design, development, solutions, and other components of the solution.
An iteration consists of the Planning, Launching, Monitoring and Controlling, and Closing Process Groups.
Closing an iteration is not the same as closing the project.
Iterative Project Management Life Cycle
Agile Project Management – APM
The Iterative PMLC model kicks in when one of the following occurs:
Most but not all of the solution is clearly known.
You might otherwise have chosen the Incremental PMLC model but have a strong suspicion that there will be more than a minimum number of scope change requests.
You might otherwise have chosen the Adaptive PMLC model but are concerned about lack of client involvement.
There is some added risk to this decision.
Iterative Project Management Life Cycle
Agile Project Management – APM
Iterative Project Management Life Cycle
Most of the Solution Is Clearly Known
Some of the details solution are missing; the alternatives to how those details (that is, features) might be added to the solution are probably known up to a point.
All that remains is to give the client a look at how those features might be deployed in the solution and get their approval on which alternative to deploy or their recommendations for further change.
This is the simplest of the Iterative situations you will encounter, Production prototype approaches are the usual choice
As far as the project team knows, all of the functions and sub-functions have been identified and integrated into the current solution. As features are added, there could be changes in how the functions and sub-functions are deployed in the solution, and hence, further changes are recommended. This is the nature of an Iterative approach. It continues in this vein until the client says you are done or until time and/or money is exhausted.
Agile Project Management – APM
Iterative Project Management Life Cycle
Planning Phase of an Iterative PMLC Model
Planning is done at two levels in the Iterative PMLC model.
The initial Planning Phase develops a high-level plan without much detail.
The reason is that the full detail is not known at the initial stage.
The functionality is known, and its design and development can be planned across any number of iterations.
There are two ways to structure the high-level plan in the Iterative PMLC model.
The Complete Plan for Building the Known Solution
The first iteration in this plan may be of long duration in order to accommodate building a production version of the entire but incomplete known solution.
If you feel that this iteration will be too long, then you might consider using a tool to model the solution instead.
You will use that model throughout the entire project and create the production version of the complete solution at the end of the project.
Agile Project Management – APM
Iterative Project Management Life Cycle
Planning Phase of an Iterative PMLC Model
The Partial Plan for the High-Priority Functions
For this approach, you will begin the partial plan by prioritizing the functions and features in the initial RBS.
The rule for prioritization will most likely be business value so that the deliverables from an iteration can be released to the end user,if the client so chooses.
Alternatively, the prioritization might be based on risk or complexity: high-risk functions at the top of the list or high-complexity functions at the top of the list.
By developing these functions early in the project, you ensure the successful completion of the project. In some cases, all the known functions and features will be developed in the first few iterations.
Later iterations then drill down to possible areas for further identification and development of features.
This is probably the most efficient of all the development alternatives you might consider.
Yet another strategy would be to develop the high-risk parts of the system first.
That removes one of the major variables that could adversely affect the project if left to a later iteration.
A final rule may be to satisfy as many users as possible with your choice of functions or features.
Agile Project Management – APM
Iterative Project Management Life Cycle
Launching Phase of an Iterative PMLC Model
There is a significant difference between the project team for a Traditional Project Management (TPM) project and the project team for an APM project. The team profile for an Iterative PMLC model can be somewhat relaxed, whereas the profile for the Adaptive PMLC model should be adhered to as closely as possible.
In addition to the team differences that you have to consider, there is one major difference in the way scope change is dealt with.
In TPM projects, there must be a formal scope change management process.
That is not the case in an APM project. There is no need for a formal scope change management process in an APM project, because all of the learning and discovery that takes place during an iteration in an APM project is saved and reviewed between iterations.
The items in the Scope Bank are prioritized for integration into the solution in a later iteration.
Differences Between a TPM Project Team and an APM Project Team
Agile Project Management – APM
Iterative Project Management Life Cycle
Monitoring and Controlling Phase of an Iterative PMLC Model
In the Iterative PMLC model, the Monitoring and Controlling Phase begins to change.
Because of the speculative nature of the iterative strategy, much of the heavy documentation and status reporting gives way to more informal reporting.
Much of that formalism becomes non-value-added work and begins to burden the team with tasks that do not bring them any closer to the final solution.
You want to be careful to not overload the architects and developers with those types of tasks.
Let them remain relatively free to pursue the creative parts of the project.
During the between-iteration reviews, you should review the status and progress of solution definition and make any needed adjustments.
Agile Project Management – APM
Iterative Project Management Life Cycle
The Adaptive models are more appropriate for projects involving higher levels of uncertainty and complexity than the Iterative models.
In that sense, they fill a void between the Iterative and Extreme models.
Adaptive models are more useful than Iterative models in those situations where very little is known about the solution.
– Keep in mind that solution discovery is still the focus of these models.
Each iteration in the Adaptive models must address not only task completion for newly defined functions and features, but also further solution definition through function and feature discovery.
– It is the discovery part of the Adaptive PMLC models that sets them apart from the Iterative PMLC models.
Key Points on Iterative Life Cycle
An Adaptive PMLC model consists of a number of phases that are repeated in cycles, with a feedback loop after each cycle is completed.
Each cycle proceeds based on an incomplete and limited understanding of the solution.
Each cycle learns from the preceding cycles and plans the next cycle in an attempt to converge on an acceptable solution.
At the discretion of the client, a cycle may include the release of a partial solution.
Unlike the Iterative PMLC model where some depth of the solution is not known (features, for example), –
– the Adaptive PMLC model is missing both depth and breadth of the solution.
Agile Project Management – APM
Iterative Project Management Life Cycle
With the exception of using the term “cycles” in place of “iterations,” the Process Group–level diagram for the Adaptive PMLC model is identical to the Iterative PMLC model; but the similarity ends there.
There is only one Adaptive model, it is the Adaptive Project Framework (APF), APF was built to be applicable to any type of project.
For that reason, I offer a more in-depth discussion of APF, APF thrives on learning, discovery, and change.
In time, and with enough cycles, you hope that an acceptable solution will emerge.
Agile Project Management – APM
Iterative Project Management Life Cycle
Adaptive PMLC model, as with other Agile approaches, the degree to which the solution is known might vary over a wide range from knowing a lot but not all (projects that are a close fit for the Iterative PMLC models) to knowing very little (projects that are a close fit for the Adaptive PMLC models).
The less that is known about the solution, the more risk, uncertainty, and complexity will be present.
To remove the uncertainty associated with these projects, the solution has to be discovered.
That will happen through a continuous change process from cycle to cycle.
That change process is designed to create merging to a complete solution.
In the absence of that merging, Adaptive projects are frequently cancelled and restarted in some other promising direction
Agile Project Management – APM
Iterative Project Management Life Cycle
Scoping Phase of an Adaptive PMLC Model
The Scoping Phase of the Adaptive PMLC model is a high-level activity because not much is known about the solution.
The missing functions and features have to be discovered and learned through repeated cycles much like the Iterative SDPM strategy.
For the Adaptive PMLC model, the scoping activities merely set the boundaries and the high-level parameters that will be the foundation on which you proceed to learn and discover.
As part of the Scoping Phase deliverables, you will document requirements, as you know them; functionality, as you know it; and features, if you know any.
In addition, you will specify the number of cycles and cycle length for the first cycle. If you have enough insight into the solution, you might tentatively map out the cycle objectives at a high level.
A partial high-level Work Breakdown Structure (WBS) can help complete this exercise.
Agile Project Management – APM
Iterative Project Management Life Cycle
Planning Phase of an Adaptive PMLC Model
At this point in the Adaptive PMLC model, planning is done for the coming cycle.
High-level planning was done as part of the Scoping Phase. Based on the known functionality and features that will be built in the coming cycle, a detailed plan is developed.
This plan utilizes all of the tools, templates, and processes that were defined for the Planning Process Group.
Conclusion
Using Iterative and Adaptive PMLC models can be among the most challenging and fulfilling experiences you might have as a project manager.
These models have many similarities and differences.
Projects are dynamic efforts and conditions could suggest changing your choice of model and how best to use it.
There are many more choices for those who are interested.
Learning to be successful with Agile projects is as much an art as it is a science.
Agile projects are definitely calling upon you to be a chef and not a cook
Extreme Project Management
Overview –Extreme & Emertxe
Both Extreme and Emertxe projects utilize the same PMLC models but with very different purposes in mind.
The major differences are seen in iteration planning and interpretation of the deliverables from each iteration.
The vast majority of these projects are research and development (R & D) projects.
For projects in the xPM quadrant, the goal is a best-guess and usually reflects the proposer’s idea of an ideal end state that the project should attain.
Extreme Project Management
Overview –Extreme & Emertxe
What Is Extreme Project Management?
Extreme Project Management (xPM) is the least structured and most creatively managed of the five models that define the project management landscape.
Because of that, the failure rates of Extreme projects are the highest among all types of projects.
The reason for the high comparative failure rate follows from the nature of the Extreme project.
These projects are searching for goals and solutions where none have been found before.
Goals are often nothing more than an expression of a desired end state with no certainty they can ever be attained.
Extreme Project Management
Overview –Extreme & Emertxe
What Is Extreme Project Management?
Solutions are often totally unexplored; at most there will be a few alternative directions to begin the search.
Even if a solution is achieved, it may only apply to a revised goal statement, then there is the question of the business value of the final goal and its solution.
Risky, isn’t it?, to touch on a goal and solution with business value is often a hunt in a dark room for something that doesn’t exist in that room but might in another room, if you knew where to find that other room.
And so one of the major challenges in xPM projects is to terminate the chosen direction at the earliest point where future failure is almost a certainty.
That allows for saving resources for a redirection of efforts.
Overview –Extreme & Emertxe
What Is Extreme Project Management?
Definition
Extreme PMLC models consist of a sequence of repeated phases with each phase based on a very limited understanding of the goal and solution.
Each phase learns from the preceding ones and redirects the next phase in an attempt to meet an acceptable goal and solution.
At the discretion of the client, a phase may release a partial solution.
A phase consists of the five Process Groups, each performed once in the sequence Scoping Planning Launching Monitoring and Controlling Closing.
In effect, a phase is a complete project life cycle much as it is in the Incremental PMLC model, but with an option to release a partial solution at the completion of each phase.
Extreme Project Management
Overview –Extreme & Emertxe
What Is Emertxe Project Management?
If you haven’t already guessed it, Emertxe (pronounced ee-MURT-see) is Extreme spelled backwards.
And indeed an Emertxe project is an Extreme project, but done backwards.
Rather than looking for a solution, you are looking for a goal.
Pardon my play on words, but it was the best way to name these types of projects.
Extreme Project Management
Overview –Extreme & Emertxe
The Emertxe Project Management Life Cycle
The Emertxe PMLC model looks exactly the same as the Extreme PMLC model.
Everything that was said previously about the Extreme PMLC model applies unchanged in the Emertxe PMLC model.
The differences have to do with the intent of the project.
The Extreme PMLC model starts with a goal that has great business value and searches for a way (a solution) to deliver that business value.
The solution may require a change in the goal.
If that revised goal still has great business value, the project ends.
The Emertxe PMLC model starts with a solution and no goal. The question to be
Extreme Project Management
Overview –Extreme & Emertxe
The Emertxe Project Management Life Cycle
The Emertxe PMLC model looks exactly the same as the Extreme PMLC model.
Everything that was said previously about the Extreme PMLC model applies unchanged in the Emertxe PMLC model.
The differences have to do with the intent of the project.
The Extreme PMLC model starts with a goal that has great business value and searches for a way (a solution) to deliver that business value.
The solution may require a change in the goal.
If that revised goal still has great business value, the project ends.
The Emertxe PMLC model starts with a solution and no goal.
The question to be answered by the Emertxe PMLC model is this, “Is there a goal that this solution can reach, and does that goal have business value?” The commonality is that both PMLCs strive to gain a simultaneous convergence of goal and solution, but from different perspectives—one to find a solution, the other to find a goal.
Extreme Project Management
Overview –Extreme & Emertxe
The Emertxe Project Management Life Cycle
When to Use an Emertxe PMLC Model
The Emertxe PMLC model should be your model of choice in any project that seeks to find business value through the integration of a new technology into a current product, service, or process.
There are two major types of projects that call for this model to be used: R & D projects and some problem-solution projects.
Research and Development Projects
This is the most obvious application.
You are considering how, if at all, a new technology provides business value to your organization.
The search for the goal might lead your team in obvious directions, or it could be very elusive.
Extreme Project Management
Overview –Extreme & Emertxe
The Emertxe Project Management Life Cycle
Problem-Solution Projects
In most cases, you would initially choose to use APF for these types of projects.
The solution of a critical problem is sought.
The goal will therefore be clearly and completely stated, and you start out on a journey to find and define a complete solution.
Not long into the project, you and the client come to the conclusion that a complete solution to the problem as stated doesn’t seem too likely.
You could abandon the project, but that might not be an acceptable resolution.
Perhaps the next question should be this:
What problem can you solve? Now the goal is not clearly stated.
Congratulations, you now meet the conditions of an Extreme project, but you are using an Adaptive model.
Do you change models or continue on the present course?, would there be any noticeable difference between the two models given the present situation? – you know that APF is Adaptive, can you adapt APF to fit this situation?
Extreme Project Management
Overview –Extreme & Emertxe
The Emertxe Project Management Life Cycle
Using the Tools, Templates, and Processes for Maximum xPM Effectiveness
The key here is to create an environment in which the project team can freely exercise their creativity without the encumbrance and nuisance of non-value-added work.
The agilest would say that this should be an environment that is light or lean versus heavy.
This section gives you a quick look at each part of the Extreme PMLC model to see how the Process Group tools, templates, and processes might be used or adapted to the best advantage of the xPM project team.
Extreme Project Management
Overview – Extreme & Emertxe
Scoping the Next Phase
The Scoping Process Group includes the following:
Eliciting the true needs of the client
Documenting the client’s needs
Negotiating with the client how those needs will be met
Writing a one-page description of the project
Gaining senior management’s approval to plan the project
A roughly structured COS for the next phase is the starting point, hold off on any attempt at specificity.
That is not the nature of an xPM project, if this phase is among the first few phases of the project, expect them to focus on a general investigation of high-level ideas about a solution.
There might be several con-current ideas to explore in an attempt to further define possibilities.
These are very preliminary ideas and must be treated as such. After some possibilities are identified, more Probative Swim Lanes might be launched to drill down into the feasibility of these ideas.
A POS might be drafted that will remain valid for a few phases, but expect it to be superseded quickly and often.
The approval to actually plan the phase will be a client approval.
Extreme Project Management
Overview –Extreme & Emertxe
The Planning Process Group includes the following:
Defining all of the work of the project
Estimating how long it will take to complete the work
Estimating the resources required to complete the work
Estimating the total cost of the work
Sequencing the work
Building the initial project schedule
Analysing and adjusting the project schedule
Writing a risk management plan and Documenting the project plan
Gaining senior management’s approval to launch the project
Planning the Next Phase
Extreme Project Management
Overview –Extreme & Emertxe
Planning is a two-level process in xPM Projects.
The first level is to satisfy senior management’s requirements and get approval to do the project.
After that approval is granted, planning can move to the phase level.
Planning at the phase level isn’t much more than just deciding what Probative Swim Lanes make sense and can be completed inside the phase time box.
So the little bit of detailed planning that is done is done at the swim-lane level.
The sub-team will plan what is to be done and who will do it.
Don’t burden them during the early phases with needless planning documents and reports.
Leave them free to approach their swim-lane tasks in a way that makes sense for them.
Detailed dependency diagrams are usually not prepared. However, there should be a lot of verbal communication among the team members as to the status of their swim lanes.
Extreme Project Management
Overview –Extreme & Emertxe
xPM projects are very high risk, and a solid plan is needed.
Just as in the case of APM projects, you should appoint a team member to be responsible for monitoring the plan.
The plan itself can take on different characteristics than planning in all other types of projects.
Here is an application of risk planning that I have used with success.
To the extent that you can identify the requirements or functions that the solution should have, prioritize that list from most risky to least risky as far as implementation is concerned.
The early phases should focus on this list from top to bottom.
If you can resolve the risky requirements or functions, then you can resolve other requirements or functions further down the list.
Of course, the list will change as new learning and discovery takes place.
Always attack the riskiest parts of the project first.
Extreme Project Management
Class Activity (during and continue after class)
Undertake the Moodle background reading for Extreme Project Management.
Discuss in small groups examples of when Extreme project management would be useful for your industry sector and present back to the class.
Some of the analytical work here can be added to your final assignment.
Any questions?
Reading Materials
Core Textbook
Wysocki, R, K; (2009), Effective Project Management: traditional, agile, extreme–5thedition, Indianapolis, Wiley. http://capitadiscovery.co.uk/bcu/items/1091130
Other useful Textbooks–or any Project Management book
Cobb, C, G: (2011) Making sense of agile project management: balancing control and agility. Hoboken, N:J Wiley
http://capitadiscovery.co.uk/bcu/items/1138767
Maylor, H (2010) Project Management. Harlow: Prentice Hall Financial Times http://capitadiscovery.co.uk/bcu/items/1047967
Order an Essay Now & Get These Features For Free:
Turnitin Report
Formatting
Title Page
Citation
Outline
