Project Management Module 4 Script

Project Management Principles: Execute & Finish Phases - Module 4
Topics:
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. An overview of the Execution stage of the life cycle H/R and Communications management Monitoring and controlling execution Quality auditing and continuous improvement Integration processes for the PM Integrated change control Finishing phase & getting handover right Project Closure and reflection Final recap of Project Management Where to from here
Topic 1: The Execute or doing phase overview

Welcome to Module 4 of the Project Management subject. In this subject we are going to discuss: The Executing life-cycle phase in more detail, including: o o o o o o o o o o Executing processes for H/R and effective Communication Processes for monitoring and controlling progress on your project Assuring and controlling quality as well as seeking to continuously improve processes and procedures Integration processes the PM is responsible for, directing execution and monitoring and controlling the work. How to integrate changes into the project during execution with the minimum of fuss Well also discuss the Finishing phase of the project, including: The two closeout processes of closing procurements and closing the project or phase. How to manage handover of the project goal Why the team should always reflect on the running of the project at the end The importance of archiving project documentation for future projects
Then Ill provide a final recap of Project Management, summarising what we have covered in these four modules And well finish with a section on where you can progress to from this MOOC.
Page 1 of 35
In Module 1 we introduced the acronym C-D-E-F to represent a four phase project life-cycle, being the Concept, Development, Execution and Finishing phases. In the last Module we looked at the Develop phase of the project life cycle, where all the work for planning all foreseeable details of your project is performed. In this module well cover Execute and Finish! Do remember that just because you move into the Execute phase of the projects life cycle it doesnt mean you may not be revisiting some of these planning processes though! Invariably as the project moves into execution mode areas not previously foreseen will raise their heads and necessitate revisiting some of those planning processes! In this topic we will start with an overview of the management processes that occur in the Execution (or doing) phase of a project. The execute phase of the project is where you finally get to do some work!... not really you already have done a lot of project management work! It is just when the work on the end goal of your project begins. Basically the Execute phase of the projects life cycle is where the Project Management Plan is put into action and the work activities as defined in the plan are carried out according to the resources and time frames also contained there. In a perfect world everything requiring execution will be contained in the Plan at the start of the projects execution but reality dictates that changes are likely to be required which we will discuss in Topic 6 under Change Control. There are 42 processes PMBoK recommends for managing projects and 18 of them fall into the two process groups of executing and monitor and controlling. Both these process groups are typically utilised during the Execute phase of the projects life. Where executing processes all revolve around completing the work that has been defined as accurately as possible during the Develop phase of the project (all encompassed in the Plan), the monitoring and controlling processes happen in parallel as they require the tracking, reporting, managing and analysing of the projects progress. In fact to some extent these processes are used throughout the entire project life cycle as at Concept, Develop, Execute and Closing phases performance should be measured and reported on. Key personnel such as the Project Sponsor are going to want to know how planning processes progress just as much as the executing processes after all without knowing where planning is at they will not be able to assess how long it is until the work of creating the project deliverable will start or for that matter, assess whether it should. When reaching the Execute phase of the projects life what is vital is that monitoring and controlling processes are used to assess and inform key stakeholders about how accurately the baselines created in the project management plan are being matching by project performance. One of the key tools for scope, time, cost, communication and risk management is Variance Analysis. In essence variance analysis is the observation of variance (or difference) between planned and actual, and the considered response to resolve that variance. Recording a variance is not sufficient methods also need to be determined as to how to either reduce the variance to an acceptable amount, or if required get agreement to a change in the baselines to reflect the change that has occurred between planned and actual. As long as the project plan is executed according to plan, and monitoring and controlling processes are used to report on and validate that progress, the Execute phase of the projects life should continue for the period that the plan is being
Page 2 of 35
activated. It is the phase of the project where you expect to see the majority of the work carried out as well as the greatest amount of expenditure. The biggest risk to the project at this stage can be unmanaged project changes. Unfortunately it may not be until project execution, when the first of the actual project deliverables are being created and verified with the Client, that they realise there are changes they would like. Having their and end users involved throughout concept and planning is the best way to minimise this, but many project leaders will be able to tell you how a client still didnt get it until they started seeing the end deliverable being created. Well discuss the H/R and Communication execution processes in the next topic, but at this stage well have a quick look at the execution process for Procurement. In Module 3 we discussed how to plan for Procurements and the importance of weighing up what parts of the project may be best procured, and how you may be able to reduce risk in some cases by doing so. Here we will overview Conducting Procurements. See the accompanying illustration for the inputs, tools & techniques and outputs. o Conducting procurements inputs consist of: Project Management Plan, Procurement documents, Source selection criteria, Qualified seller list, Seller proposals, Project documents, Make or buy decisions, Teaming agreements, Organisational process assets. Tools & Techniques recommended are: Bidder conferences, Proposal evaluation techniques, Independent estimates, Expert judgement, Advertising, Internet search, Procurement negotiations Outputs are: Selected sellers, Procurement contract award, Resource calendars, Change requests, Project management plan updates, Project document updates
Just as we earlier warned against seeing winning a tender as a project goal, without proper evaluation of the SOW, being the organisation seeking procured services also has traps. Make sure you thoroughly evaluate seller proposals using the T&T described for this process. Too many have been caught out by overenthusiastic bidders and been complacent because they believe penalties for nonprovision or missed deadlines will ensure the selected seller will provide the procured service, product or result. However history shows us that without proper analysis you may end up with a sub-standard result or nothing at all and you need to weight up the risk of that occurring, as if it endangers the success of your project, regardless of it being the providers fault, as Project Manager you are likely to end up wearing the blame. We will next examine execution processes for H/R and communications in greater detail as these two knowledge areas are both closely related as well as requiring the best of a PMs soft skills in communicating and displaying emotional intelligence! o Before progressing to the next topic encourage to look at the Readings Tab. All That You Need to Know Regarding Execution of Projects on the Bright Hub PM website.
Page 3 of 35
Useful Links
VIDEO: WEB: http://en.wikipedia.org/wiki/Emotional_intelligence Overview of what emotional intelligence is. http://www.maxwideman.com/papers/procurement/procurement.pdf Review of book on Procurement Management that includes useful information. http://www.building.co.uk/news/qs/apc-trainer-on-procurement-and-tendering%28t062%29/3112815.article Explanation of procurement and tendering processes http://www.projectsmart.co.uk/ten-tips-for-running-successful-projects.html 10 tips for running successful projects by Leslie Allan. http://www.brighthubpm.com/project-planning/3387-how-to-effectively-plan-andexecute-a-project/ How to Effectively Plan and Execute a Project by Joe Taylor http://www.brighthubpm.com/project-planning/124879-all-that-you-need-to-knowregarding-execution-of-projects/?cid=parsely_rec All That You Need to Know Regarding Execution of Projects, with hyperlinks to supporting information. http://www.youtube.com/watch?v=vDkuYoMvgG0 Overview of conducting procurements using PMBoK Ed.5 process by Tamilselvan Mahalingam http://www.youtube.com/watch?v=vl_nmOZB2Og Good overview of project procurement basics, looking mostly at what procurements are and how to plan them.
Page 4 of 35
Topic 2: H/R and Communications management

