Posts

Including Lessons Learned in a Closeout Report

/in /by

Capturing lessons learned thoughtfully in a closeout report is important and often overlooked. Here are lessons learned to include in your closeout report:

Project successes and issues: Highlight what went well and any issues experienced to inform future project managers. Keep to the facts. Don’t share personal opinions. Avoid names. The individuals involved won’t necessarily be available for future projects. Avoiding names also reduces the concern of publicly appraising a team member.

Plan recommendations and risk records: Help the next project manager be proactive. Recommend planning approaches and share risk records that would have helped your project.  Be specific to ensure that people not involved in your project fully understand the information. Document any organizational priorities or management preferences that impacted your project, as they will likely affect future projects. Don’t mention names. Simply share the priorities expressed by different areas of the business.

Early warning signs: Identify conditions that foreshadowed issues that occurred on your project. These signals are often overlooked. When tied to recommended risk records, knowing early warning signs can save considerable money and time on future projects. Talk about the characteristics of early deliverables and/or circumstances that affected your schedule or budget. If debates occurred between team managers, document those including their positions and rationales.

Other items you learned: Document what you wished you knew before you started the project. The future project manager that references this may be YOU, and you’ll be glad for a reminder of what to do or avoid on your new project!

For more about this, check out my course Project Management Foundations course.

This post contains affiliate links, and I will be compensated if you click my links and make a purchase.

It’s Not Just Agile versus Waterfall

/in /by

Designing your approach to project delivery is a strategic exercise, as there are several options. Here are questions to consider when choosing your approach:

How detailed will your requirements be? If your customer knows what they want and significant requirement changes are unlikely, traditional waterfall methods are appropriate. But pick only the waterfall tools you need. Limit project documentation to what will address risk. For example, you don’t need a procurement plan if you will purchase from a trusted supplier you have worked with before. Determine the tools you need based on the skill and experience you, your team, and key stakeholders have with the type of product you are delivering

What product are you producing? Agile, design/build or waterfall methodologies may or may not be suitable based on your project output. Building a house – think waterfall. A stand-alone web platform – think agile. But you could build either of those with a design/build approach if some requirements are well defined while others need to evolve. Consider how much flexibility you have in building your project’s products. Then choose the methodology that gives you the best chance of fulfilling scope and delivering on time.

What staff do you have available?  Agile can be a fantastic way to deliver a product – but only if you have experienced staff. Transitioning to agile is not trivial, so having staff members experienced in agile is important. If you are adopting agile, you can go hybrid…building parts of your product with agile and others in more of a waterfall approach. Selecting a project methodology based on your current capabilities and what you are aspiring to learn is a productive approach.

What does your customer expect? The project successes and failures your customers had in the past will form their judgment around project methodologies. They will have expectations for what they see or don’t see as you manage the project. If nothing else, embrace being predictable. A customer who understands what you are doing and whose expectations are being met – even in the face of some diversity – will usually stick with you. You might be running a perfect project but if what you’re doing seems unpredictable to your customer, your position is tenuous.

Remember, it isn’t just agile or waterfall. Agile, design/build, a hybrid approach or waterfall with extensive or limited tools are all options as you decide on a methodology to deliver your project outcomes.

For more on project management methodologies, check out my Project Management Foundations course on Linkedin Learning.

Photo by Jonatan Pie on Unsplash

When the Sponsor and Customer are Two Different People

/in /by

When your sponsor and project customer are two different people, you face some unique challenges. Here are tips for handling this situation:

Address differing needs. Understand the motivations and concerns of your sponsor and customer. Customize your reports and briefings to fit those needs. If they aren’t in alignment, your status updates are the best hope for creating cohesion on the project. Although it isn’t feasible to customize communication for every stakeholder, your sponsor and customer are vital and require appropriate attention.

Align priorities. Delivering scope, within budget and on time is the goal. However, issues may dictate prioritizing these critical constraints. Facilitate a discussion your sponsor and customer to align priorities. Imagine the challenge if your sponsor wants to cut scope to stay within budget, while your customer wants to retain scope and spend more. If they can’t agree, defer to your sponsor (and focus on the next two tips to keep things moving!)

Create a review committee. Your customer and sponsor may have different views of project success. Major deliverables and decisions require meaningful discussion and decision-making. Creating a committee to review deliverables and make significant decisions helps ensure organizational buy-in as your project proceeds.

Verify the approval process. Make sure your sponsor and customer are on the same page about who will make decisions and how that process will work. Determine this process in advance . The last thing you want is schedule delays because the sponsor and customer are arguing and engaging in an escalation process.

Having separate sponsor and customer perspectives and passion for your project brings many benefits – you generally produce a better product! Helping these vital stakeholder work in harmony is an important part of your role as a project manager.

To learn more, watch my course (#10 on LinkedIn’s Top 20 most popular courses for 2020). LinkedIn has made it free for September 2020.

This post contains affiliate links and I will be compensated if you click my links and make a purchase.