What Domain Knowledge is Needed to Manage a Project?

/0 Comments/in /by

A project manager doesn’t have to be an expert in a project’s domain area to serve as PM. But they must possess some domain knowledge to be effective. Here is the general domain knowledge needed to manage a project.

  • Processes and regulations. Domain areas have specific approaches to work and standards that must be understood. For example, in the drug industry, processes for introducing new medicines are rigid. These must be understood to deliver project outcomes.  In construction, one must know the laws that restrict a building’s design. Without this, the building could become unusable without expensive modifications. In healthcare, managing and sharing data requires both health and technology process knowledge. Without this vital domain knowledge, project managers have reduced foresight. And they are unlikely to gain the respect of their project teams which makes it difficult to succeed.

  • Sources of risk. Effective risk management involves understanding the challenges that may present themselves. The project manager must know enough about the domain area to anticipate possibilities. They also should understand the probability of them coming to fruition. While having an expert team member as a management partner can help, it isn’t enough. The project manager needs to interact with key stakeholders without deferring to others. They must also react to situations that occur daily. Having to constantly refer to an expert partner impacts the project manager’s perceived authority. It also brings their abilities into question, reducing effectiveness.

  • Ability to assess business value. Projects are all about creating business value. Sometimes that value is obvious, like creating a new drug that cures a disease. Other times, value propositions are more subtle, requiring industry expertise to understand them. For example, the value of a great website is that it is easy to maintain after delivery to a client. So, website construction techniques are important. The project manager should participate in construction decisions to ensure maintenance is straightforward. This requires an understanding of the capabilities of modern coding languages. Knowledge about AI tools and search engine optimization is also useful. Unless the PM has some level of experience in these areas, they could overlook critical project activities.

  • Management practices and cultural expectations.  Domain areas have varying norms around how decisions are made. The expertise that is most valued, and how clients and their vendors work together also vary between domains. Industry trends might not be easy to identify without domain experience. Understanding these nuances are vital for a project manager to succeed. These can be learned on the job if knowledge gaps aren’t extensive, but that must be done quickly so project success isn’t impacted.

_______________________________________

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.

_______________________________________

Focus on Project Goals

/0 Comments/in /by

Long-term goals are what projects are all about. Daily project challenges make it difficult to keep focus on those goals. Here are tips to help you keep your eye on the prize of successful project completion.

  • Use two goal definitions. The first set of project goal definitions needs to be relatable to your stakeholders to maintain their interest and support. But what about your needs? To keep you moving toward completion of the project and your growth opportunities, write your own goals for project completion. What will you gain personally? How will this project’s success help you get your next assignment? What other benefits might you receive after the project is completed?
  • Track multiple milestone types. Milestones can demonstrate progress. Because that progress can take several forms, create milestones that show positive movement for your stakeholders. Create a second set of milestones that are significant for the project team, like getting interfaces to work, overcoming a problem, or settling team staffing. Acknowledging these accomplishments boosts team morale and recognizes the valuable contributions all of you are making to the project’s success.
  • Focus on learning moments. Projects offer a bounty of unexpected moments, many of which are great learning opportunities. The more difficult, the more learning! Reflect on what you and the team have learned from what the project has thrown at you. How can you apply that learning to your current and future projects? You’ll see the value of the project journey — and the destination.
  • Adjust your plans without shame! Projects present us with unique circumstances. Despite diligent planning, you may have to adjust mid-flight. That’s okay! It’s part of project management and increases your ability to deliver your project successfully. Ignoring the need to replan is a much worse sin. 
  • Hold celebrations along the way. Achieving milestones, learning lessons, and successful replanning are causes to celebrate. Don’t wait until the end to acknowledge your accomplishments. Get your team together, celebrate your progress, and enjoy the journey.

Be honest: are you still aiming for your project target or are you lost in the weeds of day-to-day project minutiae? If you’re lost in the weeds, take a moment now to try one of these tips. If you’re laser-focused, share one of your secrets with the rest of us in the comments section.

For more about goal setting, check out Todd Dewett’s  Performance Management : Setting Goals and Managing Performance course.

_______________________________________

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.

_______________________________________

Just Enough Project Reporting

/0 Comments/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

/0 Comments/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.

_______________________________________