Lots of detailed and overwhelming project reports drain stakeholders’ confidence. Too few reports are even worse. How do you know when you produce the right number of reports at the right level of detail? Here are some indicators that you’ve hit the right amount of project reporting.

• Positive stakeholder feedback. Positive feedback from stakeholders is the best indicator. However, stakeholders might only skim your reports, trusting that you’ll let them know if there’s an issue. Ask your stakeholders questions about details of the reports you distribute. If you get positive feedback and answers that show a knowledge of what’s in the reports, you’re on the mark with your reporting. Answers without that detail mean your reports aren’t being read. You can ask your stakeholders more questions to figure out how to modify your reports to satisfy their expectations.
• Do stakeholders ask informed questions? Encourage stakeholders to ask questions. Intelligent questions about status reports usually means they’re on target. Think about the questions asked to see if you should include more explanatory text in your reports. Questions might mean you should make a report more understandable. Think about the questions people ask and use them to make your reporting more effective.
• Is there a clear presentation of status? Effective reports include clear indicators of status — usually up-front with a color scheme. If there are status issues, include the actions and outcomes the project team is taking to correct course.
• Do sponsor and status meetings focus on the reports? When project status conversations revolve around your reports, your reporting is likely on target. Because project managers rarely interact with every stakeholder, reports make up for that communication gap. Reporting is doing its job when casual stakeholder discussions include an accurate picture of project status, especially when the PM doesn’t interact with those stakeholders very often.
• Is reporting effort and risk balanced? Ideally, report generation is automated, it doesn’t take much effort. Sometimes you need specialized reporting, which requires extra work. Suppose the project objective is leapfrogging the competition. You might need detailed reports on the performance of a new product. In this case, the extra effort to produce these reports is worthwhile, because it’s a way to manage risk. Contrary to the effort to produce a special report to satisfy a single stakeholder’s curiosity.

What other indicators tell you your reports could use tweaking? If you’re willing to share your secrets, what reports features do your stakeholders love?

It dives deep, but you can learn about data analytics with Robin Hunt’s Learning Data Analytics: 1 Foundations course.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 66,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________

Project work isn’t for the meek. Pressure comes from management, stakeholders, and acute business needs and the resulting stress reduces team members’ performance. Helping your team alleviate their stress improves their performance and increases their loyalty to the project. Here are ways to decrease stress in your project environment.

• Recognize people’s emotions. You might hear that emotion has no place at work. That’s total crap. We are human. We have emotions. And ignoring them is unrealistic. Acknowledge that emotions are present and can make us shine or stumble in the workplace. And yet focus on the work, rather than the emotion. Be compassionate, which demonstrates your concern for your team member while supporting the need to produce the work.  
• Provide downtime. Under pressure, project managers often look to overtime, which can work for a short time. Yet, extensive over time (50+ hours/week) leads to stress. Recognize the need to take a break from work and re-energize. Downtime is like sharpening a saw — it helps increase productivity in the long run.
• Acknowledge the work people produce. It’s easy to fall into the trap of looking only at the incomplete or late tasks. Instead, acknowledge what people deliver along with the good work and effort they’re contributing. This recognition boosts people’s spirits and helps them focus on making progress toward delivering project outcomes.
• Meet and walk. Physical activity can act as a “stress off-switch.” Have one-on-one meetings while walking. Working virtually? No problem. Hold your video meeting or call with each team member walking in their neighborhood. Fresh air and a change of scenery can increase energy and generate new ideas, while exercise reduces tension and increases productivity. Use an AI meeting recording tool to take notes so all attendees can participate in the meeting.
• Champion coaching. Allowing team members to work with a coach can significantly reduce stress. Team members can work through their concerns with their coach. They can also get tips from the trenches or work on skill development. With an external coach, these benefits come without fear of judgment from management, which can build people’s confidence. It also reduces team member stress and improves project outcomes.

OK, we’ve all been stressed out at some point on projects. Let’s share our knowledge on this incredibly important topic. What have you done to relieve your stress or a team member’s stress?

For more about decreasing your stress, check out Todd Dewett’s course Managing Stress or Dr. Judson Brewer’s course, Train Your Brain to Unwind Stress and Anxiety Habits 

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 67,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________

Projects involving technology are challenging for project managers. But it’s rarely the technology that presents the challenges. Here are ways to avoid common traps that trip up PMs leading projects with technical components.

• Projects are really about business processes. Projects to deploy technology typically produce two things: increased productivity and/or reduced cost. What delivers these outcomes is improved business processes. These process changes must be acceptable and learnable by business staff. There is often more than one technical tool that can produce these business process improvements. Many projects get stuck by choosing the technical tool first. That forces the team to try to fit the business process to the tool, which can be tricky. So, don’t  consider the new technology as the output of the project. It’s the enhanced business processes that generate results.