o o In this topic we will look at the 5 executing processes for the h/r and communications knowledge area. The first set of processes we will look at belong to the Human Resources knowledge area. They are: 1. acquiring the project team, 2. developing it and 3. managing it. o Should be obvious having the right people for the job is a really good start for running a project successfully. While having team members that have been involved with projects before, and who have had some form of training in project management processes will help, for most of the team what will be critical is that they have the technical skills required to carry out the work activities they have been assigned to and the personality traits to work well in a team. The most skilled individual in the world can throw a project into chaos if they refuse to work in with the team! See the accompanying illustration for the inputs, tools & techniques and outputs of acquiring the project team. Acquiring the project team consist of: o o o o Inputs: project management plan, enterprise environmental factors and organisational process assets. Tools & Techniques recommended are: Pre-assignment, Negotiation, Acquisition and Virtual teams Outputs are: Project staff assignments, resource calendars, project management plan updates
o o
Because acquiring the project team should be partly based on what skills are required for the project work as worked out in the Time management processes where the team has broken down the work of the project into an extensive list of activities and estimates of sequence, duration and resources required for each, acquiring the project team is listed in PMBoK as happening in the Execution phase , so there will be informed decisions made about who needs to be brought onto the team. However while it makes sense to acquire members with specialist skills after working out whihc skills are needed, this doesnt fit with the recommendations we made back in Module 2 about making sure that the PM involved their team members in doing the estimates as after all the best guidance on how long a task will take and what resources it is likely to require are likely to come from the SMEs in that area! It also doesnt fit with the suggested input of Resource Calendars for estimating activity resources! This is all symptomatic of the slightly egg-or-chicken first nature of project management... just as it is often pointed out that it is easy to be clever in hindsight, many project planning processes are easier done after other planning processes have been performed, but because as in the case of acquiring a team and planning what the team member skills need to be they cant both be done simultaneously project teams instead rely on iteration... being repeated as more knowledge is discovered. In truth it is likely that the key project team members which will include people with SM Expertise will be put together at the end of the Concept phase, and with the key team providing expert advice throughout planning, the whole team can be acquired at the start
Page 5 of 35
and during the execution phase as required. After all there are many projects that require specialist skills at only some stages and so there is no point in hiring staff that are not going to be required until sometime in the future. o o In the interim plans can be made with job titles instead of peoples names assigned, denoting the need for a human resource but not specifically who that will be. The Resource Calendar output of this process simply documents the availability, work time wise, of each of the project team. It should include any pre-booked leave or commitments. This information can obviously have an impact on a number of other processes such as task durations and activity sequencing. If a person with a key skill the Project Team really wants to utilise for some activities is not going to be available for a certain block of team then activity sequencing may need to be adjusted and accordingly some lead or lag times added to other activities or team reassignments to ensure the time when waiting for that particular person to be available is fully utilised. Next lets look at Developing the Project Team. See the diagram for process inputs, T&T and outputs. o o o o Developing the Project Team consists of: Inputs: project staff assignments, project management plan, resource calendars. Tools & Techniques recommended are: Interpersonal skills, Training, Team-building activities, Ground rules, Co-location and Recognition and rewards. Outputs are: Team performance assessments and updates to enterprise environmental factors
Building a team is something that can occur in many different ways. For instance, though it is not listed within PMBoK, once the final project team is assembled and the project management plan is ready to execute a kick-off event should be held for the execution stage of the project. We already mentioned a kick-off event at the end of the Concept phase- which would be for the key Project Team members but a further kick-off event should not be undervalued. While you and your immediate team that have planned out all the work that needs doing will be feeling very familiar with the scope and objectives, staff that have been especially recruited or seconded for the technical work of the project will really benefit by knowing what the organisational vision behind running the project is. The benefits of running a kick-off event for the entire project team are the same as holding one for your planning team: Everyone gets to be on the same page when it comes to understanding the project objectives and goal Roles and responsibilities, including who to go to in management for direction or assistance, will be clearer Allows opportunity for people to ask questions and hear answers from the horses mouth. Outlines important processes and procedures you wish to see team members follow. Helps everyone know how communication will work and where important documents such as the Project Management Plan can be found. Confirms the project proper has begun in other words that the PM Plan has been formally authorised to move to execution. Additional benefits are that the Project Manager can demonstrate their leadership qualities by enthusing team members about the project, organising the meeting
Page 6 of 35
effectively so everyone feels their time has been well spent and empowering people by letting them know where to go for what and what their responsibilities are. o A well run kick-off event will help in the work of building a strong team ethos, as all present should feel they are an important part of the project.
Another simple and productive way to help build a team is to involve them in planning processes. As a PM you would benefit from their knowledge, and they will benefit from knowing their opinions are being sort and listened to. The next execution process for Human Resources is to manage the project team. See the accompanying image for inputs, t & t and outputs. o o o Inputs: project staff assignments, project management plan, Team performance assessments, Performance reports and organisational process assets. Tools & Techniques recommended are: Interpersonal skills, observation & conversation, project performance appraisals, conflict management and an issue log. Outputs are: Change requests, organisational process assets updates, project management plan updates and enterprise environmental factor updates.
The tool of an Issue log has not been previously discussed. While most people are familiar with Risk Registers, that help document, track and monitor unexpected (in the future) events that may impact the project either positively or negatively, an issue log is a place where issues (things that have eventuated) can be logged. Team members &/or stakeholders may raise issues that require some action to be taken to prevent them being hindered in their work. The logged issue should be assigned a measure of urgency and allocated to an individual for resolution by a proposed date. As part of communications management Issue logs need regular assessing and attending to as unresolved issues may end up causing delays and major conflict, none of which is good for the harmony of the team and may block the team from achieving the project objectives. The next set of processes we will look at belong to Communications Management knowledge area. There is a fair overlap between the outputs of human resource and communication management as you may expect. People management and effective communication usually go hand in hand. The communication management processes are: 1. distributing information and 2. managing stakeholder expectations (which includes the project team members as well as other external and internal stakeholders).
The first execution process for Communications we will examine is to distributing information. This sounds simple but what you distribute to who actually requires some careful consideration. Overloading people with information they dont need to know can lead to saturation and a tendency to just ignore all communications which can be extremely dangerous. In the same way not keeping the right people informed about relevant information for them can lead to gaps in understanding which in turn can lead to frustration and conflict within the project. See the accompanying image for a list of the inputs, T&T and outputs for distributing information. o o Inputs: Project management plan, Performance reports and Organisational process assets. Tools & Techniques recommended are: Communication methods, Information distribution tools
Page 7 of 35
o o
Outputs are: Organisational process assets updates.
Sounds simple but must be done well. For instance avoid overloading people with information as there is a risk they will simply tune out which can be dangerous as they may then miss information critical to their work tasks. The tools & techniques for information distribution have been dramatically impacted by advances in electronic communication. As the internet backbone increases in bandwidth and speed more and more effective real time communication is occurring between geographically remote team members. Resultantly project team members and stakeholders are increasingly being able to travel and maintain effective communication more easily. Similarly expert judgement is able to be sought from further afield to make sure that the best possible information and communication inputs and outputs are achieved. The next Communications execution process we will look at is managing stakeholder expectations. As we discussed back in Module 2 understanding who your stakeholders are, what their interest in the project is and their potential influence is one of the key processes in initiating a project at its Concept phase. The importance of stakeholders is demonstrated by the need to formally manage their expectations. The illustration shows the inputs, T&T and outputs PMBoK outlines. 1. Inputs: Stakeholder register, stakeholder management strategy, Project management plan, Issue log, Change Log and Organisational process assets. 2. Tools & Techniques recommended are: Communication methods, Interpersonal skills and Management skills 3. Outputs are: Change requests, organisational process assets updates, project management plan updates and project document updates.
Effective stakeholder management will mean you keep the right people supporting and championing your project throughout which should very importantly include your team it should also help you to manage the negative influence of those that seek to demote or discredit the project so as to not have a seriously negative impact. The Monitoring and Controlling processes we will examine next obviously need to be occurring at the same time project execution is taking place so that the progress of the project is measured as it is executed. There is very little point in waiting until the end of project execution to report that the project has run over time, budget and not met scope or quality standards! Before progressing to the next topic encourage to look at the Readings Tab and have a look at Simon Wallaces free electronic Project Management books chapter on Team Management for useful information on this area. It would be great if you could take the opportunity to discuss in the Forum innovative methods you are aware of for communicating between project stakeholders. There are some great ideas and methods available and project leaders will benefit from knowing the widest tool-set possible for allowing stakeholders to effectively communicate, regardless of their geographic location.
Page 8 of 35
Useful Links
VIDEO: WEB: http://www.epmbook.com/team.htm In depth look at building teams for projects http://www.techrepublic.com/blog/project-management/get-everyone-on-the-samepage-with-a-project-kickoff-meeting/138 benefits of having kick-off meetings http://www.tutorialspoint.com/management_concepts/project_kick_off_meeting.htm http://goodkickoffmeetings.com/tips/ designed for Web Project kick-offs. http://www.projectmanagementdocs.com/project-execution-templates/employeeannual-review.html template for reviewing employee performance http://www.projectmanagementdocs.com/project-documents/issue-log.html Sample and template for Issue Log. http://www.youtube.com/watch?v=qxjuo4Vnp6U How to kick-off a project http://www.youtube.com/watch?v=cJ91fLrTL9Q A 48 minute webinar on project communications and reporting http://www.youtube.com/watch?v=90RiAJTNUss Video on managing stakeholder expectation process and the goal this aims to achieve.
Page 9 of 35
Topic 3: Monitoring and controlling execution

