Including Lessons Learned in a Closeout Report

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

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

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.

 

The Importance of Testing Plans

Testing is often an underdeveloped part of project plans. Here are circumstances that make solid testing plans critical:

Uncharted territory. If your project is delivering a product new to your company, risk increases. To address this risk, testing should include reviews throughout the project life-cycle.

Interface complexity. As interface volume and complexity increases, so does your need for rigorous testing. In your testing plan, consider impacts to people, processes, and technology from all interfaces.

Vendor touchpoints. Integrating vendor products means more interfaces with increased complexity. Expand your normal testing rigor when vendor products are involved. Increase your testing regime with vendor products. Test all assumptions. Create a data dictionary and confirm compliance with its contents.

For more on testing, watch this LinkedIn Learning testing course.

 

What Do I Do When My Sponsor is Also My Customer?

An engaged sponsor who doubles as your primary customer has pros and cons. Here are a few tips for handling this situation:

Prioritize the triple constraints. A combined sponsor/customer makes it easier to prioritize time, cost and scope. While you should strive to meet all three constraints, your job will be easier when you understand your sponsor/customer’s views on compromising among those constraints. For example, when issues surface, you can respond quickly and in line with your sponsors wishes. When your sponsor and customer are the same person you get no significant arguments about these priorities!

Seek different perspectives. Find a management resource that can counter an overly headstrong sponsor/customer can be useful. The idea sharing that occurs when your sponsor and customer are different people won’t happen when it’s only one person holding those roles. Find a trusted resource who can present different perspectives to generate idea sharing that leads to better outcomes.

Use an inclusive review process. The sponsor/customer might feel so confident in their perspectives that they overlook the need for reviews and validation activities. Work with your sponsor to schedule team reviews and invite other interested parties to ensure the project concepts and outcomes are valid and can be easily adopted by your organization.

Leverage the energy. Work with your sponsor to share their energy and dedication to the project with project stakeholders. A combined sponsor/customer has numerous reasons for the project to succeed. They often have clear ideas as well. Sharing that energy will generate enthusiasm and clarity for the project which can support the change management aspects of your project.

 

For more on project roles, watch this LinkedIn Learning course.

This post contains affiliate links and I will be compensated if you make a purchase after clicking those links.

Identifying the right people to provide requirements

Having the right resources to identify requirements gets your project off to a great start.  Here are 4 steps that can help:

  • Identity the right stakeholder groups. Identify the various stakeholder groups that will be impacted by the new product or solution. Which ones are right? The ones that will be impacted by the new solution or product. These can include internal departments and external entities such as vendors, customers and consumers. Don’t forget groups such as IT support, Legal, Procurement, Finance, Safety, Security, and Compliance.
  • Acquire the right domain expertise. Ensure all representatives have appropriate domain knowledge for the stakeholder group they represent. If not, push back to get ones who do. Ideally, getting at least two representatives from each domain helps you obtain broader perspectives.
  • Confirm resource availability. The best resources are rarely idle. Negotiate with the appropriate manager to obtain the right resources by explaining the value of requirements identification.  Design the requirements identification process to maximize the value obtained from these critical resources in the least about of time.
  • Attitude matters. The right attitude is essential. Work with your designated representatives to get them excited about participating in the requirements process. Emphasize how they can influence business outcomes for the area they represent.

With the right people are engaged in the requirements identification process, you can greatly increase your chances of achieving the desired business outcomes.

For more info on requirements, check out this LinkedIn Learning course

Managing a project during a pandemic

Managing projects is rarely easy. Managing during a pandemic is another matter!  Here are four actions that can help:

Soft skills first! It’s time to highlight your soft skills.  Touch base with each team member to determine their ability to perform.  Based on their circumstances, you may need to adjust their availability upward or downward if they’re working from home.  Follow up frequently, understand their changing needs, and adjust project plans as required.

Accommodate unpredictability. We’re seeing change like we’ve never experienced before.  Mentally prepare for frequently-changing demands and adjust plans to support those changes.  Align your risk management plan accordingly. Now is not the time to over-commit.  Review your project schedule to determine the actual output capability of your team and adjust as required.

Leverage technology.  Have your video conference expert show others the features your tool has to offer.  The more comfortable EACH team member is with video capabilities, the more productive and relaxed they will become.

