Posts

When to Defer Decision-Making

/in /by

Timely decision-making is a valuable skill for project managers. There are times when deferring a decision is the best way to respond to project situations. Here are some situations when delaying a decision make sense.

  • Your vendor has product upgrade plans. What if the release date for an updated product isn’t finalized yet? Rather than sticking with the current version or gambling on the new one, set the software decision as late as possible in your plan. When your decision time arrives, you can evaluate up-to-date information about the release to decide on what to do.
  • Stakeholders are debating the project’s value. It’s risky (and perhaps costly) to continue when key stakeholders are debating the value of your project or a part of it. can be risky — even if deadlines are looming. Continuing might alienate a stakeholder, leading them to withdraw their support. Wait until the stakeholders’ debate is over before making your decision. If deadline pressure becomes overwhelming, work with your sponsor to expedite the stakeholder’s discussion.
  • Regulatory changes are under consideration. With regulated outcomes, project solutions must conform to legislation. Regulations might apply to the methods for creating outcomes, like the highly-legislated process for testing new drugs. If regulations are under debate or are being revised by government agencies, wait until the changes are confirmed before deciding on how to produce project deliverables. Note: Speed to market that conforms with new regulation can be a valuable business strategy. So you might decide to speculate on the implementation of a regulatory change and move forward with a solution  — or produce multiple deliverables to accommodate regulatory options. Even in this case, wait as late as possible to understand the potential regulatory changes.
  • Cross-project dependencies are delayed. When deliverables from another project are prerequisites to your project and they are late, you might have to delay decisions in the successor project. Be sure you understand the prerequisite’s makeup and outcome before making a decision about how to use the full capabilities of that deliverable. As with regulatory changes, you might speculate about the deliverable, but you should wait on that so you know as much as possible about the deliverable.
  • Resource availability is unclear or undetermined. An appropriate level of technical and business process expertise is important on project teams. It can be beneficial to wait to see if the management team can make a knowledgeable staff member available. If that expertise isn’t available, you’ll have to hire skilled contractors or allow more time for lesser-skilled people to get up to speed and perform work. These options cost time and money, often much more than you’d spend on that expert staff member.
  • Stakeholder requirements are unconfirmed or delayed. Project failures can be caused by project teams designing and producing deliverables without getting accurate requirements from stakeholders. They move forward assuming they know what stakeholders want. This alienates stakeholders and reduces their confidence in project deliverables. That could result in deliverables being partially implemented or not at all. Bottom line: wait until key stakeholders confirm the project deliverables before moving forward.

If you have a decision coming up, think about whether there is an advantage to delaying it. If you can think of other times when a delay is beneficial, share them with us in the comments section.

For more about decision-making, check out Becky Saltzman’s Critical Thinking for Better Judgment and Decision-Making course.

Coming Up

I am busy updating two of my courses. Later in the year, you’ll be seeing new and improved versions of Learning Microsoft Project and Project Management Foundations: Choosing the Right Online Tool. The latter course will review more tools than the original using a different format.

_______________________________________

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

_______________________________________

Beyond SMART Requirements

/in /by

Making sure business requirements are suitable is a valuable practice. Using SMART requirements (Specific, Measurable, Achievable, Relevant, and Time-bound) is a great start, but it isn’t always enough. Here are other requirement characteristics that help keep projects out of trouble.

  • Will the requirement cause conflict? Requirements can benefit one part of the business and cause difficulties for another. For example, creating a streamlined approach for selling a product might help sales while creating problems for the finance department in collecting client payments. Identify potential conflicts and try to adjust requirements to benefit all business areas.
  • Prioritize the requirements. Prioritizing requirements accomplishes two important things. First, in the event of budget cuts, you can remove requirements that have the least impact on the delivered solution. This strategic approach to prioritization simplifies scope management. Second, the discussions around prioritizing requirements are an educational process for the project team. The more the team understands stakeholders’ needs and business rationale, the more effective the project deliverables can be.
  • Are stated requirements “the tip of the iceberg.” Stakeholders sometimes think about their immediate needs and overlook the big picture. For example, a sales team presents a requirement to enable customers to select product color on the company website rather than talking to a sales agent. This could trigger an avalanche of requests for choosing different product options via the web. In this situation, the project team might proactively ask whether product options beyond color are desirable. That way, the development team could design and build a more comprehensive set of product options, which might be cheaper and more efficient in the long run.
  • Does this requirement impact regulatory processes? Businesses consider process or tool enhancements to increase productivity. What if enhancements affect outcomes that are needed by regulatory requirements. The process to create a regulated outcome might also be regulated. Make sure requirements don’t violate regulatory standards for processes and outcomes.
  • Are test cases available and feasible to create? Complex projects can involve multi-faceted requirements. Test cases assess a solution help determine whether the project solution satisfies a requirement. There’s a risk when test cases can’t be derived or are extremely expensive. The next logical step is to assess that risk to determine if you should accept the requirement. Commercial Off the Shelf Software (COTS) provides an example. Some COTS components are not validated via test cases because non-functional requirements, like usability or real-world performance, might not be adequately testable during development (due to lack of access to client production environments and so on).

