Retired course

This course has been retired and is no longer supported.

About this lesson

Understand how to gain stakeholder acceptance during project closeout and learn how to create and use a Punch List.

Exercise files

Download this lesson’s related exercise files.

Stakeholder Acceptance.docx
60.2 KB Stakeholder Acceptance - Solution.docx
59 KB

Quick reference

Stakeholder Acceptance 

Stakeholder acceptance is the formal acknowledgement by stakeholders that the project objectives have been met. 

When to use

Stakeholder acceptance must be complete for the project to complete.  However, acceptance of all project deliverables does not need to be delayed until the end of the project.  Stakeholders can be formally accepting project deliverables as they are completed.  

Instructions

Acceptance should be conducted by someone not on the project team, to avoid any conflict of interest.  The stakeholders who should be doing the acceptance are those most interested in the respective deliverable, or their delegates.  For instance, if a deliverable was a marketing plan, someone from the marketing department (the head of marketing or their delegate) should review this deliverable.  When doing incremental acceptance, I recommend that at the end of each phase you formally document which deliverable s were accepted in that phase so that there is no confusion at the end of the project.

  1. Complete the project deliverable based upon the deliverable requirements.
  2. Verify by a project team member that the deliverable is complete.
  3. Determine with the stakeholder how stakeholder acceptance will occur (meeting, test, review).
  4. Schedule the stakeholder acceptance activity.
  5. Record any deficiencies and enter them on the Project Punch List.
  6. Correct the deficiencies and resubmit the deliverable for review/analysis.

Hints & tips

  • Unless you have worked with a stakeholder before and fully understand their expectations, assume that they will want some minor change or “tweak” in the deliverable.  Allow enough time and resources in the project plan to do the change.
  • Some stakeholders do not do a thorough job at stakeholder acceptance and then come back after completion and complain that the work was not done correctly.  If the stakeholder does not have the time to do the review, work with them to find an alternative acceptance method.
  • Stakeholders often try to “move the finish line” at this time and ask for more performance from the team.  This scope creep can turn an otherwise successful project into a failure.  Start the stakeholder review by going over the requirements for the deliverable (I assume you had their buy-in on the original requirements).  If they want to change those, stop the review and ask them to submit a change order to senior management for a change in the project scope.
    • A change may be the right thing to do, if business or market conditions have changed.  Don’t be “pin-headed” about insisting on the old requirements.  Acknowledge the need for the change, work to get the change approved, and then revise the deliverable.
  • If any deficiencies are discovered during the stakeholder acceptance process, capture those on a punch list and aggressively work to close those out.
  • Get the stakeholder to sign off on the punch list as being the only items that must be done to complete the deliverable.
Login to download
  • 00:04 Hi, I'm Ray Sheen, let's talk about closing out a project.
  • 00:11 In particular, a lot of folks are getting stakeholder acceptance for
  • 00:14 the final deliverables of the projects and agreement to end the project.
  • 00:18 The purpose of the closeout process is to obtain a formal acceptance
  • 00:22 of all the project deliverables.
  • 00:24 The stakeholders will review the deliverables and results and
  • 00:27 determine whether the project work has been completed.
  • 00:30 Part of the closeout is to validate that each deliverable meets its requirements
  • 00:34 for both quality and accuracy.
  • 00:36 The characteristics of the closeout process include insuring that the project
  • 00:40 objectives have met.
  • 00:41 And that all open action items for project reviews and
  • 00:43 management reviews have been closed out.
  • 00:46 And resources which were assigned to the project have been released back to their
  • 00:50 original organization or transferred over to the other projects.
  • 00:54 And that all the project results have been documented and archive appropriately.
  • 00:59 You can see from that list that the closeout process links back to
  • 01:02 the original initiating process, it was that time, that the goals and
  • 01:06 objectives are approved based upon the business objectives.
  • 01:09 The project performance targets will be also set at that time and it closeout,
  • 01:13 a final measurement is made to determine that those targets were achieved.
  • 01:18 Closeout as a hand off of the project results to the stakeholders.
  • 01:22 The stakeholders are typically very interested in the results of the project,
  • 01:25 keep in mind they're the ones who initiated the project and funded it.
  • 01:29 In many cases, the stakeholders are relying on the results of the project,
  • 01:33 in order to achieve their goals and objectives.
  • 01:35 The business benefits are often already baked into
  • 01:38 their expected business performance.
  • 01:40 The project must deliver for the business to meet its numbers.
  • 01:44 In other cases, the stakeholders are the users of the project result.
  • 01:49 They will be implementing it.
  • 01:50 They wanna make certain that whatever was created meets their needs.
  • 01:54 And of course, many times the stakeholders are also the funding agency for
  • 01:57 the project.
  • 01:58 Any good business leader,
  • 02:00 they wanna determined if they're getting adequate return on their investment.
  • 02:04 Key stakeholders often or involved in validating the results.
  • 02:08 They are members into the independent review team that validates whether
  • 02:11 the project results are fully compliant with all the business requirements.
  • 02:14 Stakeholder acceptance approaches will normally follow one
  • 02:17 of these three patterns.
  • 02:19 First, the stakeholder maybe a member of the team who
  • 02:22 directly analyses the results.
  • 02:24 They conduct testing and analysis and determine at the results accepted.
  • 02:28 Second, instead of directly reviewing or testing the deliverables,
  • 02:32 they may review the documentation about the deliverables and
  • 02:35 about the deliverable validation to ensure that everything is acceptable.
  • 02:40 And finally, they may have authorized an independent review by a third party,
  • 02:45 such as an industry expert or regulatory body.
  • 02:48 If your project has technical reviews,
  • 02:50 the independent reviewers will likely include some of your stakeholders.
  • 02:54 One last point in this topic,
  • 02:55 the stakeholder acceptance should be formally documented in the project files.
  • 03:00 This is helpful in case of a project audit.
  • 03:03 A technique that I've used to help close out with stakeholders,
  • 03:06 the work that's required is called a punch list.
  • 03:09 To create the punch list,
  • 03:10 I will meet with the stakeholders as we approach the end of the project.
  • 03:14 I review with them the status of all the project deliverables and then come up with
  • 03:18 a list of open actions that are still required in order to complete the project.
  • 03:22 Once I get the stakeholders agreement on those open actions,
  • 03:25 the project team completes each item on the punch list.
  • 03:29 This clarifies and defines the end point of the project.
  • 03:32 It prevents last minute scope creep.
  • 03:34 If you're not familiar with this term,
  • 03:36 scope creep occurs when the stakeholders or project team start to do actions and
  • 03:40 create deliverables that were not required in the original project charter.
  • 03:45 Many times, I find stakeholders asking for just one more thing and
  • 03:49 then just one more thing after that.
  • 03:51 These are often great ideas that occur to them as they see
  • 03:54 the results of the project, but
  • 03:56 they were never included in the cost and schedule estimate for the project.
  • 04:00 As the stakeholders decide to implement a scope change and
  • 04:03 says scope creep, which means it provide more time and money.
  • 04:06 So the project team should consider the request and provide an estimate.
  • 04:10 When developing a punch lists, go through every deliverable with the appropriate
  • 04:13 stakeholder before it's final submittal.
  • 04:16 Make sure you identified any gaps or inefficiencies in that deliverable.
  • 04:23 Yes, projects do have an end point, they're not a process to continues on and
  • 04:27 on and on.
  • 04:28 Final stakeholder's acceptance is that end point.
  • 04:31 Proactively managing this process, well I'm sure a clean hand off and
  • 04:35 a smooth close out.

Lesson notes are only available for subscribers.

PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.

Gift this course