Remember self-care. Don’t forget about yourself.  Proactively communicate the project changes you believe are necessary to ensure you have the tools, resources, and emotional support you need.  The more balanced you are – the better equipped you will be to help each team member as required.

During this unpredictable time, you need to balance caring for the project mission, your team, and yourself!

#projectpointers #projectmanagement

For more, check out the LinkedIn Learning Become a Project Manager learning path

 

Overusing Agile Can Reduce Your Success

Overusing agile will decrease your organization’s success! Here are signs of agile overuse:

Agile is the default: Using agile on projects without short-term needs puts unneeded pressure on scarce agile resources. Project solutions needing in-depth, long-term thinking often won’t benefit from agile, because agile doesn’t provide time to think through long-term consequences. If a project doesn’t have true short-term delivery needs, use traditional project management. Apply your agile teams to time-critical projects.

Designs focus on today without considering the future: If your sprints are consumed by fixing functions from hasty, ill-conceived designs, your speed will only get worse if you continue with agile. Lack of long-term analysis and design produces awkward tools or processes that require frequent band-aids. More agile then means more fixes and more fragile solutions.

Prioritization loses integrity: Over-reliance on agile to produce fast results reduces clarity needed to properly prioritize work. When everything is #1 priority, relentless pressure to produce decreases staff effectiveness. The urgency that used to differentiate crucial and nice-to-have is lost. Project timelines lose meaning because deadlines aren’t seen as authentic or justified.

Leaders are impatient to deliver: Another sign of inappropriate use of agile is a rush to deliver, which might introduce sub-par testing and implementing solutions without appropriate training. Leaders, who are focused on speed of change rather than improved outcomes, produce chaos and lose credibility with their teams and customers. Improvements envisioned at project initiation are often abandoned, because team members spend their time correcting issues created by earlier solution implementations.

Agile discipline breaks down: Instead of short, daily stand-up meetings, consistent sprint length and dedicated team members, you see the cadence of delivering functions sputter and confidence in agile wane. In some organizations, the agile terminology remains but doesn’t match what happens. “Stand-ups,” which are supposed to short, daily meetings focused on status, become weekly, long meetings of solving problems in addition to sharing status. The end of a sprint is determined by the next time any work is completed, rather than by the set cadence for progressing the initiative. Retrospectives become complaint sessions and don’t produce meaningful changes to improve results.

Agile can generate outstanding results when properly applied. If you see the symptoms here, don’t abandon agile; reset your conditions for launching agile initiatives.

Picking the Right Tool for Effective Communication

Effective communication content is critical for project managers, but so is the tool you use to send your messages. Here are tool guidelines based on the intent of your communication:

  • Email is appropriate for repeatable and expected messages such as status reporting or scheduling meetings. Because recipients can’t use factors like the voice inflection to interpret the meaning of your emails, it’s unwise to use email for messages that require interpretation. That’s why email should be limited to messages when only a straightforward acknowledgement is required from the recipient.

 

  • The telephone works when more information needs to be exchanged and the data or management process has been previously discussed, such as risk items, known issues being resolved, confirming requirements or simple change requests. Communication like this conveys information that may be questioned by the recipient, but those questions are predictable and the information is easy to discuss. Note: In situations where conflict may occur, use video conferencing or face-to-face meetings to manage the contention.

 

  • Video conference tools are recommended when new or unexpected information needs to be shared. Problem solving, discussing more complex requirements, or reprioritizing requirements are examples where this richer medium is needed. Idea generation and complex problem solving can also be performed via video conferencing, if functions like whiteboard sharing are available and all participants are comfortable with them. Otherwise, train attendees before using these virtual tools or meet face-to-face.

 

  • Face-to-face meetings are recommended when discussing your project in depth with difficult or powerful stakeholders or working through very contentious issues.

 

It isn’t always possible to use the recommended tool. To reduce risk, use the richest possible communication tool for the situation at hand.

Don’t trade efficiency for effectiveness. If you send a lot of messages that don’t yield the actions or answers you need, you’re sending the wrong message or using the wrong communication tool.

 

For more on communication, check out Doug Rose’s LinkedIn Learning course on project communication.