In the last two topics we looked at most of the executing processes used for managing human resources, procurement and communication. As earlier discussed monitor and controlling is all about tracking the performance of the project, reporting on it and using tools and techniques to help keep it on track or in the case of a variance bring it back on track! In this topic we will look at the processes used for monitoring and controlling the project scope, costs and communications as well as risks and procurements. Scope management requires monitoring and controlling to: 1. 2. Verify scope Control scope Inputs: Project Management Plan, Requirements documentation, Requirements traceability matrix, Validated deliverables Tools & techniques: Inspection Outputs: Accepted deliverables, Change requests, Project management documents
The Verification of scope process requires (as illustrated)
Note that the work done back in Collecting requirements before you had even defined the scope, also helps to monitor scope verification, by providing information about the stakeholders documented requirements to verify if they have been met. This is typical of where the early work performed in a projects planning can pay off when it comes to getting acceptance of the project goal. Inspection is the only tool for verifying scope basically this is where the work and deliverables are checked to make sure they meet the requirements documented at project start that were defined by setting measurable outcomes and success criteria, the WBS work packages and any deliverables that have already been checked by Quality Control for correctness. These inspections may be called product reviews, walkthroughs or audits it doesnt really matter. What they are about is confirming that what was agreed to have been done is being done. If it has the deliverables inspected will be accepted.... if not it is likely a Change Request will result, requiring assessment and integration via integrated change control, which if accepted will likely result in updates being made to various project documents and rework. The sooner you can actually verify scope is being met during execution the more confident you can be that you will be meeting the customers requirements at handover. The scope control process requires (as illustrated) Inputs: Project Management Plan, Work performance info, Requirements documentation, Requirements traceability matrix, Organisational process assets Tools & techniques: Variance Analysis Outputs: Work performance measurements, Organisational process asset updates , Change requests, Project management plan updates, Project document updates
Variance Analysis was briefly discussed in the introduction to this module. In this case it is used to measure the variance between the originally defined scope and the scope during execution. If too great a difference occurs between planned and actual work then either corrective or preventative action may be required. Corrective action is documented directions designed to bring the project execution back in line with the scoped work from the projects
Page 10 of 35
scope baseline where preventative action is documented directions to alter future actions so that the scope may be brought back on line before execution is finished. Monitoring and controlling of Time management requires a process of: 1. Control schedule The control schedule process requires (as illustrated) o o Inputs: Project Management Plan, Project Schedule, Work performance info, Organisational process assets Tools & techniques: Performance reviews, Variance Analysis, Project management sware, resource levelling, what-if scenario analysis, adjusting leads and lags, schedule compression and scheduling tool. Outputs: Work performance measurements, Organisational process asset updates , Change requests, Project management plan updates, Project document updates
The tool of Variance Analysis in controlling the schedule basically works in the same was as for scope control it looks for difference between the baseline and the actual execution and uses variance over a certain amount as a trigger for corrective / preventative action. Schedule compression occurs by either fast tracking or crashing. Fast tracking is where activities originally defined as being performed sequentially (e.g. FS or SF) are altered to happen in //. Generally increases risk of rework though! Crashing is doing things to shorten the timeline like paying for overtime or bringing in additional staff and / or resources so generally incurs a financial penalty. Cost management monitoring and controlling requires the one process: Control of costs The control costs process requires (as illustrated) : o o Inputs: Project Management Plan, Project funding requirements, Work performance info, Organisational process assets Tools & techniques: Earned value management, forecasting, to-complete performance index, Performance reviews, Variance Analysis, Project management sware. Outputs: Work performance measurements, Budget forecasts, Organisational process asset updates , Change requests, Project management plan updates, Project document updates
1.
Earned Value Management (EVM) was developed for financial analysis back in the 60s but has become a popular tool in project management since the 1980s. What is special about it is that it allows PMs to combine measurements of scope / schedule / cost in a single system to track and forecast project performance. It helps with both monitoring and measuring variances from baseline. There have been studies that have shown a positive connection between EVM and project success rates. Communications management requires: o Report performance Inputs: Project Management Plan, Work performance info, Work performance measurements, Budget forecasts, Organisational process assets The report performance process requires (as illustrated) o
Page 11 of 35
o o
Tools & techniques: Variance Analysis, forecasting methods, communicating methods, Reporting systems Outputs: Performance reports, Organisational process asset updates , Change requests
Performance reports often referred to as Status Reports are probably the most commonly understood method of monitoring and reporting on project progress. They range between different companies in complexity and frequency, but what they should all show is: 1. 2. 3. 4. 5. 6. Work completed for the last period Work scheduled for completion for the period ahead Notification / explanation of variance Summary of any changes requested Current status of any risks and issues Currently forecast project end date (and possibly cost).
2.
Risk management requires the process of: Monitor and control risks The monitor & control risks process requires (as illustrated) o o o Inputs: risk register, Project Management Plan, Work performance info, performance reports Tools & techniques: risk assessment, risk audits, Variance & trend Analysis, technical performance measurements, status meetings. Outputs: Risk register updates, Organisational process asset updates , Change requests, Project management plan updates, Project document updates
The success of monitoring and controlling risks will be largely dependent on how good a job the team has done of identifying risks, analysing them and planning responses. What is vital is that throughout the life of the project the risk register is used to frequently reassess the risk landscape as continuing to identify as well as deal with and respond to risks in pre-planned ways is the best way to keep them from seriously impacting on the project. There is always the possibility of extreme unexpected events such as earthquakes, or death or insolvency but these will be rare. Of course if your project involves such life critical products as to require even these risks to be planned for, even more emphasis should be placed on planning responses.
In the next topic we will look at both execution and monitor & controlling processes for assuring and controlling quality on your project. Before progressing to the next topic encourage to look at the Readings Tab. Too many processes have been covered here to be fully explained, so do please check out all the readings and videos which will help better inform you about monitor & controlling processes for Project Management.
Page 12 of 35
Useful Links
VIDEO: WEB: http://www.brighthubpm.com/monitoring-projects/124945-collection-of-guides-andtips-to-improve-the-project-monitoring-process/ Great overview of series of articles aimed at helping better monitor and controlling of projects http://project-management-knowledge.com/definitions/v/variance-analysis/ Definition of Variance Analysis http://www.projectmanagement.com/articles/177431/The-Power-of-VarianceAnalysis Useful article on the power of variance analysis by George Spafford. http://en.wikipedia.org/wiki/Earned_value_management Overview of EVM http://www.brighthubpm.com/monitoring-projects/127582-earned-value-analysisforecasting-to-complete-performance-index/ Earned Value Analysis http://www.projectsmart.co.uk/earned-value-management-explained.html Earned Value Management explained by Umesh Dwivedi. https://www.youtube.com/watch?feature=player_embedded&v=IQK4QN-NqgM (40 years of great projects)
Page 13 of 35
Topic 4: Quality auditing, control and continuous improvement

