CompTIA Project+ PK0-003

Project Closure

by Steve Caseley

Start your 7-day free trial today.

This video is only available to subscribers.

A free trial includes:

  • Unlimited 24/7 access to our entire IT training video library.
  • Ability to train on the go with our mobile website and iOS/Android apps.
  • Note-taking, bookmarking, speed control, and closed captioning features.

What is Project Management

Project+ and how to prepare for the exam

Pre-Project Setup

Project Planning

Prepare Scope Statement

Create WBS and WBS Dictionary

Define Change Management Process

Develop Project Schedule and Resources and Roles

PERT/GANTT/CPM and Schedule Compression

Communications Management Plan

Risk Management Plan

Quality Management Plan

Cost Management Plan

Procurement Management Plan

Transition and Project Management Plan

Human Resource Management

Project Governance

Project Tracking

Project Change Management

Project Risk Management

Project Quality Management

Project Delivery Management

Earned Value Management

Project Communication Management

Project Closure

00:00:00 - Congratulations! You made it to the last nugget in the series
00:00:03 - and the last component of project plus certification and the
00:00:09 - last component of project management and that is project closure.
00:00:15 - Project closure has three components: 5.1, Formal Project cClosure;
00:00:21 - 5.2, Review of the Different types of Closure and the Actions
00:00:25 - to be taken for that and 5.3 production of the final formal closing
00:00:32 - document. The full definition of each of these segments from
00:00:36 - CompTIA is 5.1, explaining importance and benefits of formal
00:00:41 - project closure; 5.2, identify circumstances in which project
00:00:47 - phase closure might occur and identify steps to take when closure
00:00:51 - occurs and finally 5.3, identify the components and purpose of
00:00:57 - closing documentation. So
00:01:00 - let's see what formal project closure is all about. Project closure
00:01:05 - should be a formal process, project closure should not be the
00:01:09 - default of project activity.
00:01:12 - Sometimes that is what happens with projects is we simply do
00:01:16 - the last task in the WBS and people stop working on it and therefore
00:01:22 - the projects closed. Taken that attitude to project closure is
00:01:26 - doing your organization no value because we are not going to
00:01:31 - gain the benefits of doing proper project closure meaning harvesting
00:01:36 - reusable artifact, creating lessons learned, doing a project
00:01:41 - course modem and
00:01:43 - basically learning from our mistakes in improving our project
00:01:47 - management processes. So project closure should not be something
00:01:51 - that happens by accident as CompTIA suggest project closure should
00:01:56 - be a formal dedicated, conscious effort on behalf of the project
00:02:01 - management team. Now the good news is project closure should
00:02:05 - not take a lot of time. Project closure should happen in a period
00:02:10 - of days or even worse case weeks. You may have an 1824
00:02:16 - month projects but should still be able to wrap up project closure
00:02:20 - in about
00:02:22 - a week. Key critical activities happen in project closure, but
00:02:26 - there is not a lot.
00:02:29 - The first aspect of project closure is project handover. Turning
00:02:33 - an order,
00:02:36 - run the code,
00:02:39 - make it production. And
00:02:43 - there is a number of activities associated with project handover
00:02:46 - that we will discuss in just a few moments
00:02:50 - probably not going to surprise you to see this aspect for me
00:02:54 - in project closure. This is one area that I believe getting that
00:02:59 - formal acceptance, getting that signature on a piece of paper
00:03:03 - is key,
00:03:05 - and we will talk about that more in a few minutes. Doing a project
00:03:08 - review, what worked?
00:03:13 - What didn't work?
00:03:16 - What should we repeat? What should we never repeat? What lessons
00:03:20 - should we learn?
00:03:22 - Improving your organizational project delivery, project management
00:03:27 - capacity is what completing a project review is all about and
00:03:31 - we will document that in the project closing document that will
00:03:35 - discuss later in this nugget. Contract
00:03:39 - closure, if you have third party contractors vendors involved
00:03:44 - in your project, we owe it to our vendors to go through a degree
00:03:48 - of formal contact closure. They are going to want to get paid
00:03:52 - for their services. They are going to want to insure proper processes
00:03:56 - or in place to release any hold back and any warranty support
00:04:01 - payments that they are going to get as result of project closure.
00:04:04 - Pay some time and attention to doing proper project closure and
00:04:08 - again include contract closure in your project review. What is
00:04:13 - our impression of working with this vendor? Would we work with
00:04:17 - them again or were they so much trouble we would recommend never
00:04:21 - working with this vendor again and obviously an aspect to formal
00:04:25 - project closure is releasing the project resources back to wherever
00:04:30 - they came from in your organization? So
00:04:33 - let's deal with each of these in a little more detail. Many organizations
00:04:39 - would consider what I am calling a project closure activity which
00:04:42 - is project handover part of implementation
00:04:49 - and therefore part of the project
00:04:52 - not closure and
00:04:56 - that is fine, as long as it is get done.
00:05:00 - My concern about treating all of these project handover closing
00:05:05 - activities as part of implementation and not closure is we may
00:05:10 - focus only on the first two or probably the first three of these
00:05:16 - and may pay lesser attention to the last one. Typically, training
00:05:22 - will be considered as part of a project implementation activity
00:05:26 - and part of standard project delivery. Fine,
00:05:29 - we just need to make sure it happens.
00:05:33 - Support for operations, training for operations, operationalization
00:05:38 - of the project parameters
00:05:41 - often again decode the run books, the
00:05:47 - run logs, the back streams whatever word is appropriate for the
00:05:52 - technology environment in which your project was developed. Often
00:05:56 - the exact format and style and nature of those batch processes
00:06:02 - that we use in projects during development may not be 100% suitable
00:06:07 - for operations. We cut things into smaller pieces. We put more
00:06:12 - configuration, more options into our run books during project
00:06:17 - development and project testing to allow us to control things,
00:06:21 - to be able to influence the execution a little more, by the time
00:06:25 - we turn it over operations a lot of that optionality, a lot of
00:06:30 - that customization that we like to have control over during project
00:06:34 - delivery, we don't want to have the ability for operators to
00:06:38 - influence so again there may be a degree of operationalization
00:06:43 - that is needed as part of the project. If you do that as part
00:06:47 - of implementation, great, just make sure it happens. Putting
00:06:52 - the processes in place for support
00:06:56 - for the first day,
00:06:58 - for the first week,
00:07:01 - for the first month
00:07:03 - you may call this warranty support,
00:07:07 - which is often the case if the project is delivered by an external
00:07:11 - agent into your organization,
00:07:15 - but what happens if the project is delivered by in house resources
00:07:19 - and the project resources are all released on the day of implementation
00:07:24 - and there is no resources left behind to do project support for
00:07:29 - the first day. Now you are probably saying, "Steve, there is
00:07:32 - no project manager in the world
00:07:35 - stupid enough to release all of his project resources the day
00:07:39 - of implementation and not everybody around for support and I
00:07:42 - think you are right." We keep them around for the first day and
00:07:46 - we probably keep them around for the first week, but what bout
00:07:49 - the first month, after you have had a week of solid error free
00:07:54 - operations, do we still have enough of our team in reserve to
00:08:01 - deal with the hiccups and the bumps that happen after the first
00:08:04 - biweekly batch process that hadn't run before or after the first
00:08:09 - monthly batch process that hadn't run before. Just again, consideration,
00:08:14 - again you may include all of this as part of Standard implementation.
00:08:18 - Great! Let's just make sure it happens. Similar for maintenance,
00:08:22 - we worried about the support, the warranty aspects, what about
00:08:26 - the ongoing maintenance? Who is going to care
00:08:30 - and feed? Who is going to keep the lights on
00:08:36 - depending on how your organization is structured, the current
00:08:40 - feeding, the operations of the system may be very different than
00:08:46 - the support operations. The people who run the batch jobs may
00:08:50 - work for a very different department than the people who fix
00:08:53 - the bumps in the nugget. What
00:08:55 - processes are in place for the ongoing care and feeding? What
00:08:59 - processes are in place for the bumps in the night? Again, may
00:09:04 - all be part of implementation, great and let's just insure as
00:09:08 - part of project handover they have all been considered.
00:09:13 - And part of project closure is formal project acceptance. This
00:09:16 - is my last time to get on my soap box and say I believe we need
00:09:22 - to have a formal acceptance document and you heard me on the
00:09:25 - soap box enough times, I am not going to repeat the soap box,
00:09:29 - but as a project winds down there should be some degree of formality
00:09:35 - to saying, "Yes, Steve and his team has done a wonderful job.
00:09:42 - I think the results or I will confirm that the results are exactly
00:09:46 - what the project was taken on to do, let's give Steve and his
00:09:50 - team a little bit of formal recognition." I
00:09:54 - already talked briefly about the concept of warranty support.
00:09:58 - Warranty support in the last discussion on project handover was
00:10:02 - more focused on what happens if it is in an internal team make
00:10:06 - sure have got enough stay back from the project to do the ongoing
00:10:09 - care and support if the project was delivered under a third party
00:10:13 - relationship whether you were managing third party vendor supplying
00:10:17 - to your project or whether you were a third party vendor supplying
00:10:21 - to your customer organization. What processes are in place to
00:10:26 - insure effective warranty support between organizations? Do
00:10:31 - we have the confidence that our vendors have enough people left
00:10:35 - behind, enough stay backs to provide the right levels of warranty
00:10:39 - support? Do we have pager numbers, do we have call out processes
00:10:44 - so that if something goes bump in the middle of the night, we
00:10:47 - know how to fix it? What processes are in place for the warranty
00:10:50 - support? And sometimes
00:10:55 - as much as I would love to get the accolades and the pat on the
00:10:57 - back and says, "Steve and his team has done a wonderful job sometimes
00:11:02 - those conditional acceptances
00:11:04 - based on the evidence that we have seen the project seems to
00:11:08 - be performing appropriately." We have seen it operating for 5
00:11:13 - days in operations. We have seen it run a weekend process. All
00:11:19 - is good, but we haven't seen it running monthly process in production.
00:11:24 - We haven't seen it running quarterly process in production and
00:11:27 - we haven't seen it run a yearly process in production so sometimes
00:11:32 - the best you are going to get is some form of conditional acceptance.
00:11:36 - We love it. It is beautiful. We have now reason to believe there
00:11:39 - is anything wrong, but we still need some hold back. We still
00:11:43 - need some way to call back the vendors if the monthly process
00:11:49 - fails, if the quarterly process fails. You are up the end of
00:11:52 - your process fails. All
00:11:54 - again at things that need to be considered as we are dealing
00:11:58 - with that formal project closure, in that formal acceptance and
00:12:02 - the handover processes.
00:12:05 - In my humble opinion one of the most important aspects for project
00:12:10 - closure is the concept of the project review. Improving,
00:12:17 - the organizational capacity
00:12:22 - to deliver
00:12:25 - future projects
00:12:30 - better by conducting formal project reviews, by gathering lessons
00:12:39 - learned in this project we expected the business to be able to
00:12:46 - participate in workshops.
00:12:50 - The lesson learned is the business is running at full capacity,
00:12:55 - people have 100% or probably 110% full time, day time jobs. They
00:13:01 - don't have the time to participate in workshops the way we expected
00:13:05 - them too. That is lessons learned. We are going to have to find
00:13:09 - some way to deal with workshop participation whether we have
00:13:14 - to bring in temps or whatever. I am not going to try to answer
00:13:17 - the lessons learned, but if we harvest lessons learned we are
00:13:21 - going to improve our organizational capacity to deliver future
00:13:25 - projects better. We need to archive
00:13:29 - project deliverables.
00:13:32 - This project produced a wonderful system test
00:13:39 - plan. Everyone who reviewed, who experienced the system test
00:13:44 - plan during project execution were in awe of this piece of art
00:13:50 - that the project produced. We
00:13:53 - need to archive that system test plan. We need to put it somewhere
00:13:57 - that it can be reused.
00:14:02 - We need to put it into the best practices library and we need
00:14:08 - to formally harvest that project
00:14:11 - archive, we need to formally harvest that reusable document and
00:14:16 - we need to formally put it in some place that it can be found
00:14:20 - for the future. My experience is if we don't formalize this process
00:14:25 - everybody says, "Yes, Steve's project, best system test plan
00:14:28 - I have ever produced. We are going to have to reuse that." And
00:14:32 - all the best intentions are-we are going to have to reuse that,
00:14:35 - but we didn't formalize the process, that system test plan was
00:14:39 - deliberately left behind on server x, everybody knows that is
00:14:43 - on server x and they will go get it off server x if they never
00:14:47 - need to reuse it. Six months after the project is completed
00:14:52 - server x is destined for removal. It is an old server. It is
00:14:57 - not an efficient server. They want to take it out of operations
00:15:01 - and the word goes around anybody running anything on System X.
00:15:06 - System X seems to be running at very low capacity, anyone, anyone?
00:15:10 - Good, just what we thought. System X is not being actively used,
00:15:14 - let's turn it off.
00:15:17 - There went that most wonderful system test plan in the world.
00:15:22 - System X got turned off,
00:15:25 - no backups, no archives, we asked the questions, it wasn't being
00:15:29 - used and it is gone. Formalize
00:15:33 - the lessons learned, formalize the project archives, formalize
00:15:37 - the creation of a project best practices library and you are
00:15:41 - going to improve your organizational capacity to deliver future
00:15:45 - projects better. We are going to repeat the things that worked.
00:15:49 - We are going to improve we are going to fix or we are going to
00:15:52 - never do the things that didn't work and we are going to find
00:15:57 - reusable artifacts,
00:16:00 - documents, processes, pieces of code. You name it, there is going
00:16:05 - to be reusable components in our projects. We need to get them
00:16:09 - off of the project servers and we need to get them into some
00:16:13 - formal best practices library where they will have continued
00:16:17 - go forward, useful lives.
00:16:22 - In contract closure for any third party relationships that you
00:16:26 - had in place for the project, if not already closed, because
00:16:30 - often subcontractors third party vendors contracts maybe close
00:16:35 - interim throughout the delivery of the project, we have the delivery
00:16:38 - of the project. It is an input to development and their contract
00:16:42 - is done, but if you have vendor contract set, continue until
00:16:46 - the day we go live and the first we could support. I
00:16:50 - believe we need to spend some special attention to formal contract
00:16:54 - closure for a third party relationships during project closing
00:16:59 - and that is because after the week of project closure and that
00:17:05 - limited warranty support period the project team is truly disbanded
00:17:10 - and the project team is truly released back to the organization
00:17:15 - including myself the project manager that no one is around and
00:17:19 - here we have a vendor sitting out there under agreement that
00:17:23 - has a 30 or 60 day payment hold back
00:17:29 - to insure nothing else goes bump in the middle of the night. 60
00:17:33 - days goes by, the vendor is saying, "Phone call hasn't happened,
00:17:37 - I guess Steve is happy with my project. Here is my final invoice,
00:17:42 - send it in to accounts payable." Accounts payable gets the invoice
00:17:45 - saying, "Why did we get this invoice? What is this invoice for?"
00:17:51 - Sits in someone's desk they don't understand, "Why, the invoice
00:17:54 - command? They don't understand which project it is for so it
00:17:56 - sits on someone's desk until such time as they have time to deal
00:17:59 - with it. They do a little research and they say, "Oh yeah, that
00:18:03 - was with Steve's project, but he is no longer with us. He is
00:18:07 - gone somewhere. Hmm, I don't know if we should pay this or not." And
00:18:11 - that valid contract from a 60 day hold back is going to spin
00:18:17 - around and around the organization for often weeks or even months
00:18:22 - before somebody finally realizes, "Oh that is the whole back
00:18:26 - invoice, yes, we should pay it." In my humble opinion, we owe
00:18:30 - it to our vendors as we are leaving the project to send emails
00:18:35 - to accounts payable saying, "Hi, it is Steve,
00:18:38 - project is winding down. I will be off the project in a matter
00:18:43 - of days. I want to inform you that there are three vendors with
00:18:48 - hold back closets. You can expect to receive an invoice for the
00:18:53 - amount of x in approximately 30 days. I have another vendor
00:18:58 - who has a 60-day hold back clause. You should be expecting to
00:19:02 - receive an invoice in the amount of why in 60 days and the second
00:19:07 - vendor another invoice for Zed again in 60 days. Assuming you
00:19:14 - don't hear from me between now and then i.e there have been no
00:19:17 - delivery challenges. This is my pre-authorization to you to pay
00:19:21 - it so make sure for the sake of your vendors that you have proper
00:19:27 - processes in place that you have payment terms in place to support
00:19:32 - their terms and I am not saying this simply because I have done
00:19:37 - a lot of work as a third party vendor and I have had issues getting
00:19:41 - my invoices paid, which is true, but I am saying this for the
00:19:45 - sake of your organization. You
00:19:48 - dealt with vendor x. You were very satisfied they did a great
00:19:52 - job for you on the project. You would love to do work with them
00:19:55 - again, but guess what. If they had a 60-day hold back and it
00:20:01 - took them another 60 days to get payment for that 60 day hold
00:20:04 - back they are probably going to think twice or three or 4 times
00:20:08 - before they respond to another request from your organization
00:20:11 - say, "Yeah, Steve's company was pretty good to work for. Very
00:20:15 - happy during project delivery, but you know what that final payment,
00:20:19 - the pain that took us to get that final payment out of Steve's
00:20:22 - company. I am not sure it is worth dealing with them" and they
00:20:25 - decide to know bit. So again, make sure we have proper processes
00:20:30 - in place to deal with the terms and conditions, not just hold
00:20:34 - back, not just payments, but warranty support.
00:20:41 - Again, Steve may get reassigned to another project two days after
00:20:45 - project closure is done, 10 days after project closure is done
00:20:49 - a warranty support issue comes up. Make sure you have published
00:20:55 - all the numbers,
00:20:58 - all the pager numbers, all the cell phone numbers, all the email
00:21:01 - numbers, all the management exclamation points so that again
00:21:05 - your organization is protected with any residual need to deal
00:21:11 - with these vendors post project closure. And
00:21:17 - with those standard steps for formal project closure behind us,
00:21:21 - it is time to step back and say, but not all project closures
00:21:25 - are the same. There are different types of project closures.
00:21:29 - There are interim project closures. We have phase closures. We
00:21:34 - have stage closures. We have component closures.
00:21:39 - What are phases, stages components? They are interim steps in
00:21:44 - our project. Remember we want to do incremental development.
00:21:48 - We want to develop our project plan for the next phase of our
00:21:52 - project. We want to do that phase of the project and then we
00:21:56 - are going to do a milestone, a checkpoint, a stage gate. Does
00:22:01 - it make sense to continue the project?
00:22:04 - That is part of a phase closure or a stage completion.
00:22:10 - It is a check point.
00:22:15 - Are we going to release resources at the end of a stage completion?
00:22:20 - Well we may release a couple of resources because we no longer
00:22:23 - need a full suite of analysts and we may bring in new resources
00:22:27 - because we need to bring in designers, but I would not call that
00:22:31 - the release of the resources, I would call that standard project
00:22:34 - resourcing. Are we going to go for acceptance? Absolutely, at
00:22:39 - least Steve is going to go for acceptance. He is going to get
00:22:42 - acceptance of his check point. I have completed analysis, please
00:22:46 - sing off.
00:22:48 - Are we going to close vendor contracts? Maybe if our vendor was
00:22:53 - only engaged to do analysis.
00:22:56 - Are we going to? So we need to sit back and look at all of those
00:22:59 - steps I just discussed with formal project closure and determine
00:23:03 - are they relevant? I would suggest most of them are with the
00:23:07 - exception of releasing all of the resources, but doing lessons
00:23:13 - learned? Absolutely, do your lessons learned at your stage completion
00:23:19 - while it is still fresh in your brain. If you wait for 10 months
00:23:23 - when the project is done to harvest the lessons learned from
00:23:27 - analysis you forgotten all the lessons learned from analysis
00:23:32 - and you have lost the opportunity to maybe make some process
00:23:36 - improvement based on your analysis lessons learned to eliminate
00:23:40 - some of the errors in design. Or you lost the opportunity to
00:23:44 - influence other projects just beginning analysis to learn from
00:23:48 - the benefit from your project and you haven't gained the opportunity
00:23:53 - to put all of those reusable artifacts into your artifact library,
00:23:57 - your re-used library for other projects to use so often most
00:24:03 - of the concepts of
00:24:05 - formal project closure need to apply with some common sense to
00:24:10 - a stage completion or a phase completion.
00:24:14 - To me a component completion is more often third party vendor
00:24:19 - related. The vendor has completed the component of their project
00:24:24 - that they are obligated to deliver so we will go through the
00:24:27 - formal contract closure. We will put the wheels in place to
00:24:32 - close the relationship with the vendor. We will put the wheels
00:24:35 - in place to insure ongoing payment of any hold backs to the vendor
00:24:39 - and we will put the wheels in place to insure the warranty support
00:24:43 - from that vendors put in play while the rest of our project goes
00:24:47 - on. Project completion, absolutely, all of the steps we just
00:24:52 - discussed would apply and let's talk about this nasty one down
00:24:57 - here, project cancellation, my project is cancelled and I didn't
00:25:03 - implement. The project could be cancelled for any of thousands
00:25:08 - of reasons, business model change,
00:25:11 - business sponsor changed,
00:25:14 - business environment changed, economic situation changed,
00:25:19 - projects will be cancelled for all kinds of reasons that are
00:25:22 - outside of the project realm and that is good. The business doesn't
00:25:27 - need the project anymore, let's not waste any money. Let's take
00:25:30 - advantage of those check points, of those stage gates and say,
00:25:33 - "Yup, it is time to cancel the project. It doesn't make sense
00:25:36 - anymore." And sometimes projects will be cancelled simply because
00:25:41 - it is not working, the project is so far over budget, the project
00:25:45 - is so far over schedule. The current estimate to complete is
00:25:48 - so unrealistic that the business case is cancelled, let's cancel
00:25:52 - it. Do we just hang our head in shame during a project cancellation
00:25:56 - and say, "I am so sorry, I worked on this project. I wish I could
00:26:00 - have made it better, darn." No, we go through formal project
00:26:05 - closure as a matter of fact I would say every step of formal
00:26:09 - project closure needs to be applied in a project cancellation
00:26:12 - especially the lessons learned. Why was this project cancelled?
00:26:17 - What could we have done to prevent this project from being cancelled
00:26:20 - and so on? So recognizing that we are going to have interim closures,
00:26:27 - but these interim closures don't need to go through very much
00:26:30 - the same process, lessons, learned, reusable library.
00:26:35 - Contract closure,
00:26:38 - acceptance still apply, we re going to have traditional closure
00:26:44 - and we are going to have cancellations. But again, virtually
00:26:47 - everything we talked about in the formal project closure will
00:26:50 - apply with some exceptions with some common sense is discussed. And
00:26:56 - with all of those closing activities behind us, all that closing
00:27:00 - work behind us, it is time to truly close the project and put
00:27:03 - it to bed and we do that by consolidating all of the activities
00:27:07 - from closing, putting it in to a formal closing document publishing
00:27:12 - it to the organization and calling the project a close and then
00:27:16 - we celebrate.
00:27:21 - Projects deserve a celebration, anyway that aside,
00:27:25 - the closing document should contain the snapshot of the last
00:27:29 - project status. The last monthly status report where we consolidate
00:27:35 - and reported on the project schedule of the project budget, the
00:27:37 - project risks, the project issues basically take a snap shot
00:27:41 - of your last formal project status and put it in to your closing
00:27:45 - document. Take your lessons learned and formally publish them
00:27:49 - into your closing document. Tell everyone where you have put
00:27:53 - your reusable artifacts. Tell everyone what your reusable artifacts
00:27:58 - are and tell everyone why you are excited about your reusable
00:28:01 - artifacts. As part of project closing I am not sure I would publicly
00:28:08 - present my performance appraisals, but as part of the formal
00:28:12 - project closing, we certainly need to do performance appraisals.
00:28:16 - The team members are being released, the team members are going
00:28:19 - back to their other duties as assigned so we need to insure that
00:28:22 - we have provided the appropriate performance appraisals to the
00:28:26 - HR department while the performance has freshen our brain. We
00:28:32 - need to document as part of the closing document what transition
00:28:36 - took place, where the transition documents are, how people can
00:28:39 - learn about the transition and we need to have this thing called
00:28:43 - a post mortem analysis after all is said and done you have looked
00:28:48 - at your last project status report, you have read your lessons
00:28:51 - learned, you have re-read and understood your artifacts.
00:28:57 - As a project manager, I believe we should take that last day
00:29:01 - of project closure to sit back
00:29:06 - in a nice calm quiet,
00:29:09 - I am going to say private environment and private only because
00:29:13 - you need to have time to think without people interrupting you
00:29:17 - and basically do a soul searching analysis, a soul searching
00:29:24 - statement of as the project manager on this project
00:29:30 - here is my assessment of the project. This is what I feel. Yes,
00:29:36 - there are lessons learned, yes the lessons learned are going
00:29:39 - to come from multiple team members, the project post mortem analysis
00:29:44 - is more here is what I the project manager believe is part of
00:29:49 - the project. Here is what I the project manager believes the
00:29:53 - project did well. Here is what I the project manager believes
00:29:56 - etcetera, etcetera. Publish this, put it in a spot. It is going
00:30:01 - to be found.
00:30:03 - I like to do luncheon learns in my organization. We often what
00:30:07 - will schedule and lunch and learn about 2 or 3 weeks after the
00:30:10 - project is done and the project manager will basically command
00:30:14 - and present the lessons learned. Tell
00:30:17 - everybody about all the reusable artifacts and where publishable
00:30:21 - to the public release their individual post mortem analysis so
00:30:26 - that again the organization is going to be better off. The organization
00:30:30 - is going to learn from my mistakes. The organization is going
00:30:33 - to repeat my successes, and the organization is going to harvest
00:30:37 - and reuse my reusable artifacts and the next time organization
00:30:42 - does a project it should be a quarter of a percent better because
00:30:47 - of my closing document and that is it, our project is now closed
00:30:54 - and our nugget series is completed. Well the nugget series is
00:30:58 - almost complete. You didn't think I was going to let you off
00:31:00 - that easy, did you? This does conclude 5.0 Project closure. In
00:31:05 - this nugget we focused on what happens in formal project closure,
00:31:10 - we gain acceptance,
00:31:15 - we insure we have proper project hand over to production,
00:31:22 - we do the project reviews,
00:31:28 - we look after contract closure,
00:31:33 - we release our resources
00:31:38 - and we celebrate.
00:31:45 - That is formal project closure. We also looked at doing different
00:31:49 - types of closure. What happens if this is a phase closure?
00:31:56 - What if this is a project cancellation?
00:32:01 - Do all of these steps supply if it is a phase closure? Well,
00:32:06 - pretty well all these steps apply possibly with the exception
00:32:09 - of the releasing of the team and possibly that our phase celebration
00:32:14 - may be a little more minor than a project celebration, but we
00:32:18 - still do acceptance, we still do handover to make sure the new
00:32:23 - team coming on in the next phase of the project understands our
00:32:26 - results. We certainly need to do the lessons learned and so
00:32:30 - on. If it is a project cancellation, we need to do all of the
00:32:34 - above so formal project closure is pretty well a one size fits
00:32:39 - all through all types and styles of closure and we complete our
00:32:44 - project closure by taking all of this work, all of the components
00:32:48 - of acceptance, handover lessons learned, contract closure, releasing
00:32:54 - of the team and we consolidate that into our closing document
00:33:00 - and then we celebrate. Oh did I say celebrate twice? But that
00:33:03 - is okay, your project is done. It was a success. I think it is
00:33:08 - okay to have two celebrations. Anyway,
00:33:11 - thank you for being with me. This does conclude this entire nugget
00:33:14 - series on project plus certification. I wish you great luck and
00:33:19 - I am sure you will do well with your certification exam and I
00:33:23 - hope you enjoy project management as much as I enjoy project
00:33:27 - management. This concludes our nugget on project closure and
00:33:32 - this concludes our nugget series on project plus certification.
00:33:36 - I hope all nuggets in this series have been informative for you
00:33:39 - and thank you very much for viewing.

Please help us improve by sharing your feedback on training courses and videos. For customer service questions, please contact our support team. The views expressed in comments reflect those of the author and not of CBT Nuggets. We reserve the right to remove comments that do not adhere to our community standards.

comments powered by Disqus

Course Features

Speed Control

Play videos at a faster or slower pace.

Bookmarks

Pick up where you left off watching a video.

Notes

Jot down information to refer back to at a later time.

Closed Captions

Follow what the trainers are saying with ease.

Premium Features

Transcender® Practice Exams

These practice tests help you review your knowledge and prepare you for exams.

Offline Training

Our mobile apps offer the ability to download videos and train anytime, anywhere offline.

Accountability Coaching

Develop and maintain a study plan with one-to-one assistance from coaches.
Steve Caseley

Steve Caseley

CBT Nuggets Trainer

Certifications:
PMI-PMP, PMI-ACP, PMI-SP, Project+

Area Of Expertise:
Project Management, MS Project, Development Methodologies, Agile Development


Stay Connected

Get the latest updates on the subjects you choose.


  © 2014 CBT Nuggets. All rights reserved. Licensing Agreement | Billing Agreement | Privacy Policy | RSS