Add these characteristics to your requirements checklist. If you have other items on your checklist, share them with us in the comments section.

For more about requirements, check out Angela Wick’s Requirements Elicitation and Analysis course.

Coming Up

I am busy updating two of my courses. Later in the year, you’ll be seeing new and improved versions of Learning Microsoft Project and Project Management Foundations: Choosing the Right Online Tool. The latter course will review more tools than the original using a different format.

_______________________________________

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

_______________________________________

Creating Meaningful Learning Moments

/in /by

Project setbacks are inevitable. The savvy project manager turns these challenges into learning opportunities. It takes finesse to add value in these situations, so here are approaches to turn setbacks into constructive learning moments.

  • Focus on psychological safety. The phrase “focus on the problem, not the person” is only the beginning. To create constructive learning moments, focus on how the problem is described, what triggered actions, what actions were taken, and what outcomes resulted. It’s important to use neutral, non-judgmental, fact-based language. This helps create an environment of psychological safety where people can discuss setbacks openly and truthfully.
  • Root causes are critical. Consider whether the team discusses symptoms or potential root causes. The “5 Whys” approach works well here. Asking “why” at least five times drives deeper discussions which helps identify the root causes of problems. Areas to focus on include processes and procedures (and what inspired their creation), unexpected actions by automated systems, unexpected or unusual reactions from stakeholders, and lack of education on project management techniques.
  • Use learning-related language. I like the phrase “fail forward.” It conveys that failing can be positive. Making discoveries and pushing the envelope of how things are done are two examples of setbacks being positive: you learn something you can use in the future. For example, you can try speeding up quality assurance processes by using knowledgeable stakeholders who haven’t been part of your project development process instead of performing user acceptance testing. In some cases, this might work well. In others, you might find shortcomings to that approach. The lesson you learn is which projects benefit from the new QA approach and which ones don’t.
  • Update lessons learned frequently. You need to update lessons learned as the project progresses (like other PM deliverables. As you implement improvements, update your documentation of root causes and ways to recover from setbacks. Include whether improvements worked as expected or further adjustments were required. Note: If you apply lessons learned from earlier projects, you might need to update those as well to ensure you get the most out of your learning moments.
  • Don’t gloss over repeated errors. Attention to psychological safety and root causes doesn’t mean you disregard repeated setbacks caused by team members who ignored lessons learned. In 1 on 1 conversations, work to understand why the team member ignored a lesson learned and address any shortcomings that arise from the conversation.

Think about a recent setback you experienced on a project. Take a few minutes to write up a description of the problem using neutral, non-judgmental, fact-based language. Recall whether your team described symptoms or root causes. Did they focus on the failure, or did they identify things they learned? If this setback wasn’t handled with a positive mindset, ask your most learning-focused team member to use this setback to practice these approaches.

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

Coming Up

I am busy updating two of my courses. Later in the year, you’ll be seeing new and improved versions of Learning Microsoft Project and Project Management Foundations: Choosing the Right Online Tool. The latter course will review more tools than the original using a different format.

_______________________________________

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

_______________________________________

How to Handle Fearful Stakeholders

/in /by

Stakeholders who fear bad project outcomes are tough to manage. It’s important to address these fears. Left unmanaged, your project could be delayed or even cancelled. Here are a few approaches to manage project fears.

  • Listen to fearful stakeholders. Their past experiences may have tainted their perceptions. You need to understand their concerns. Actively listen to these people: make eye contact, ask questions, paraphrase their points, use the terminology they use. Stakeholders will feel heard when you refer to the business implications at the source of their fears. When stakeholders feel their concerns have been heard and are taken seriously (that is, the project team is committed to addressing their concerns), their comfort level with the project increases.
  • Share your plans. Your project plan talks about how you will accomplish things and what you do to ensure obstacles don’t prevent you from achieving project objectives. Stakeholders become concerned when there is a lack of communication, unexplained changes, or drawn-out decision-making. So don’t be shy about communicating how your project plan will help avoid obstacles to successful project delivery.
  • Add risk items to your plan that directly address stakeholder fears. Add items to your risk management plan related to your stakeholders’ fears. Ask them to help look for trigger events and implement risk responses. This way, the project team will partner with these stakeholders to ensure their fears don’t come to fruition. Even if the risks occur, they will be addressed directly with pre-determined actions the fearful stakeholders have already agreed to.
  • Address areas of concern in status reports. In your status reports, address the status of stakeholder’s concerns. This reinforces that the stakeholders were heard and that the team is focusing on those concerns as the project progresses.
  • Highlight quick wins. Identify and communicate completed milestones as the project unfolds. Celebrating these wins helps stakeholders visualize progress and builds confidence in the project’s ultimate success.
  • ALWAYS support views with data. Trying to reassure fearful stakeholders with past experiences doesn’t work. They don’t relate to projects they weren’t involved in.  Objectives information is more reassuring than subjective opinions. Support your assertions and decisions with data, metrics, and evidence from industry best practices and actual progress with the current project. Stakeholders are more likely to feel reassured.

Have someone with a concern about your project? Of course you do! Take 15 minutes to plan how you will use these approaches to address their concern. And then, try it! Let us know how it goes in the comments section.

Coming Up

I am busy updating two of my courses. Later in the year, you’ll be seeing new and improved versions of Learning Microsoft Project and Project Management Foundations: Choosing the Right Online Tool. The latter course will review more tools than the original using a different format.

_______________________________________

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

_______________________________________

How to prepare a project idea for primetime

/in /by

Project ideas are what support careers in project management — and present possibilities for moving your organization forward. Sometimes, project ideas need more work before they should or would be accepted. Here are indicators that a project idea isn’t ready and how to improve it:

  • The sponsorship prospects aren’t clear. A great question about a project idea is, “Who would be an appropriate sponsor for this initiative?” If the answer isn’t clear or several sponsors might be needed to fulfill sponsorship responsibilities, that’s a problem. A project is doomed without sponsor commitment. The fix: restructure the project idea to align with a potential sponsor’s scope of responsibility. 
  • Unclear benefits. For a valid project idea, 1 – who will benefit? and 2 – how will those benefits be realized and measured? If you can’t answer those questions, the idea might still be valid, but more work is needed before proceeding. Look for benefits resulting from changes to business processes, technology solutions, or customer support approaches. Then, document the answers to the questions above.
  • Unclear funding sources. For every project idea, it’s essential to ask, “How will we pay for this?” If the answer is not clear, more work is needed to determine where the project’s benefits will be realized. Analyze the project benefits to identify the business area that will benefit from improvements – that’s your candidate for funding.
  • Technology challenges exist. Some valid project ideas face technology platforms that struggle to handle change. Either the systems are too old or fragile, or the backlog of changes for the technology team is too large. In this case, you can consider two approaches. First, can benefits be obtained without extensive technology changes. Alternatively, if the benefits are large enough, consider contracting specialized technical or supplementary resources to address the technological changes needed to implement the project idea.
  • Lack of strategic alignment. Resources and/or funding shortages often constrain organizations. Project ideas that don’t support the organization’s strategic direction aren’t a good idea. If necessary, restructure the project idea to support the organization’s strategy — or dismiss it as one that doesn’t fit current business priorities.

If you’re a project manager who doesn’t hear about project ideas early on, the points in this article are great topics to discuss as you finalize your project charter. If the project rushes ahead before the points are resolved, incorporate them as risks in your project planning. That way, you can discuss risk response activities with your key stakeholders.

_______________________________________

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

_______________________________________

How to Validate Project Assumptions

/in /by

 

Validating the assumptions included in the project justification is key to minimizing project risk. Sometimes, straightforward research is enough. For assumptions that aren’t easily validated, here are other approaches to validate or, at least, reduce the probability of an assumption being wrong.  

  • Consult experts. Reach outside your organization. Seek the opinions of LinkedIn contacts, peers in project management associations, or prominent individuals in industry bodies. Ideally, get multiple perspectives so you can analyze the results to identify project situations that could render an assumption invalid. If you get differing opinions, use the Delphi approach. Send the differing opinions to your expert panel and ask them to comment on the rationale for dissenting views. Use the results of that exercise to figure out if the assumptions present a significant risk to the project.
  • Perform an audit. Find situations where you can directly test the validity of the assumption. Then, test the assumption via a manual process, querying a customer, or performing any other action that might provide a “sample result” you can use for validation purposes. For example, altering the directions you provide to clients to solve a product issue, publishing an advertisement with a different angle to a small set of clients, or changing the parameters of a system function to see if the subsequent system or user action is expected. Note: this approach has risks. You don’t want to frustrate a client or have an advertisement yield an adverse reaction to your product. To minimize risk of adverse outcomes, select the clients and situations carefully, and if feasible, alert a trusted client that you are trying something new.
  • Build a prototype. Designing a prototype process or I/T system is an effective way of validating assumptions. When it works, it triggers enthusiasm for the project and its potential business results. Depending on the situation, the prototype can be a small, standalone project or a set of features in an agile project environment. With this approach, be prepared for the project to take an unanticipated direction — your stakeholders might create additional requirements. No worries, the result is often more effective than the original plan, so keep an open mind.
  • Conduct a survey. Query individuals who aren’t familiar with the project’s justification and current assumptions. Why? Because stakeholders who know the assumptions can answer the survey questions to confirm or invalidate them based on their views about the project. Also, don’t make the mistake of taking a casual approach to designing survey questions. Use people with experience designing survey questions: the wording of survey questions is vital to ensure you get valid results.

Have you come up with other approaches for validating assumptions? Or have tips for managing the nagging feeling that you haven’t even identified all the assumptions? If so, share with us in the comments section.

_______________________________________

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

/in /by

Contract management makes sure that you and your project vendors agree on costs, terms, deliverables, and conditions. Dig a little deeper, and contract management can help your projects in other ways: 

  • Enhanced vendor relationships. Time spent negotiating vendor contracts helps vendors understand project goals and your organization’s culture. This effort also helps set expectations that smooth the process when the vendor’s resources are needed in future projects. In longer-term relationships, the vendor will be able to anticipate future needs and train their staff to support your organization’s future initiatives.
  • Expanded risk mitigation. Contract management helps identify and mitigate potential risks by defining terms, obligations, and liabilities for everyone involved. By identifying and planning for these risks, you reduce the probability of issues occurring when vendor resources work on tasks. In longer-term relationships, vendors can develop skills that position them to work on more and broader tasks. Skilled vendor resources help in several ways. If skilled resources within your organization aren’t available, you can turn to a vendor – thereby reducing the risk of using less skilled people within your organization. Skilled vendor resources also lighten your internal peoples’ loads so they have time for cross-training. That way, you reduce future risks related to skills shortages.
  • Compliance support. Vendor resources can help ensure your organization complies with government regulations or industry standards. When you include compliance in the terms and conditions of a vendor contract, the burden of creating compliant tools and processes shifts to the vendor. That reduces your organization’s compliance risk. Note: Even though that responsibility is shifted to the vendor, the contracting organization (that is, your organization) is ultimately responsible for compliance. Be sure to review all deliverables to ensure that the vendor has maintained compliance.
  • Long-term cost savings. Contract management helps current and future projects. Contracts on file simplify the renegotiation of favorable terms during renewals and can identify opportunities benefiting both the contracting organization and the vendor. This can yield longer-term deals at reduced cost, shorter ramp-up times for vendor personnel who return to the same client, and increased efficiencies.

Because contract management provides so many benefits, it’s a good idea for project managers to be involved even if another department does the bulk of the work. If you don’t already know the contracts people in your organization, make a point of introducing yourself!

For more about contract management and procurement, check out Steven Brown’s Purchasing Foundations course.

_______________________________________

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

_______________________________________

Prevent Pseudo-Stakeholders from Hurting Your Project

/in /by

People who think they’re stakeholders but aren’t waste your time and distract your project team. Early on, you need to address these pseudo-stakeholders, so they don’t eat up your time and resources. This Project Pointer provides approaches to identify them and reduce their impact on your project.

  • Hold public consultations. After meeting with identified stakeholders, it’s time to hold open-to-the-public meetings to discuss the project’s scope and objectives. People who think they have something to lose or gain from the project can share their thoughts and concerns at this meeting. By addressing these concerns early, you save time later on (from minimizing distractions from pseudo-stakeholders) that more than makes up for the time it takes to plan and deliver a public consultation session.
  • Draft out-of-scope statements. Project charters typically focus on defining scope. An underused aspect of project charters is identifying what is out of scope. By clearly defining what is and is not in scope, you can help prevent pseudo-stakeholders from delaying the project with needless debates.  
  • Build a deliverables map. This is a visual representation of the deliverables produced in a project, showing the prerequisite deliverables that must be completed to produce the project’s final deliverables. This comprehensive overview of every item the project will produce can highlight the areas of the organization that will and won’t be affected by project deliverables—and from that, you can demonstrate who actual stakeholders are. Anyone else is a pseudo-stakeholder.
  • Focus on organizational politics. Be aware of internal politics, power struggles, or turf wars that might lead individuals to think they are stakeholders. You can proactively address people’s concerns when you understand who challenges scope statements or demands more for their business area. Politics will alert you to managers (beyond your project sponsor) who you need to work with to prevent pseudo-stakeholder objections.

Try these approaches with your current project to see if you have pseudo-stakeholders dragging your project down. If you do, it’s time to address them politely, firmly, and with your reasoning.

For more about stakeholders, check out Natasha Kasimtseva’s Managing Project Stakeholders course.

______________________________________

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

_______________________________________

Want to Expand Your Skills? Use Your Network!

/in /by

Conferences and courses can help expand your skills and enhance your project management career. There are other ways to increase your abilities as part of your everyday job. Check out these ways to increase your skills by using your network.

  • Swap project reviews. A fresh set of eyes can spot weaknesses, flaws, or risks you might have overlooked. Taking advantage of others’ experiences can improve your project foresight. From your project management network, offer to review one of your colleague’s projects in exchange for them reviewing one of yours. You’ll get to see a project you might not know about, and you and your project management colleague will benefit from the insights you share.
  • Engage a contact as a mentor or coach. Take advantage of others’ skills and experiences by asking if they will mentor or coach you. This can be someone within or outside your organization. Internal mentors can help you understand project histories within your group and help with navigating office politics. External coaches provide different perspectives, challenges, and solutions you can apply to your projects.
  • Schedule case study discussions with colleagues. Case study sessions allow you and your colleagues to analyze and discuss real-world project scenarios. This can improve your analytical and decision-making skills and offer deeper insights into handling project challenges in your industry and others.
  • Expand your network and start a discussion. A quick search on LinkedIn lists more than 17 million people on the platform who refer to themselves as project managers. That is an amazing skill base! Search by industry or in your city and reach out. You’ll probably find other project managers eager to expand their skills as well. Launch a discussion, ask a question about a pressing issue, and take advantage of the experience your network can provide.
  • Use LinkedIn’s resources. You’ve discovered my Project Pointers newsletter. I also host live discussions on LinkedIn. You can ask questions during these live events or listen to the recorded videos at your convenience. Other LinkedIn Learning instructors offer newsletters hold live events. Check out the newsletters by Bob McGannon , Doug Rose and Chris Croft  among others!

Not sure how to reach out to others? One thing to keep in mind is that lots of others feel the same way. Don’t be afraid to be the one to kick things off. For more about networking, check out Dorie Clark’s Professional Networking course.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 68,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 Domain Knowledge is Needed to Manage a Project?

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

_______________________________________