In the last three topics we have covered most of the executing and monitoring and controlling processes, excluding quality assurance and control. This is because quality in a project is such an important area that it requires a topic of its own. There are only three processes for Quality Management in total and we covered the 1st Plan Quality back in the Develop phase of the projects life cycle, when Quality plans are built. The other 2 processes are from EXECUTE phase and are: 1. Perform Quality Assurance 2. Perform Quality Control While there are only three processes for Quality Management in total, the importance of getting quality standards right on a project is such that Quality Management has in its own right spawned a number of standards and methodologies such as: Total Quality Management (TQM) ISO 9000 and 9001 (Quality Management) Six Sigma - follows a five stage improvement process (often called DMAIC) of define, measure, analyse, improve and control. This process examines existing processes. If you are looking to build a new process you may use DMADV (define, measure, analyse, design and verify).
Execution process is: Perform Quality Assurance. Involves tools such as auditing results to make sure appropriate standards and definitions are are being used in the project execution. All about using the right processes and executing for quality! See the process diagram for: Inputs = Project management plan, quality metrics, work performance information, quality control measurements Tools & Techniques = Plan quality & perform quality control tools and techniques, quality audits, process analysis Outputs = Organisational process asset updates, change requests, PMP updates, project document updates
Monitor & control process is: Perform Quality Control. Recording results of quality activities, checking quality of deliverables against plans. All about results and monitor and controlling them! Process diagram displays: Inputs = Project management plan, quality metrics, quality checklists, work performance measurements, approved change requests, deliverables, organisational process assets Tools & Techniques = Cause & effect, control charts, flowcharts, histogram, Pareto charts, run chart, scatter diagram, statistical sampling, inspection, approved change requests. Outputs = quality control measurements, validated changes, validated deliverables, Organisational process asset updates, change requests, PMP updates, project document updates
Page 14 of 35
The input of Quality Metrics used for both this process and performing Quality Assurance is actually an output from having Planned Quality back in the Develop phase of the project. Establishing Quality Metrics then helps you to assure and control quality during execution. Seven tools of quality control are commonly listed for assisting in Quality Control and these are: Cause-Effect Diagram, Pareto Chart , Check Sheet, Scatter Chart, Bar Chart and other graphs, Histogram and the Control Chart.
Well look at an example of cause and effect diagrams which were originally known as Ishikawa or Fish bone diagrams, after the Japanese quality management expert who invented them. Used to analyse the cause and effect behind a problem to identify what caused it so you can address the problem effectively. NOTE: that the quality control measurements output from performing quality control are used as inputs for assisting in assuring quality control, so the measurements taken in controlling can help inform improving processes to remove the fault, such as in the case of our cause and effect diagram. Shows the circular nature of Project Management. Good example of continuous improvement is a story that illustrates the difference between American and Japanese car manufacturers in the 1970s. The story goes that when a car came off the production line in the US with only 3 wheels everyone raced around looking for a 4th wheel, added it on and shipped the car out the door. However if the same thing happened in a Japanese factory the entire production line was immediately shut down until the cause of the fault was located, so that never again should a car be produced with only 3 wheels. It may only be a story but it perfectly explains the difference between simply fixing defects after production and applying quality management so that the likelihood of the fault is either reduced or removed. Before progressing to the next topic encourage to look at the Readings Tab. The extensive guide to quality management with sample quality plan and inspection report on the Project Perfect site is well worth reviewing. Try doing a forum posting on your own experiences of quality failings or quality improvement processes.
Page 15 of 35
Useful Links
VIDEO: WEB: http://www.pmhut.com/quality-control-in-project-management Discussion on quality control in Project Management http://www.isixsigma.com/new-to-six-sigma/getting-started/what-six-sigma/ explanation of what Six Sigma is http://ebookbrowse.com/juran-trilogy-paper-pdf-d18594600 Juran Trilogy by Brad Lewis http://www.juran.com/our-company/ Home site for Juran Institute http://en.wikipedia.org/wiki/Total_quality_management Wikipedia explanation of Total Quality Management and its relationship to Six Sigma. http://www.projectperfect.com.au/downloads/userguides/Quality%20Management%20User%20Guide.pdf Extensive guide to quality management including sample quality plan and inspection report. http://www.evolt.org/article/The_Tao_of_Testing/20/4142/index.html Discussion on importance of testing (IT related) http://en.wikipedia.org/wiki/Ishikawa_diagram Overview of cause-and-effect diagrams. http://thequalityweb.com/cause.html Guidance on creating cause and effect diagrams http://www.projectmanagementdocs.com/project-controlling-templates/root-causeanalysis.html Root cause analysis sample and template http://www.isixsigma.com/new-to-six-sigma/getting-started/what-six-sigma/ (contains a video to explain Lean Six Sigma) http://www.youtube.com/watch?v=mVsxxoGHHWM Video on Project Management Quality Management http://www.youtube.com/watch?v=TDj0RBjYAdk Meeting quality targets to improve project results
Page 16 of 35
Topic 5: Integration processes for the PM

The last four topics have covered all executing and monitoring and controlling processes except for the three that are the primary responsibility of the Project Manager and therefore belong to the Integration knowledge area. These are: 1. 2. 3. Directing and Managing the Project Execution Monitoring and Controlling Project work Performing integrated change control
We will look at performing Integrated Change Control in Topic 6 so this topic will concentrate on the first two. Not surprisingly the Executing process is called Direct and manage project execution. It is the Process for executing all the work contained in the Project Management Plan to achieve the projects outcomes. See the process diagram for: Inputs = Project management plan, approved change requests, enterprise environmental factors, organisational process assets Tools & Techniques = Expert judgement, project management information system Outputs = Deliverables, Work performance information, change requests, Project Management Plan updates, project document updates
Note the outputs they truly reflect what the PM (and their team) work is in this process. First it is creating deliverables of the project... these arent necessarily only the product/service/or result sub-deliverables. Documentation for projects such as the Charter, Project Management Plan, Project Closure Report are all physical items that are produced as sub-deliverables of running the project, so should also be considered as such. Next we have work performance information, which are the various reports (and status updates) that the PM will produce while tracking the execution of the project. There are also change requests as during execution it is very likely the team and PM will uncover aspects that werent correctly covered in planning and therefore require a request for change to be issued. Obviously while the project is executing the PMP should also be updated to note how project baselines are playing out, plus any changes to subsidiary plans and information. Other project documentation requiring constant updating are items such as the risk register and issue log. The PM may not be personally making all these changes, but they are responsible for making sure they are performed. With the T&T note PMIS. For an example of this, if an mpp file has been created in MS Project to assist in managing the project, as mentioned earlier it can have all work activities with their sequence, duration and resources entered and it will create a Gantt Chart to act as a diagrammatic schedule baseline. When executing is started that schedule should be saved as a baseline. From this point on the PM can then add what the actual progress of the work is and add in any differences in durations that occur. MS Project can display a Tracking Gantt which will show the original schedule with the actual durations alongside providing a useful illustration of where tasks are slipping and when projected durations have gone longer or shorter than planned. The Monitoring and controlling process for Integration Management is called: Monitoring and controlling project work. This is all about tracking, measuring reviewing and regulating the actual progress of the project against the project management plan baselines, using the methods and processes that that have been planned. See the diagram for:
Page 17 of 35
Inputs = Project management plan, performance reports, enterprise environmental factors, organisational process assets Tools & Techniques = Expert judgement Outputs = change requests, Project Management Plan updates, project document updates
Again the outputs explain what the work required for this process is. As a result of comparing what is actually happening with project execution against what was contained in the plan, the PM may need to request changes. These may be changes to cope with variance analysis results, assisting to bring project work back in alignment with the plan by taking corrective actions, it may be a request for a preventative action because a risk is escalating in the project and making a change will lessen or remove its potential negative impact. It may also be a request for a defect repair, as in the performance reports and quality control activities a fault or defect may have been uncovered in a deliverable that requires it to be replaced, repaired or removed. The PM Plan updates are going to be a possible requirement whenever you are requesting changes, and as a result of attempts to control project activities. Lastly, document updates in this process include the Status Reports (or Performance reports as PMBoK calls them) to be updated, the Issue log and forecasts may be requested to evaluate how current deviations from the plan may alter the planned baselines. Earned Value Management we discussed briefly under Cost control is a tool that may be used for these. These two processes simplistically cover the day-to-day work of the PM when managing a project, but dont forget they also represent activities such as training and mentoring team staff, dealing with issues and conflicts that may arise at any time, constantly trying to balance the often conflicting constraints of scope, time, cost, quality, resources and risks, as well as probable involvement in all 42 of the management processes weve discussed. Next topic examines the last of the monitoring and controlling processes of the Execute phase of the project a process that actually runs throughout the entire project life, Integrated Change Control. On the Readings Tab at least try and look at the Slideshare show on executing and monitoring a project.
Page 18 of 35
Useful Links
VIDEO: WEB: http://project-management-knowledge.com/definitions/d/direct-and-manage-projectexecution/ Definition of, and associated hyperlinked information. http://project-management-knowledge.com/definitions/m/monitor-and-controlproject-work/ Definition of, and associated hyperlinked information. http://projectmanagementsolutionsltd.com/main/?p=1141 Overview of directing and manage project execution. http://www.slideshare.net/pajames36/managing-project-execution-presentation Good Slide Share overview of executing and monitoring a project. http://www.projectsmart.co.uk/21-project-management-success-tips.html success tips https://www.youtube.com/watch?feature=player_embedded&v=IQK4QN-NqgM (40 years of great projects) http://www.youtube.com/user/projectlessons Channel that contains lessons from history of great projects. http://www.youtube.com/watch?v=aLJH3L_XulQ Overview of directing and manage project execution
Page 19 of 35
Topic 6: Integrated change control

