project management
jhh19970724
powerpoint.zippowerpoint/MAN7084 Project Management Wk_Session 10.pptx
MAN7084 Project Management
Week 10
Agile Project Management
Suhil Khan: [email protected]
Kulbir Bains: [email protected]
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
Alternatively try use Microsoft Project – Free Trial https://products.office.com/en-us/project/project-professional-
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 - [email protected]
Suhel Khan - [email protected]
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 - [email protected]
Suhel Khan - [email protected]
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 - [email protected]
Suhel Khan - [email protected]
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