Locked lesson.

Upgrade

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.docx
60.2 KB Stakeholder Acceptance - Solution.docx.docx
59 KB

Quick reference

Stakeholder Acceptance

Stakeholder acceptance is the formal acknowledgment 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 deliverables 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, this is Ray Sheen.
  • 00:05 Let's talk about preparing for closing out a project or
  • 00:08 at least a phase of a project.
  • 00:09 In particular I want to focus on the role of the stakeholder for a moment.
  • 00:13 Stakeholders are typically very interested in the results of the project.
  • 00:17 Keep in mind they're the ones who initiated the project and funded it.
  • 00:21 In many cases the stakeholders are relying on the results of the project in order to
  • 00:25 achieve their goals, and their objectives.
  • 00:28 The business benefits are often already baked into the expected business
  • 00:32 performance.
  • 00:33 The projects must deliver for the business to meet its numbers.
  • 00:36 In other cases the stakeholders maybe the users of the project results.
  • 00:40 They will be implementing it.
  • 00:42 They want to make sure that whatever was created meets their needs.
  • 00:46 And of course, many times stakeholders are also the funding agency for the project.
  • 00:51 Like any good business leader they want to determine,
  • 00:54 if they're getting an adequate return on their investment.
  • 00:56 Key stakeholders often are involved in validating the results.
  • 01:00 They're members of the independent review teams or the sprint demo.
  • 01:04 And they validate whether the project results are fully compliant with all of
  • 01:08 the business requirements.
  • 01:10 Stakeholder acceptance approaches will normally follow one of three patterns.
  • 01:15 First, the stakeholders maybe a member of the team,
  • 01:17 which directly analyzed the results.
  • 01:20 They conduct testing and analysis to determine if the results are acceptable.
  • 01:24 Second, instead of directly reviewing or testing the deliverables,
  • 01:28 they may review the documentation about the deliverables and
  • 01:31 about the deliverable validation to ensure that everything was acceptable.
  • 01:36 Finally, they may authorize an independent review by a third party,
  • 01:40 such as an industry expert or a regulatory body.
  • 01:44 If your project has technical reviews,
  • 01:46 the independent reviews will likely include some stakeholders.
  • 01:49 Our last point on this topic is that the stakeholder acceptance should be
  • 01:53 formally documented in the project files.
  • 01:55 This is helpful in case of a project audit.
  • 01:58 Many projects review and approve the deliverables as part of gate reviews.
  • 02:03 Let's look at this special project oversight meeting.
  • 02:06 Gate reviews are a normal part of the project management methodology in
  • 02:10 traditional and concurrent project methodologies.
  • 02:13 They maybe called stage gates, phase gates, or
  • 02:15 toll gates, but they all do the same thing.
  • 02:17 There are milestones in the project schedule where review occurs of
  • 02:21 deliverables to reach a decision of whether the project should proceed.
  • 02:25 During the gate reviews stakeholders assess whether the project team has been
  • 02:29 successful in moving the project through the methodology.
  • 02:33 These meetings are focal points, focusing both project effort and decisions.
  • 02:38 There are essentially four directions that project stakeholders can go with
  • 02:42 the project.
  • 02:43 In the gate review, the stakeholders need to decide what next.
  • 02:47 Not deciding leaves the team stuck doing nothing.
  • 02:50 The first possible decision is to approve the project for the next phase.
  • 02:53 The work of the preceding phase was done successfully.
  • 02:57 So the project progresses on.
  • 02:58 The second possible decision is similar to the first, the project receives
  • 03:03 a conditional approval, so work on the next phase is started.
  • 03:06 But there are still some cleanup items from the preceding phase that must be
  • 03:10 closed out.
  • 03:11 These are then followed up on action items.
  • 03:13 The third option is to close this gate and
  • 03:16 send the team back to redo portions of this phase.
  • 03:19 And then come back for
  • 03:20 a new gate review when they have completed everything satisfactorily.
  • 03:25 And the final decision is to cancel the project.
  • 03:28 Now this cancellation may not be a project issue,
  • 03:30 it maybe due to business conditions.
  • 03:32 The business need no longer exist.
  • 03:35 But of course,
  • 03:35 it may also be due to the fact that the project has an insurmountable obstacle.
  • 03:40 A technique that I've used to help close out a phase or
  • 03:43 a project with stakeholders is called a punch list.
  • 03:47 This defines the remaining work.
  • 03:49 To create the punch list,
  • 03:50 I'll meet with the stakeholders as we approach the end of the phase or project.
  • 03:54 I review with them the status of all deliverables, and then come up with a list
  • 03:58 of any open items that are still required in order to complete the phase or project.
  • 04:04 Once I get stakeholder agreement on those open items,
  • 04:06 the project team completes each item on the punch list.
  • 04:10 This clarifies and defines the endpoint of the phaser project, and
  • 04:13 prevents last minute scope creep.
  • 04:15 If you're not familiar with that term, scope creep can occur
  • 04:18 when the stakeholders or project team start to do actions and
  • 04:21 create deliverables that were not required in the original project charter.
  • 04:26 Many times I find stakeholders asking for just one more thing, and
  • 04:30 then just one more after that.
  • 04:33 These are often great ideas that occur to them as they see the results of
  • 04:36 the project.
  • 04:37 But they were never included in the original cost and schedule estimates for
  • 04:40 the project.
  • 04:41 The stakeholders decide to implement these,
  • 04:43 a scope change is required instead of scope creep.
  • 04:46 Which means that they provide more time and money to do the work.
  • 04:50 When developing a punch list go through every deliverable with
  • 04:53 the appropriate stakeholder before it's final submittable.
  • 04:57 Yes, projects have an endpoint.
  • 04:59 They're not a process that continues on, and on forever.
  • 05:02 Final stakeholder acceptance is a key element of that endpoint.
  • 05:06 Proactively managing this process should ensure a clean handoff and
  • 05:10 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