Change control has only one management process suggested for it, but you are likely if you are the project manager to spend quite a lot of time using it. As the person responsible for the successful execution of the project Performing Integrated Change Control you should recognise it belongs to the Integration knowledge area, as any requested change is likely to result in changes that may affect all other knowledge areas: scope, time, cost, quality, HR, communications, risk and procurement. It is a Monitoring and controlling process and may be required at any stage of the projects life, from concept to finish. All about reviewing, assessing, approving the inevitable changes that a project requires and integrating them back into the project management plan and other documents. Importantly, it is also about rejecting change requests that are not going to add value, save time or money or in any measurable way greatly improve the project. Very dangerous to see approving change requests as your only option.... just as important to block ones that are not beneficial and will only delay or complicate the project. See diagram for Inputs = Project management plan, work performance information, change requests, enterprise environmental factors, organisational process assets Tools & Techniques = Expert judgement, change control meetings Outputs = change requests status updates, PMP updates, project document updates
As with many tasks the PM is responsible for it is a good thing to not be the only person assessing and authorising change requests. We early mentioned that a way of planning for change is to appoint a Change Control Board. As you would need authorisation from the Project Sponsor to any major changes anyway, having an appointed executive or board with yourself, the sponsor and any other key decision makers should assist in making the right decisions. Dont forget that when change requests are made they need to be properly assessed. For instance changes should be evaluated for cost, time, risk, work considerations, product and technical specifications. To make an informed decision on a large change the CCB will need ot understand the impact of making the change as well as the impact of not making it. If one out ways the other by a significant margin it will simplify the decision. The Change request needs to act like a business case for the change, particularly if it is a significant one. However, you dont want your change management system to introduce barriers to implementing necessary changes. Lets say that while executing a series of tasks your team member realises thy need a piece of software that only costs $250 to purchase. There is no other product the company already has that will do the required job. Its unfortunate that it wasnt identified as a resource when estimating them, but it wasnt these things happen. However, we have to document the need and cost of purchase in the project documentation we cant just have $250 vanish out of the budget without justification! Are you really going to take this request to the CCB...? I dont think so. The executive are all busy people and they arent going to want to have to make this obvious a decision. This is where in your Change Control System it should be flagged at which levels different people have responsibility for assessing and approving changes. Depending on the size and budget for the project the change management plan may denote $4000 as the barrier between where a PM can authorise a change request and where the CCB needs to be involved. As long as the project budget also contains some contingency reserve for unexpected expenditure, it will be a simple process for the Team Member to fill in the Request and the PM to sign off on it and release the funds for purchase. Of course that will then mean some updated to project documentation for a start the resource will need adding
Page 20 of 35
to the plan. Remember, while this change request may have been initiated by a conversation with your team member, to perform integrated chg control properly you do need to get her to fill out a request just make sure for smaller changes the form isnt too onerous to fill in! A good chg management system shouldnt put people off making reasonable requests... you cant expect everything will have been thought of in planning, but it should put people off making frivolous requests because it should require a rationale to why the change is being requested. Making it clear to all stakeholders what the considerations are that will be used to assess change requests will also help prevent people submitting requests that are not going to be passed. Next topic provides an overview of the last of the projects life cycle phases: Finishing. Readings Tab at the ProjectSmart Driving Successful Change index which looks at change management both from an organisational perspective and change management within a project. Also highly recommend The Department of Health and Human Services extensive guide to change management, written in easy to understand.
Useful Links
VIDEO: WEB: http://www.projectsmart.co.uk/change-management.html an index page to a whole range of related topics on change management http://manage.techwell.com/articles/original/how-say-no Saying no to change requests. http://www.chacocanyon.com/essays/sayingno.shtml In-depth look at saying no for Project Managers. http://www.projectsmart.co.uk/rescuing-projects-in-crisis.html Tips on how to salvage a project in crisis. http://office.microsoft.com/en-us/project-help/how-to-evaluate-project-changerequests-HA010172671.aspx Good overview of change management titled How to evaluate project change requests. http://www.hhs.gov/ocio/eplc/EPLC%20Archive%20Documents/07%20%20Change%20Management%20Plan/eplc_change_management_practices_guide .pdf Comprehensive guide and sample change management practices from The Department of Health and Human Services. http://www.youtube.com/watch?v=yljkbUNTB5g Overview by Simplilearn of Monitor & Control Project Work http://www.youtube.com/watch?v=5_EwXi_SgfU Overview of Performing Integrated Change Control.
Page 21 of 35
Topic 7: The Finishing phase & getting handover right

