Just Enough Project Reporting

/in /by

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.

_______________________________________

 

Lesser-known Benefits of Quality Management

/in /by

Quality management is about ensuring your deliverables meet the expectations of stakeholders: meeting standards, performance and reliability business needs. But quality management delivers extra benefits you don’t often hear about: 

  • Enhanced stakeholder buy-in. Quality management requires a deeper grasp of stakeholder needs and expectations. That understanding comes from better conversations and learning about stakeholder’s challenges and hopes. These stakeholder interactions boost buy-in to the project and also improve the stakeholder/project team relationship.
  • Expanded risk management. Understanding quality standards and performance expectations leads to a better understanding of product requirements. That understanding broadens your view of what must go right and what might go wrong with the project’s products.
  • Increased innovation. Quality management encourages continuous improvement and expands problem-solving. A quality mindset fosters innovation. It also increases the capability of the project team and stakeholders. Project team capabilities increase through new and better ways to meet quality standards. Stakeholder capabilities are increased through enhanced requirements definition. This also improves outcomes by improving stakeholder’s interactions with project teams.
  • Increased product knowledge. Quality assurance activities, such as reviews, inspections, and testing, produce learning moments. They expand the understanding of the product’s strengths and weaknesses. And they also help identify potential areas for future development. So, you get better outcomes now and new pathways to improve your business in the future!

As you work on quality aspects of your projects, look for ways to use these added benefits.

For more about project quality management, check out Daniel Stanton’s Project Management Foundations: Quality 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.

_______________________________________

Alleviate Team Member Stress

/in /by

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.

_______________________________________

 

 

 

Project Review vs. Project Audit

/in /by

During your career as a project manager, you might endure people poking through one of your projects, looking for things to improve. There are two typical approaches for this: a project review and a project audit. The differences are important, because a project manager needs to behave differently for each of these improvement initiatives.

A Project Review typically…

  • Is a supportive exercise. The intent is to discover improvement opportunities. It is performed with the project team.
  • Has unlimited scope. The review can look at any aspect of the project. The reviewers can interview any project stakeholder.
  • Examines management practices and implementation approaches. The review team searches for opportunities to streamline methodologies. Also, they look to enhance communications and create better business outcomes.
  • Focuses on improving future projects. Project reviews deliver recommendations that aren’t mandatory to put into action on your project. The intent is to enhance project management going forward.
  • Can be performed at any time. Teams conduct reviews while a project is running or after project completion.

When involved in a project review, the project manager should:

  • Collaborate with the reviewers. Work in harmony to achieve the goal of improving the current project and future projects for the organization. 
  • Negotiate interview schedules with reviewers for a current project. Leading a project efficiently is the best way to deliver outcomes for the business. Help the reviewers understand your schedule and the availability of stakeholders to minimize the impact on project deadlines.
  • Make information readily available and act on recommendations. Share any documentation you have available and seriously consider any recommendations for new project management deliverables that the reviewers suggest. This is the best way to improve project delivery.

A Project Audit typically…

  • Evaluates compliance, with a pass/fail outcome. The focus is on government regulations, internal processes, or specific project objectives. For example, have public funds for a project been managed per government regulations?
  • Has limited scope. An audit involves only stakeholders and management practices associated with specified compliance objectives.
  • Is conducted by personnel external to the project. These can be government officials or an organization’s internal staff with full-time compliance responsibilities.
  • Occurs during project execution. Because an audit often disrupts the project schedule, you will have to adjust some things. More significant audits are best managed as mini-project in parallel with the reviewed project to minimize the impact on project deadlines.
  • Yields findings that must be addressed. Responses to audit findings are mandatory. They adjust the execution of the reviewed project and projects in the future.