• Support project and organizational change management. No change is too small to deserve attention. Technical changes may seem trivial to team members used to dealing with IT or engineering tools. As a result, they don’t realize the stress new tools can bring to business stakeholders. Experienced project managers support both project and organizational change management. This helps ensure the integrity of the project deliverables, testing regime, and product documentation. As you develop your project schedules, make sure to include specific tasks to help bring your stakeholders along on the change journey. This will ensure project stakeholders are aware, trained, and ready to incorporate new tools and processes into their work practices. Only then will business value be realized.

• Ensure new technical functions are useful. New technical capabilities can enhance business productivity…or not! Organizations often become enamored with installing the latest version of a tool to get the latest functionality. New technology isn’t always helpful. Think about how new functionality can fit into your business processes. If opportunities exist, take advantage of them. If new functionality doesn’t help enhance business processes, why install the latest version? Note: One benefit to updating technical tools is so they are supported by the vendor.

• Control the pace of change. Make sure you don’t ask your business stakeholders to absorb too much change too quickly. This typically isn’t a concern with waterfall projects. These projects produce single large updates, which are scheduled well in advance. Pace of change issues occur only when many waterfall projects finish around the same time. Agile projects can lead to pace of change issues, because they release small deliverables quickly. While speed of delivery is usually helpful, too much change can decrease the value the business realizes from project outcomes. Look at the overall schedule for changes the business must handle to make sure the pace is manageable.

• Run “business projects with technical components,” not “technical projects.” The vast majority of “technical projects” are meant to deliver business value. So, they should be driven by business stakeholders who collaborate with the technical team. This way, the business is responsible for delivering requirements and assessing business risk. Many technical teams believe they would do this better, because they understand how the technical tools work, including the business processes they support. This is risky though. Technical team members often don’t understand the nuances of delivering business outcomes. Also, buy-in from business stakeholders can be challenging when the technical team drives business improvement projects. Instead, keep the focus on the business objectives and business stakeholders.

Think about the last project you worked on that involved technology. It seems like they all do. How could you have applied these tips to make the project run more smoothly and deliver results more successfully?

For more about technical projects, check out Bob McGannon’s Project Management: Technical Project course.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 64,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________

What criteria do you use to accept a deliverable? Have you ever even thought about it? I recommend applying more scrutiny to whether a deliverable is complete when closing a task. Here are criteria for deciding whether to accept a deliverable and close project tasks.

• Deliverables have been produced and can be reviewed. You can’t accept a deliverable if it doesn’t exist yet – or you don’t know that it’s ready. The deliverable for a completed task (software code, machine part, installed stovetop, etc.) has to be shared and then validated. If a deliverable product or service can’t be reviewed (maybe the software is complete, but the server is down), then the tasks to produce that deliverable have to be kept open until the review is completed.
• Acceptance criteria are met. The next level criteria is that the deliverable passes the tests and meets the stakeholders expectations. (This is why it’s important to document acceptance criteria before work starts on tasks.) If stakeholders aren’t satisfied, a task needs to stay open or new tasks have to be added to your schedule to correct the deliverable, so it meets expectations.
• Broad stakeholder approval is received. In some cases, deliverables need to be reviewed by other stakeholders after acceptance criteria are met, for example, customer reviews. The customers might not have provided acceptance criteria, but their views on the product’s viability are important. For this broader review, you distribute a sample of a product and collect customer opinions. If issues are raised, the related task(s) have to stay open or new tasks created to complete the work that needs to be done.

Sometimes deeper examination is called for before accepting a deliverable and closing project tasks. Consider the following techniques:

• Does the product contain scope creep items? Scope creep usually occurs when a well-meaning stakeholder shares an idea with a well-meaning project team member. If that idea makes its way into a deliverable without going through the change management process, voilà, scope creep. If you find scope creep in a product, you should consider whether to accept a deliverable or ask your team member to remove the scope creep item and re-submit their product for review and task closure. For example, you might not accept the deliverable with scope creep until it has passed the change control process. Or you might decide that is the result of a broader interpretation of a requirement and does not have to go through change control. Some people might leave it in because “it seems to work,” but the rest of know that is an irresponsible thing to do.
• Complete a detailed quality audit. At times, particularly in regulated industries, products aren’t considered viable until certified personnel have conducted a detailed review or audit, (medical instruments for example.) This activity usually goes above and beyond the acceptance criteria provided by internal stakeholders. When this audit is required, do not close tasks until the audit is complete and results are satisfactory.
• Does the deliverable include appropriate documentation? If you don’t have a separate project task for creating product documentation, documentation needs to be delivered along with its corresponding deliverables before accepting the deliverable and closing the task.
• Does the deliverables support successor tasks sufficiently? This acceptance criteria is often missing: whether the deliverable provides what successor tasks need. Don’t close a task until someone confirms that its deliverable allows successor tasks to proceed. 
• Does the output create new risks? Sometimes, the approach taken to produce a deliverable is different than planned. As a result, downstream risks may arise, even though the product meets all the acceptance criteria.  In this case, consider whether to accept the deliverable. You might want to ask your team to use a different method that doesn’t create new risks.