While topics one to six in this Module have covered the Execute phase of a projects life cycle, the next two look at the wrap up of the project in the finishing phase of its life cycle. This phase often seen as the least important of the four, being Concept > Develop > Execute > Finish but is vital for capturing lessons learned to improve project management into the future for an organisation. The Closure phase does only have two processes specified for it (remember the Concept phase only had two also)? These two are: 1. 2. Close procurements and Close project or phase
From this you may conclude there isnt much to do, but a better appreciation of why the Finishing phase of a project is important can be drawn from how often we have referred to Organizational Process Assets and Expert Judgement across these modules. Organisational process assets are listed as inputs for 34 of the 42 management processes PMBoK recommends to manage a project. You should know by now that Organisational Process Assets include the archives of projects past which provide historical information anyone involved with a project can draw from to inform current projects. Without a proper finishing phase these vital company assets would not be available! Expert judgement which is listed as a key Tool & Technique for many of the processes can also often be attained by researching documentation such as lessons learned from past projects, or expert advice obtained for similar past projects that has been documented, so the value to the organisation and any projects that run after yours, of carrying out closing processes thoroughly, should not be underestimated. Lets start by looking at the Integration Management process of closing the project or phase. See the process diagram for: o o o Inputs = Project management plan, Accepted deliverables, Organisational Process Asset Tools & Techniques = Expert judgement Outputs = Final product, service or result transition, Organisational Process Asset updates
Firstly note that this process states project or phase. Remember back in Module 1 where we discussed the 5 process groups used to manage the project across its CDEF life? We noted then that if a project were particularly complex, it could be advantageous to separate it into sub-projects or phases for ease of management. I think the example we gave was that on a very unique or large project the work of running a Feasibility Study and writing a Report could be turned into a phase. This process is reflecting the fact that rather than being an entire project that is being closed, it may be the end of a phase of the project, in which case the new phase would begin with those 2 initiating processes of writing a Charter and Idd stakeholders. Also note that carrying out this process does not necessarily mean that the project handover of its final product, service or result was carried out. If the project has been beset by problems and has drifted off course, or if the environment that the project was being carried out has changed so significantly that it can no longer meet
Page 22 of 35
its initial business reason, then the sensible thing to do is for the Sponsor and any other key stakeholders that need to be consulted agree to close the project down. The figures various surveys quote on wasted $ through projects that ultimately failed are quite horrifying and so learning when it is best to terminate a project is an area that project management, as a discipline, probably needs to learn how to better evaluate. Interestingly many mining companies have built into their projects the market conditions within which they will choose to continue or close a project. Because much of their profitability is directly aligned to the current price of the ore they are mining right at the start of project initialisation cost estimates will be performed to determine the price range within which reconsideration of a projects viability needs reassessing. In mining they have become quite adept at closing projects, without entirely cancelling them, maintaining all the work and project documentation so that when the right prices again prevail the projects viability can again be assessed and a decision made to restart. However, given the assumption that the project has been run right through to the end of the project management plan, obviously the outputs from this process should be the final handover of the projects product, service or result. The project manager is responsible for checking that all this work has been completed and all 42 management processes have ended (except for closing procurements which is probably occuring in //). The organisational process asset updates is signifying that all documentation that has been created during the life of the project should be carefully archived in a manner that allows future project managers to easily search for and access the information contained. After all there is no value in archiving documentation if it is going to be extremely difficult to ever access or reference again. In the next topic we will look in more detail at the closing documentation that the PM should ensure is created in this final stage of the projects life. The Procurement closing process called Close Procurements is the last process that PMBOK list in their listing of project management processes for a project. However it is designed to help support closing the project as it will assist in verifying that all work and deliverables were accepted. See diagram for Closing procurements: o o o Inputs = Project management plan, Procurement documentation Tools & Techniques = Procurement audits, Negotiated settlements, Records management system Outputs = Closed procurements, Organisational Process Asset updates
As you can see from the tools & techniques and outputs a lot of the work for this process is administrative. Every contract that has been used in procuring needs to be checked for terms and conditions, where specific instructions may be given for closing the contract, and checked to make sure that everything the contract was supposed to deliver has been and that all outstanding payments have been made. As contracts are legally binding documents it is very important to be meticulous in closing them down according to proper procedures and meeting the contract terms, or litigation may result. Sometimes you may find that an outstanding dispute is still unsettled at the time of project closure. In this case using negotiated settlement tools such as dispute resolution or mediation is highly recommended though of course, ultimately legal action by one or the other party may result in forcing an outcome to be reached.
Page 23 of 35
Put simply, as long as your project scope was well defined in the Concept stage, stakeholder requirements correctly identified and meaningful, measurable success criteria and quality standards agreed to, finishing the project should run smoothly as the deliverables are verified and accepted as meeting the customer requirements and the needs of the project objectives. It is possible, depending on what was originally agreed on in the scope, that even after formal handover of the project deliverables has been accomplished there may be some sort of handover period defined where the SMEs from the project help support the staff where the project outcome has been implemented until they have confidence in being able to maintain and utilise the project goal for the purposes it was defined. This is particularly common in situations where the project deliverable was IT infrastructure or software. In the next topic we will have a better look at the types of procedures that can be used to help ensure efficient closure of the project, outside of the ending of the closing processes. o Before progressing to the next topic encourage to look at the articles on the Sydney Opera house. It is a very interesting project in that although at the time the project was beset by problems, and could have benefited a lot from better project management. While construction was supposed to take 4 years it dragged on for 14! The architect resigned from the project under duress and it was all generally judged to be a waste of time and money. And yet, in the intervening years from its opening in 1973 this failure of a project has ultimately been determined to be such an outstanding success in both its innovative design and its fulfilment of functionality as the premier performing arts centre for NSW that it was placed on the World Heritage List in 2007!
Useful Links
VIDEO: WEB: http://www.gids.nl/sydney/opera.html Example of how a project originally described as a failure can end up being deemed a huge success. http://www.youtube.com/watch?v=I3Wt_bHZl7U Project management close out, construction based. http://www.youtube.com/watch?v=cM1JphMzqKs Learn 7 steps to Avoid Closing Pitfalls & Be Left Holding the Project Bag by Jennifer Whitt.
Page 24 of 35
Topic 8: Project closure and reflection

Worth noting that in some cases the success of a project in meeting its goals will not be able to be evaluated until sometime after the project has been handed over. This is particularly the case with handover of a new service. The Sydney Opera house is an interesting example of where sufficient time between project end and the use of the deliverable has converted a failure into an iconic success. However, I wouldnt aim to wait this long to measure a projects success. Instead within 6 months of completion it should be possible to hold a post project review that will seek to answer the longer term success of the project now it is in use. In the meantime we will discuss why it is important that any project a company sponsors includes the writing of a Project Closure Report with lessons learned documented to pass the knowledge gained by the project team over into the assets of the company, so those who never have run a successful project can learn from your experience. Even if the project is terminated this process should be followed as obviously, the lessons learned in a failed project may be even more pertinent for those following behind. A Project Closure report needs to use the advantage of hind-sight to outline where the project could have been better managed. It needs to highlight failures and successes and document the lessons that have been learnt as well as provide recommendations for any future projects that may be run. In this way a company can build up a library of insight and knowledge about what is a very complex area project management. A project closure report is not just useful for those who follow in your path though it is also a way of making time for you and your team to self-reflect on where your weaknesses and strengths in project management lie. Self-reflection is a valuable tool for self-improvement. Too often we are not given the time or opportunity to take advantage of this important learning tool but to employ best practise for Project Management you should have the opportunity to do so by writing your Closure Report. The purposes of a Project Closure Report are: To review the successes and failures of the project Assess how successful the project has been in meeting its outcomes Outline any hand-over procedures that are needed for the transition of a project to becoming an on-going operation Provide details for any outstanding issues that need dealing with after the formal closure of the project. To document important lessons that have been learnt throughout the project To make recommendations on how the project may have been better managed Highlight best practise Formalise the closure of the project (and get sign-off that it is closed) The project title The author(s) of the report A Table of Contents Background overview of the project Reasons and methodology for closing the project Highlights and best practise
The Project Closure Report should contain:
Page 25 of 35
Assessment of performance, compared against original objectives Lessons learnt Hand-over tasks for those that will be using/managing the project deliverable Post-closure issues for anyone taking on the managing of the project deliverable Recommendations for future projects
The other feature of a proper project finish that is not referred to in PMBoK is the team, if it has been a success, should have some sort of formal wrap-up event. Just as a kick-off event marks the start of project execution, having a celebration to formally recognise the project end and give everyone involved the opportunity to celebrate their part in the projects success is an important aspect of finishing a project well... particularly if you want to be able to assemble the same valued team members for another project in the future! Before progressing to the next topic encourage to look at the Readings Tab for the article on the Microsoft website about applying the finishing touches to project closure.
Useful Links
VIDEO: WEB: http://www.nsf.gov/od/oci/CPMLL.pdf Interesting Lessons Learned report from the results of a community cyber-environment project that was intended to build a cybercommunity of earthquake engineering researchers. http://www.projectsmart.co.uk/lessons-learned.html Index page to articles about how Lessons Learned benefit project management. http://office.microsoft.com/en-us/help/project-closure-applying-the-finishing-touchesHA001127766.aspx Extensive and useful article on the benefits of closing a project well. https://www.youtube.com/watch?feature=player_embedded&v=IQK4QN-NqgM (40 years of great projects) http://www.youtube.com/watch?v=I3Wt_bHZl7U Overview of Project Management Closeout, construction based.
Page 26 of 35
Topic 9: Final recap of Project Management

In these four modules we have taken a journey that overviews most of the processes used in modern Project Management to help projects to be run effectively and efficiently, with the aim of delivering a project on time and within the agreed parameters that has a positive impact on the environment it is employed in. We started by looking at what a project is defined as (remember: unique, specific S & e, temporary, limited resources, involve uncertainty and implements change and creates a product / service or result). While we can identify projects from the beginning of history, modern Project Management processes have really only been used since about the 1950s. In the last half century a number of methodologies or standards have been established and are gaining in popularity and usage around the world rapidly. We discussed a few of these but this Subject has been based mainly on the processes recommended by the Project Management Institutes Edition 4 guide, called the Project Management Body of Knowledge. PMBoK was first published in the early 1980s and has been used as a standard in America (American National Standards Institute) as well as the Institute of Electrical and Electronics Engineers (IEEE). In just September of last year there was a new ISO standard released for Project Management that has a very close synergy with PMBoK so the processes we have discussed are in wide use all around the world. However, for effective project management what is really important is to have a methodology established within your organisation and then follow it! One of the reasons modern project management is growing in popularity is that the evidence shows the better educated staff are and more mature project management processes are within an organisation, the greater the number of successful projects will be produced. This is also why even if the only learning you do about project management is completing this SUBJECT you will have benefited yourself and your company if you work in projects. We discussed how a project can be thought of as having a life-cycle which we defined as Concept > Develop > Execute > Finish. Thinking of a project in this way helps us to think about what processes should be run at what stage of the project and how management techniques will need to alter across the projects life dependant on what stage it is at. Using PMBoK as a guide we looked at how there are many differing areas of knowledge that a Project Manager will need to become informed about to be able to effectively manage the multitude of areas that need careful consideration when managing a project. We explored the four so called core areas of knowledge which are Scope, Time, Cost and Quality management. As scope represents the actual specifics of the product, service or result the project is to produce, both in terms of what the project deliverables specifications are and what work will be needed to produce it, scope is a good starting point for planning in a project. However anyone that has been involved in a project will quickly find that these areas do not operate in isolation. While obviously the scope is the core of why the project is being run the other core areas have to be taken into consideration at the same time. The budget allowed for a project and the time and quality standards that need to be met all have to be considered when working out the scope or the natural tendency would be to aim too high for the money and time allowed. While it is easy to appreciate why scope, time, cost and quality are all areas the project will need carefully managed, the four facilitating knowledge areas are also critical to the projects success. As we discussed they were Human Resources, Communication, Risk and Procurement. When you think about it, how could a project be run if proper care and attention were not paid to the team that will run it, how effective communication between all
Page 27 of 35
the parties with vested interest in the project should be managed and how any external purchasing for the project should be handled. Risk is a knowledge area that is particularly important because of the very nature of a project. Projects are unique and involve uncertainty. If they werent they would be just part of the day to day operations of a company. Because projects contain uncertainty they also face more risks than ordinary operations, and because the project needs to run to a predefined schedule and budget unexpected events cant afford to be unplanned for. Planning for risk helps the project team deal with risks when they occur and plan how to respond. Of course there is one more knowledge area that we discussed which was the prime knowledge area for the Project Manager. While team members may need in depth knowledge of a number of the previous areas the Integration knowledge area is where the project manager draws together the threads of scope, cost, time, quality, HR, communication, risk and procurement to build the key documents for managing the project: the project charter and the project management plan. We then went on to look at the five process groups that PMBoK recommends be used to manage the project. While the knowledge areas highlight what fields you need to be informed about to manage projects, the five process groups contain all the processes used to manage these knowledge areas. They are: Initiating Planning Executing Monitoring and controlling Closing
You may mistake these five groups for the projects life cycle but where the CDEF life cycle is the phases the project goes through from its start date to its end date, these five groups of processes may be run across the life cycle or across the different phases or sub-projects the main project goal has been broken up into. However, in general the initiating processes will run during the concept phase of the project, the planning processes will be needed to manage the development phase, both executing and monitoring and controlling processes will be used while the project is in its execute phase and the closing processes will be used to manage the finish of the projects life. The other difference between the projects life cycle and the five process groups is while the project is never going to go from its execution phase back to its concept phase, the five management process groups can be iterative and in fact often need to be as because projects involve uncertainty the team is bound to uncover new areas of work required or changes to resources, time frames and costs as the project evolves through its execution. This means that while executing the work of the project, the manager may need to return to planning processes which will then involve more executing and monitoring and controlling processes to be carried out. Sometimes the manger may even need to reemploy some of the initiating processes such as identifying new stakeholders and making a retrospective though authorised change - to the project charter. Another area important to effective management of projects that we have covered are constraints. We discussed how traditionally four constraints have been identified that apply to all projects and how PMBoK Ed4 now identifies six. The four main ones were: Scope Cost / Budget Time / Duration
Page 28 of 35
Quality
These four have traditionally been identified because it is easy to see how they impact on each other. The more complex the scope, the more money and time will be needed and the more important the quality standards will be. The less time there is available to a project then the more likely you will need to restrict the scope to the bare essentials, but more money may be required to outsource some work, or employ more staff to speed up its execution. If there are very tight time frames to be met the quality requirements need to be made very specific as frequently less time means lower quality. Depending on the project goal this may be acceptable. However if the project involves safety to individuals, or a function that will be critical to the businesses survival then attaining sufficient quality standards may involve more time and cost allowances to ensure this. Because these factors are so dependent on each other they can be used as a way of explaining to a project sponsor or client how a requested change is likely to affect more than one aspect of the project. A constant danger to running projects successfully is having a client wanting to constantly add to the projects scope. Using the common constraints to explain how a change to scope has an impact on the other areas will help them to understand why the change should not be made or of it is agreed to why it will require more time and money to authorised for it to be included.
The Edition 4 version of PMBoK lists:

Scope Quality Schedule Budget Resources and Risk
as project constraints that need balancing, and we discussed why these additional factors are also worthy of careful consideration and managing. In the section on the concept phase of a projects life cycle we looked at how important it was to carefully assess the business case and feasibility of a project before it is started. There have been countless billions wasted world-wide on projects that have either been closed down or which have delivered results that were no longer deemed useful to the organisation they were implemented in. while there are many definitions of success and failure in a project these two are I think the main reasons a project should be deemed a failure. Running a project that rambles endlessly on to the point a realisation is made that it never is going to end so it has to be closed down is a definite failure. In my opinion just as definite a failure is running a project that delivers the agreed scope on time and within budget but that the end result of is a product, service or result that is not used or is in fact a detriment to the organisation it was implemented for. While balancing scope, quality, schedule, budget, resources and risk to deliver the agreed goal on time and within budget are all ways success of a project can be measured ultimately the main gauge will be the satisfaction of the end user of the delivered goal. It is surprising how many projects that have failed on these specific measures have in the long term been considered great successes the Sydney Opera house is a perfect Australian example! In the concept phase once the goal had been clearly identified and evaluated by upper management and resources authorised for the project to be progressed we discussed how the first of the PMBoK management processes should be employed, which was to develop a Project Charter. We looked at regardless of whether appointed Project Manager or the Project Sponsor wrote this document what was really important was: It outlined as clearly as possible the project objectives and deliverables
Page 29 of 35
It identified how the success of the project would be measured It enables a clear delegation of authority for the Project Manager to begin expending money and resources to plan the project It signifies the support of the sponsor / client / project manager for the project to be transitioned to the development phase of its life cycle.
The more accurately and specifically the Project Charter has been drafted and agreed to, the more smoothly all further work on the project will progress and the more likely a successful handover at the end of the project will be. It provides a key framework for all stakeholders to refer back to throughout - and as long as at the project handover that framework is met there should be agreement all around. In the development phase we talked about the planning processes required there were 20 in all to plan out the scope, time, cost, quality, human resources, communication, risk and procurement of the project. We talked about how the planning needs involvement from the team to be comprehensive and accurate enough. We looked at how each of these processes used inputs, tools and techniques to provide outputs that were then integrated by the project manager in to the go-to document for executing the project, which is the Project Management Plan. This document is best thought of as an over-arching document that provides an interface to all the relevant plans for managing the project through its execution. It is also a dynamic document that should constantly be updated as the project progresses with the latest information so that any stakeholder at any stage can gather a clear idea of the projects progress from reviewing it. It also provides the framework for how all the knowledge areas should be executed and managed, including monitoring and controlling plus how to make change requests and integrate them if agreed. We looked at why it is important to plan for change in a project. References to iterative processes and rolling wave method were made to help clarify that as a project goes through its planning and execution life cycle phases naturally a better understanding of the details of the project will be achieved which means that it is extremely likely the team will uncover areas that were missed from the initial plans. The most important thing about change in a project is not that it happens it will it is that there is a formal process set up to manage change. By making sure that requests for change are formally made so that they can be properly assessed as to whether there is value in integrating them and an accurate appreciation of the flow on effects from integrating them, sensible decisions can be made on what changes should be agreed to and which should not. Without careful management of change which is one of the key responsibilities of the Project Manager in the Integration knowledge area projects can be needlessly and continuously changed which ultimately will almost ensure you go over budget and time and potentially deliver a very different deliverable to the one originally defined in the Charter. Not only can this cost money time and waste resources it is bound to frustrate and confuse everyone involved with the project, so good change control management is yet another key area the project manager needs to be well skilled in. For the execution of the project to occur smoothly once the project management plan has been set up and authorised, there are a total of 18 processes from the monitoring & controlling and executing process groups that can be used. If the Plan has been well developed and is used as a benchmark for measuring against throughout, the Execute phase should simply follow the Plan, with only necessary changes integrated into it. Finally smooth the transition to operation of the project in the Finish phase by properly applying the closing project and procurements processes and supporting handover of deliverables. Developing a Closure Report to allow for reflection and documentation of lessons learned and archiving all project documentation will add to the knowledge bank of
Page 30 of 35
the organisation (and its organisational process assets) and will benefit all future projects to be run. To manage projects well there needs to be a commitment by the performing organisation to allow time and resources to be allocated to concept and develop phases of the projects life, as the better this is done the better execution will run and the higher the likelihood of successful handover. While this has been a brief overview of project management investigating all the videos and web links to readings in the resource tabs for each Topic will allow further expansion of your understanding of Project Management.
Useful Links
VIDEO: WEB: http://www.brighthubpm.com/project-planning/65203-the-project-lifecycle/?cid=parsely_rec Overview of the entire project life cycle. Max's Project Management Wisdom - Max Wideman was the author of the first PMBOK guide and has dedicated a lot of his time and effort to creating a wealth of information about Project Management, accessible for free from this site. Australian Institute of Project Management (AIPM) - the Australian organisation representing Project Management professionals in Australia, formed in 1976. Projects at Work - American resource for Project Managers, founded 2001 and "The online destination for leading-edge approaches and perspectives in program, portfolio, and project management. (their description)". Project Smart - British resource, free site launched 2000, with many Project Management resources. http://en.wikipedia.org/wiki/List_of_project_management_topics http://www.maxwideman.com/pm_101/intro.htm is an easy to read overview by Max Wideman about projects and project management. http://www.maxwideman.com/papers/framework/intro.htm is a more sophisticated explanation of project management by Mr Wideman. http://www.businessballs.com/project.htm Short overview of a whole lot of project techniques and tools. https://www.youtube.com/watch?feature=player_embedded&v=IQK4QN-NqgM (40 years of great projects) https://www.youtube.com/watch?v=4n0kVSxV8-8 (What is Project Management in simple outline) https://www.youtube.com/watch?feature=player_embedded&v=r5qFLd1u0XQ (An Idiots Guide to Project Management) The basics. http://www.youtube.com/watch?v=GcR-wpSzr4Y A simple 5 step process example of how to manage a project: why, what, how, who, tracking. http://www.youtube.com/watch?v=9LSnINglkQA Simple, cartoon overview of Project Management. http://www.youtube.com/user/projectlessons Channel that contains lessons from history of great projects.
Page 31 of 35
Page 32 of 35
Topic 10: Where to from here...

Were hopeful by now you will feel that you have learnt a whole heap about how to manage projects! However, as we said right back at the start, this is only an overview! It should have given you a pretty good idea of how much work needs to go into managing projects in a structured and formal way and highlighted some of the traps that projects fall into when these processes are not properly employed. It should also have provided you with enough of a taster to assess whether project management is a discipline you wish to be employed in. Remember, most of the most interesting work in the world revolves around running projects! However if you are serious about gaining a thorough understanding of project management please dont think this MOOC has provided it. Educationally you have a number of options. Use as pathway to a Cert IV in PM. Under the Australian Qualifications Framework the cert 4 covers 8 units: Scope, Time, Cost, Quality, Human Resources, Communications, Risk and Procurement. Use as pathway to the Diploma of PM, which comprises 9 units: Scope, Time, Cost, Quality, Human Resources, Communications, Risk, Procurement and Integration. They may seem pretty familiar after this MOOC these qualifications basically cover project management using the PMBoK knowledge areas. The Cert IV doesnt include integration management because it is intended for those students who work or wish to work in projects but are not aiming to be project managers. The Diploma is intended for those wanting to pursue a career so PM and so obviously needs to cover Integration management. Being at different qualification levels obviously the standard of work required for the Diploma is at a higher level than the Cert IV, so even those wishing to pursue PM as a career may prefer to start at the Cert IV level as a slightly softer lead in. Be aware that if you are applying for either of these qualifications you should have access to a workplace and preferably one that runs projects. As a Diploma would normally allow you to claim exemptions in related Bachelor degrees the standard of work required is at a higher education level. In other words you would be expected to have good literacy and communication skills and know how to research and reference appropriately. Mind you these skills are also necessary for being a Project Manager! Depending on your current level of formal education you may choose to progress from this MOOC straight to a university course such as a Bachelor of Business that will also cover many aspects of managing projects at a greater depth, or a Bachelor of Project Management. Degrees in Project Management are relatively new but more are being made available through Universities. These obviously provide a higher education qualification than a Certificate IV or Diploma. You can also pursue one of the many popular industry based courses. For instance the PMI authors of PMBOK provide links to accredited courses in Project Management and run a range of project management certification exams. One of the most popular certifications is the Project Management Professional - or PMP. Prince2 also has a qualification framework that enables successful students to claim Prince2 Practitioner status, amongst others. If wishing to seek employment in Project Management most team members are first and foremost specialists in a technical area in an organisation that runs projects, so to be a project team member have good skills in your discipline of choice and look out for employment opportunities within organisations that run projects. Let them know you are interested in being involved in Project work. Tell them you have done
Page 33 of 35
a MOOC which gave you a background of what modern project management is. Obviously obtaining a qualification such as the Certificate IV would be a desirable entry on your resume! If you want to be a Project Manager then you really need to enrol in more specific training such as the Diploma or above. Having a qualification by itself wont ensure you are employed as a Project Manager. Really it should be a value add to a technical proficiency such as IT, Business, Engineering, Construction etc. As most projects involve a fair amount of money and resources to be allocated you can understand why most organisations would be reluctant to hire a green Project Manager, even with a Bachelor Degree. Your best method for pursuing this career is working in project environments as a team member, promoting yourself as a potential project manager by communicating with the people that count and backing it up by enrolling in and studying formal project management. Looking for a Project Manager mentor within an organisation can be really useful and then look for your opportunities and argue to be given a chance. If you can demonstrate to a company that you possess the necessary skills to be a Project Manager, have the qualifications to back this up, and be persistent chances are you will get your chance! There are more and more companies looking for more and more Project Managers and for all the emphasis put on having experience first, we all know that only happens by being given the first chance! Thanks for spending your time with me on this Subject and good luck with whatever pathway you choose to follow! As always, do have a look at the Readings for some further information you can explore on possible pathways to further education in Project Management.
Page 34 of 35
Useful Links
VIDEO: WEB: http://www.open.edu.au/courses/business/provider-pow Page listing Certificate IV and Diploma of Project Management information. http://www.open.edu.au/courses/business/polytechnic-west-formerly-swan-tafediploma-of-project-management--pow-pmt-dpl-2013 Specific information on the Diploma of Project Management http://www.open.edu.au/courses/business/polytechnic-west-formerly-swan-tafecertificate-iv-in-project-management--pow-pmt-civ-2013 Specific information on the Certificate IV of Project Management http://www.open.edu.au/courses/business/university-of-south-australia-graduatecertificate-in-project-management--usa-pjm-gce-2013 Specific information on the Graduate Diploma of Project Management http://www.pmi.org/Certification.aspx Page explaining PMIs Certification options. http://www.prince-officialsite.com/Qualifications/QualificationScheme.aspx Page explaining the official Prince2 Qualification scheme. http://www.youtube.com/watch?v=pXdKUY9d-4A YouTube video about what PMP certification is about http://www.youtube.com/watch?v=YK8JJu9Ejvg More in depth YouTube video about PMP certification and how to study for it http://www.youtube.com/watch?v=e5-TriVtzlI Video about obtaining Prince2 certification http://www.youtube.com/user/PMstudyLessons?feature=watch Series of videos about benefits of Prince2 Practitioner certification
Page 35 of 35

Project Management Module 4 Script

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Project Management Module 4 Script

Hochgeladen von

Copyright:

Verfügbare Formate

Project Management Principles: Execute & Finish Phases - Module 4

Topic 1: The Execute or doing phase overview

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Topic 2: H/R and Communications management

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Outputs are: Organisational process assets updates.

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Topic 3: Monitoring and controlling execution

The Verification of scope process requires (as illustrated)

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Topic 4: Quality auditing, control and continuous improvement

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Topic 5: Integration processes for the PM

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Topic 6: Integrated change control

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Topic 7: The Finishing phase & getting handover right

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Topic 8: Project closure and reflection

The Project Closure Report should contain:

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Topic 9: Final recap of Project Management

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

The Edition 4 version of PMBoK lists:

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Topic 10: Where to from here...

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Project Management Principles: Execute & Finish Phases - Module 4

Das könnte Ihnen auch gefallen