When involved in a project audit, the project manager should:

  • Focus on passing the audit.  You want the project found to be compliant with the target of the audit. Then, you want the auditors to leave you alone, so you can get on with your project. Being left alone is why it’s important for the project manager and team members to relay only information about the target of the audit. Going beyond the target area invites other investigations, which elongates the audit and further delays your project.
  • Figure out the auditor’s goal. Many auditors have one goal: to find an issue. They do that because they feel it validates their job. Others have a more balanced goal of finding issues if they exist, and not reporting findings otherwise. Collaboration might work when dealing with balanced auditors. Strictly sticking to the scope of the audit and “answering the question and only the question” is the best approach with less than balanced auditors. How can you tell if they are balanced or not? This is usually a judgment call, but the tone of the documentation you receive from auditors prior to the start of the audit gives you significant clues. If I am unsure of the auditor’s approach, I behave as if they are NOT balanced until they prove otherwise.
  • Accommodate the auditors schedule whenever possible. Auditors typically have a scripted approach to conducting an audit. Working within that script helps you get through the audit in the least amount of time, minimizing project disruption. So, strive to make stakeholders whose are relevant to the audit scope available to the auditors upon request. Push back if they request interviews with stakeholders whose role is out of scope of the audit.
  • Admit an issue if it exists and the auditors are en route to discovering it. Remember the goal of reducing the impact of the audit on your project. While dealing with audit findings is time consuming, if you are out of compliance, it’s better to resolve the issue. Reporting the issue shows cooperation. And the auditors may help you work through the best approach to resolution based on their experience. If auditors aren’t on a path to discover an issue, work to learn from their investigation. This can help you resolve an issue on your own, in a proper time, in a way that best serves your organization.

Have you been through a project review or audit? If you have any best or (if you’re willing) worst practices, share with us in the comments section.

_____________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 65,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.

_______________________________________

Avoiding Traps in Technical Project

/in /by

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.

_______________________________________

Embracing an Agile Mindset

/in /by

Adopting agile methodologies successfully requires the right mindset. For this iterative and adaptive approach to thrive, you need to embrace the following elements and characteristics. 

  • Speed and experience. Agile produces outcomes quickly, but that speed comes at a cost. You need dedicated experienced people on the team to produce quality outcomes and you need management involved in the effort, so they know what they’re getting. Don’t try to have less experienced people produce interim deliverables, which are then reviewed by those with experience. If you do that, the experienced folks can find shortcomings in the deliverables and request changes. For agile to work, deliverables and decisions must be “veto-proof.” That is, they cannot be overridden by a team leader or manager who doesn’t like the outcome. This demoralizes the team and sacrifices the speed that agile is supposed to generate. 
  • An “allow for learning” mindset. A benefit of agile is that it allows stakeholders and team members to learn. Using deliverables inspires learning and continuous improvement of the project’s products. That means stakeholders must be ready for products to be reworked after installation. Also, that learning often shifts the priorities from producing new deliverables to reworking earlier ones. Overall, this volatility in what the team works on is productive. The downside is that stakeholders who are eager to use new features might be disappointed. To support the learning organization mindset, be sure to communicate and reassure stakeholders.
  • Encouraging frequent small improvements. Agile produces the most important, business-improving deliverables early. This fast delivery of value can create expectations that business improvement will continue at that rate. Yes, the improvement will continue, but not at the same blistering pace as at the project start. The outcomes that agile produces are typically incremental improvements. Rarely does agile produce single big leaps. Make sure stakeholders understand that improvements will be smaller and that changes will occur often as the project continues.  
  • Trust and empowerment. For an agile team to thrive, stakeholders, management, even end users, must trust the team. The team needs to have permission to decide how to accomplish business objectives. This includes making decisions about adjusting business processes.   If trust isn’t there, the value of agile diminishes. Speed decreases, and team members will become frustrated.  
  • Simplicity. Agile methodologies favor simplicity over complexity and excessive documentation. Simplicity applies to processes, communication, and deliverables. Stakeholders must forgo the bureaucracy and documentation they received in the past. Focus instead goes to delivering working solutions. Documentation is developed from an exercise of watching how end users use those working solutions.

Do you have other suggestions to add to the agile mindset? Share with us in the comments section.

For more about agile, check out Doug Rose’s Agile Foundations 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.

_______________________________________

Criteria for Accepting Deliverables

/in /by

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.

_______________________________________

Building the Best Possible Project Team

/in /by