What do you look at before you accept a deliverable?  Do have any best practices to add to this list? Share with us in the comments section.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 63,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________

In a recent survey, AI in project management was my readers’ top topic to explore further. AI’s benefits are often highlighted, so let’s look at potential pitfalls using AI in project management. For an ironic twist, I asked an AI tool to identify the five most significant traps. 

Beyond best practice — required practice! Any output from an AI tool needs human review for clarity, context verification, and refinement. To show this, you’ll see the AI tool’s answers along with my human interpretation and insights. The My insight entries either clarify what wasn’t clear in the AI response or expand what AI identified to other scenarios. Overall, the AI response identified the high-level concerns I had thought of. However, I didn’t consider it complete. Of course, I could have asked AI to provide more detail on each high-level topic to see if it provided some of the insights I identified.

• AI-identified pitfall: Overreliance on AI. Project managers may become too reliant on AI tools and overlook the importance of human decision-making. It’s important to remember that AI tools are only as good as the data they are trained on and the algorithms they use. They can’t replace human intuition and experience.
• My insight: AI also can’t “read a room.” Sure, there are great tools to take notes during meetings, track and assign action items and check calendars. What they can’t do is tell whether a person is happy with an assignment. They also can’t tell if people are content with the meeting. They aren’t detecting body language (yet!). So, they only tell part of the story.
• AI-identified pitfall: Data quality issues. AI tools require high-quality data to function effectively. If the data is incomplete, inaccurate, or biased, the AI tool’s output will be flawed. (My aside: Yep, garbage-in, garbage-out is still true.) Project managers need to ensure the data they’re using is high-quality and free from bias.
• My insight: In addition, you need to review the sources the AI tool uses to produce its responses. One way to minimize data-quality issues is to include mandatory experience levels in your AI prompts. For example, “As a project manager with over 20 years of experience in delivering projects in the information technology sector…” then ask for the information you’re looking for. This approach helps improve response relevance and accuracy, but you still need to review the output.
• AI-identified pitfall: Lack of transparency. Some AI tools are “black boxes” that don’t offer any insight into how they arrived at their output. This lack of transparency can make it difficult for project managers to understand how the AI tool is making decisions and to identify potential issues.
• My insight: A simple rule – don’t use AI output without understanding the sources the tool referenced. Most AI tools are now providing specific (and actual) references as part of their response. Check those references to ensure their context is suitable for what you are trying to do.
• AI-identified pitfall: Inadequate training. AI tools require significant training to function effectively. Project managers need to ensure that they and their team members are adequately trained in the use of the AI tool and that they understand its limitations.
• My insight: Using AI to produce something you don’t fully understand is another version of inadequate training. I heard a story where a web developer used an AI tool to produce code in a language that he had not learned. While initially it appeared to work, errors arose. The developer didn’t have any idea how to debug the code, and refined AI queries to correct the code were unsuccessful. His reputation with his client was tarnished because he didn’t appreciate the need for proper training.
• AI-identified pitfall: Ethical concerns. AI tools can raise ethical concerns, particularly around issues of privacy and bias. Project managers need to ensure that they are using AI tools in an ethical manner and that they are not inadvertently perpetuating biases or violating privacy laws.
• My insight: Do your homework! Understand your local laws. They are changing quickly around the world. The safest thing is to analyze the output from AI tools, verify its accuracy and how much it has “spit out” the work of others. Make changes or don’t use the output without seeking permission from the referenced author. Another approach is to apply the output to your own stories and experiences. For example, if AI output recommends that you need to beef up project requirements, document that need by conveying your own stories where requirements were inadequate. That way, you use your intellectual property, not someone else’s who didn’t provide permission to do so.

Do you see other pitfalls to using AI in project management? Rules for how to make AI work effectively in your work? Share with us in the comments section.

For more about AI, check out Dave Birss’ How to Research and Write Using Generative AI Tools course. Or search LinkedIn Learning for his name to find all his courses.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 62,000 subscribers. This newsletter is 100% written by a human (no aliens or AIs involved). If you like this article, you can subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________