We usually don’t get to pick all of our team members. When you can, focus on individuals’ characteristics that will, when combined, give you the best possible team. Here are five key traits for a successful project team. 

  • The ideal mix of skills. Every project team needs the proper mix of technical and business skills. That way, the team can produce the right products that are usable by the business. You need a team that can design and build a product, but can also perform business analysis to develop procedures that will optimize the use of that product, In addition, personal characteristics, such as patience, diligence and the ability to multi-task can be important. Think through the skills you need as you build your project scope statement. 
  • Include people with earlier experience working together. Team members that have worked well together before are more likely to succeed on future projects. Over time, working together means you have a better understanding of each other’s strengths, weaknesses, and working styles. This familiarity can lead to improved foresight, more effective communication and efficient problem solving. 
  • Include team members who directly benefit from the solution. Involving people who benefit from the project solution can give you significant insights into its potential business impact. It also cultivates a sense of ownership among the project team. Note: Verify that the perspectives of the beneficiary team member align with those of the broader beneficiary group. That way, you won’t overlook discrepancies in objectives from different areas of the business.
  • Choose team members with positive relationships with key stakeholders. Maintaining positive relationships with key stakeholders can be the difference between success and failure. Good relationships build trust, and trust leads to better listening and improved exchange of both good and bad news. Good relationships also help ensure buy-in. And buy-in is crucial for meeting project expectations. 
  • Strive for diverse backgrounds and communication styles. Diversity in a team can lead to innovative solutions and improved problem-solving. A team that includes a mix of communicators, creative thinkers, and individuals from diverse backgrounds draw upon a wider set of knowledge, skills, and approaches to support business needs.

As a project manager, what choices have you made that improved your team’s performance? As a project team member, what team characteristics led to positive project outcomes? Share with us in the comments section.

For more about project teams, check out Daniel Stanton’s Project Management Foundations: Teams course.

_______________________________________

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.

_______________________________________

Avoiding Common Pitfalls Using AI

/in /by

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.

_______________________________________

Using Personality Traits to Assign Project Tasks

/in /by

Project team members come with diverse personalities. Let’s look at how to take advantage of different personalities and their work preferences throughout your project.

Important! As project managers, we might assume a person’s personality limits their abilities. For example, extroverts like to talk, but they‘re still able to actively listen to stakeholders. Be careful not to confuse preferences with capability.

Here are some examples of putting personalities to use: 

  • Introversion versus Extroversion. If possible, I assign introverted team members to support senior leaders who appreciate thoughtful consideration. These leaders appreciate team members who carefully digest information before responding. On the other hand, extroverted team members are better for leaders who engage in rapid-fire discussions. These leaders expect quick answers across a range of topics and thrive in dynamic settings.
  • Big picture versus detail-oriented thinkers. When constructing work breakdown structures (WBS), I like a mix of big-picture and detail-oriented thinkers in the room. Big picture thinkers excel at creating the high-level work breakdown structure–listing and combining overarching topics into high-order categories that make sense to the team. From there, the detail-oriented thinkers shine at identifying specific tasks needed to complete the work. Next, the entire team creates the mid-level breakdown and assigns the tasks. Big-picture and detail-oriented are both needed when you’re building a WBS from the top down and the bottom up! When it comes to testing, detail-oriented team members work thoroughly to confirm products to satisfy business needs.
  • Leader versus follower. Team members often need a degree of guidance and leadership to carry out tasks. Assigning a person to lead an effort might seem straightforward…pick the best leader. Maybe not! Sometimes you might need a person who will strictly follow your directions or who will make sure there is alignment with one of your business’ specific and rigid processes. In that case, a person who readily embraces and follows rules and processes might be the best leader.
  • Sensing versus intuitive individuals. By definition, a sensing person looks at the details of a situation and uses their senses to examine what’s in front of them. An intuitive person thinks more abstractly. They focus on future possibilities and patterns as opposed to what is currently present. Intuitives also typically pick up the feelings or disposition of other stakeholders. Sensing individuals are better for collecting and analyzing information.  Intuitive folks are better at collaborating with stakeholders who you suspect aren’t disclosing all of what’s on their mind.

Do you see yourself in any of these categories? Do the activities and roles sound like you? After examining yourself and the tasks you like to do, spend some time doing the same analysis for your team members.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 61,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.

_______________________________________