Which is Better: A big picture or detail-oriented PM?

/in /by
Which is Better: A big picture or detail-oriented PM?

Photo by pine watt on Unsplash

If you want to be a better project manager, do you enhance your big-picture thinking, or focus on being more detail-oriented? Ideally, both! For some types of projects, one style or the other can be advantageous. Here are some situations when big picture thinking and detail-oriented thinking are more helpful. 

Big picture thinking is best when:

  • The organization considers a series of inter-related projects to address strategic needs, and inter-project relationships have to be identified and managed.
  • Many stakeholder groups are involved, and you have to define and establish the relationship between the stakeholders’ needs.
  • There are many potential approaches for delivering the project. To be successful, you have to evaluate different methods and determine the sequence of high-level activities and high-level business risks.
  • Resourcing issues will arise due to demands from projects and operations. You’ll need big-picture thinking to figure out ways to satisfy the resource demands from both.
  • Continuous improvement is the motivation for the project(s). With continuous improvement projects, the outcome of each project is a new environment which future projects are designed in. 

A detail-oriented project manager is better suited when:

  • The PM needs to be in charge of building the WBS, task groupings and task sequences. This is often the case when the PM also serves as a technical expert, or when particularly careful project planning is required.
  • The PM needs to be a focal point for resolving technical issues and working with management to justify the project team’s proposed actions.
  • A strong focus on risk, budget, or quality practices is required. As the saying goes, “the devil is in the details.” When a project is heavily constrained by the budget or timeline, attention to detail is crucial. Also, strict quality standards require a detail oriented PM.
  • Improving processes requires detailed analysis to be successful. The insights identified by a detail-oriented PM are helpful with this type of project.
  • Intricate or numerous specific requirements need to be satisfied. Attention to detail ensures that all requirements are captured and met.

I hope this information gives you a different perspective on project management skills and your personal tendencies.  Use it to identify your  areas for improvement and to recognize the need for different thinking styles so you can communicate to sponsors/potential hiring managers accordingly.

Remember, neither style is better than the other. And a big-picture person can be detail-oriented  and vice versa. Some people are naturally big-picture thinkers, while others tend to be detail-oriented. Being adept at both isn’t common. If you lean one way or the other, consider having someone of the other style on your project. That way, you get the best of both!

Have you tried to expand your thinking to include the style that isn’t your strong suit? What issues did you run into? What was most helpful to your improvement? Share with us in the comment section.

 

Coming Up

Project success is driven to a large extent by healthy relationships within your project teams, which is why a lot of people skills go into project management. In this Office Hours on June 1, 2023, at 11:00am MT, Todd Dewitt will join me to talk about how to build better relationships – by learning to overcome our own fears and by building rapport with others through empathy and mutual respect.

Todd will be sharing some of the insights and strategies from his new book, Dancing with Monsters. I’m a big believer in relationship-building, so I’m looking forward to this conversation. I hope you’ll join us and bring your questions and challenges! Here’s the link to join: https://www.linkedin.com/events/betterrelationships-betterresul7060330084796170240

______________________________________________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 37,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 Leverage Your Out-of-Scope Statement

/in /by
How to Leverage Your Out-of-Scope Statement

Photo by Mohammed-Alqarni on Unsplash

The Scope Statement may be the most important document a project manager publishes. It helps define the project, captures what the project will produce, and defines success criteria for those results. A crucial section of the scope statement doesn’t cover what is in scope at all: the part that specifies what’s out of scope. Here are some tips for getting the most out of your scope statement’s out-of-scope section.

  • Make sure it reflects project delivery realities. In the scope statement, be specific about what is in and out of scope. In the out-of-scope section, be sure to document why out-of-scope elements are excluded. Typically, out of scope items are dictated by time to delivery, complexity or the availability of expertise. Sometimes, business priorities might exclude items.
  • Explain the advantages of smaller scope. A smaller scope allows for focused effort, a smaller team to manage, reduced cost, and less need for integration. These reduce complexity and increase the probability of successful project completion. If the reduced scope causes concern with key stakeholders, create risk profiles for the proposed smaller scope and one for the larger project stakeholders may be looking for. The differences in risk might help you justify going forward with a smaller scope.
  • Trigger debate, if necessary. When it comes to project scope, the worst debates are ones that need to occur, but don’t. Succinctly documenting what is in and out of scope is likely to generate a debate between key stakeholders. That’s good because it’s probably needed to move your project forward. Remember, your job as the project manager is to evaluate risk and deliverability. So, your part in the debate is to inform the stakeholders, not choose sides! 
  • Share what a “Phase 2” might look like. When an individual project ends, it doesn’t have to mean that creating business value ends. Many practical project initiatives involve a string of projects, each delivering incremental value. In fact, that’s the premise of agile project methodologies. Note in your out-of-scope section what a future project, like a phase 2, might look like. This can make it easier for stakeholders to approve your scope statement. 

Have you used the out of scope section in other ways? Or has that section gotten you into trouble or saved your project from problems? Share with us in the comments section.

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

Coming Up

On May 18 at 4PM MT, I will be joining Christina Charenkova to talk about how Project Managers and Change Managers collaborate on things like scope, communication, and stakeholder management. We’ll discuss how to use and clarify roles and plans, avoid pitfalls, and collaborate better for awesome outcomes! Sign up here:

https://www.linkedin.com/events/7056412593510363136

On June 1st at 11AM  MT, Todd Dewitt will join me to talk about how to build better relationships – by learning to overcome our own fears and also by building rapport with others through empathy and mutual respect. Todd will be sharing some of the insights and strategies from his new book, Dancing with Monsters. I’m a big believer in relationship-building, so I’m looking forward to this conversation. I hope you’ll join us and bring your questions and challenges!

https://www.linkedin.com/events/betterrelationships-betterresul7060330084796170240

_______________________________________

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

_______________________________________

Determine Your Minimum Viable Product

/in , /by
Determine Your Minimum Viable Product

Photo by Sincerely Media on Unsplash

A key to success in an agile project environment is to determine your Minimum Viable Product (MVP) — that is, the smallest, quickest-to-develop product that provides business value. With passionate stakeholders, keeping the MVP to a minimum can be a challenge. Here are steps to help you define your MVP.  

  • Understand the pain or opportunity. Take the time to understand the source of a problem (the pain) or the envisioned improvement (an opportunity). Analyze processes analysis to further understand the source of pain or opportunity. How can you generate value by adding/removing/creating new steps in a process? Your goal in producing a valid, minimal MVP is to minimize the number of process changes to achieve an improvement.
  • Sit at your customer’s desk (literally, if possible) and watch how they perform their job.  Watch for anything that represents manual activity: duplicate data entry, data verification or handoffs to another person or department. Many of these inefficiencies are taken for granted when collecting requirements. Observing someone at work can flag these as candidates to include in your MVP. If your customer shares other requirements during your “customer desk time,” ask them to show you what they envision. Be sure they use their current processes and tools to do so. Sketch things out on a whiteboard. Make sure you understand the advantages of their proposal.
  • Prioritize the features that surface. And be persistent! You may collect a lot of potential features while you sit at your customer’s desk. Use your observations to identify the most impactful features. If you are having trouble prioritizing, use the pairwise comparison approach. Take each feature and pair it with another. Then ask which one would you prefer to have. Do that for every possible pair of features, and you’ll have a prioritized list. 
  • Iterate building a prototype until you generate business value.  Generating ANY business value means you have created an MVP. That is, if your prototype shows evidence of delivering a positive business outcome, you have an MVP. Share it with your customers and assure them that you can continue to add more features and enhance business value. Doing this avoids the trap of an MVP not being a true minimum, but rather a set of features that address more than one point of pain or opportunity. Stick to the literal definition – a minimum solution – and you’ll be sure to generate the MVP agile was designed to produce.  

What else do you do to identify the minimum viable product in your agile projects? What questions do you have about identifying a true minimum product? Share with us in the comments section.

For more about minimum viable product, check out Daniel Stanton’s Project Management Tips course.

Coming Up

On May 18 at 4PM MT, I will be joining Christina Charenkova to talk about how Project Managers and Change Managers collaborate on things like scope, communication, and stakeholder management. We’ll discuss how to use and clarify roles and plans, avoid pitfalls, and collaborate better for awesome outcomes! Sign up here: https://www.linkedin.com/events/7056412593510363136

On June 1st at 11AM  MT, Todd Dewitt will join me to talk about how to build better relationships – by learning to overcome our own fears and also by building rapport with others through empathy and mutual respect. Todd will be sharing some of the insights and strategies from his new book, Dancing with Monsters. I’m a big believer in relationship-building, so I’m looking forward to this conversation. I hope you’ll join us and bring your questions and challenges!

https://www.linkedin.com/events/betterrelationships-betterresul7060330084796170240

_______________________________________

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

_______________________________________

 

Communication Tips for Handling People’s Concerns

/in /by
Communication Tips for Handling People's Concerns

Photo by Christina @ wocintechchat.com on Unsplash

Even with the best communication plan in place, your stakeholders might have concerns about your project. Here are a few common-sense communication tips to use when you’re addressing concerns. (These work equally well in professional and personal situations.)

  • Listen actively.  Your stakeholders should no doubt that you’ve heard what they said. You can do this by explaining how you think their concerns might affect the project. Make sure that your views reflect your stakeholders’ fears. Also, spell out the steps you are or will take to address their concerns.

Important Note: Explain your views and the actions you will take even when you don’t agree with the stakeholders’ concerns. Don’t try to convince a stakeholder that their concerns are unfounded. For example, say that the stakeholder is worried about a risk that you think is unlikely to occur. Normally, you wouldn’t add it to your list of actively monitored risks. But in this case, you would monitor what you need to track their concern – or take an action to track the risk. You will build trust and a stronger relationship by appreciating their emotions and acting on their concerns.

  • Provide regular updates through your stakeholders’ preferred medium. To reinforce that you’ve heard your stakeholders’ concerns, make sure that the stakeholders have up-to-date status of their concerns. Set up a schedule for updates that the stakeholders are comfortable with. Always use the communication method your stakeholder prefers. For example, you might use formal methods, like status reports, as well as informal methods like a specific message to your stakeholder. Keep your updates concise and make sure they address their concerns. Use the same vocabulary the stakeholder uses to reinforce that you listened and understand their situation.
  • Be transparent and share bad news early. To maintain trust, you must share both good and bad news in a timely manner. Also, don’t let stakeholders hear bad news come from anyone before you communicate it. If that happens, your relationship could be permanently damaged. Contact your concerned stakeholder whenever theirs concerns come to fruition. At that time, explain the issue and what you’re doing to address it. If you aren’t sure what action you’ll take, explain the investigation you’re doing and the alternatives you’re considering. Ask your stakeholders for opinions.  Let them know you’ve chosen a course of action. Schedule follow-ups to report on your progress.
  • Be realistic. While stakeholders may prefer to be reassured, don’t fall into the trap of trying to “fix their concern.” If things aren’t good, clearly state that. Don’t sugar-coat it or they might not get your message. Reaffirm the actions you’re taking. Tell them (and mean it) that you are dedicated to solving the issues that arise. 
  • Watch your mood.  Be mindful of your mood. Your stakeholder will catch your mood more easily than the words you use, no matter how wise your words may be. If you are feeling negative emotions, take time to improve your mood before you meet your stakeholder.

Do you have other tips for communicating when people are concerned about something in your project? What about when they’re angry or demoralized or overwhelmed? Share with us in the comments section.

For more about communication, check out Doug Rose’s Project Management Foundations: Communication course.

Coming Up

On May 18th 4PM MT, I will be joining Christina Charenkova to talk about how Project Managers and Change Managers collaborate on things like scope, communication, and stakeholder management. We’ll discuss how to leverage and clarify roles and plans, avoid pitfalls, and collaborate better for awesome outcomes! Sign up here: https://www.linkedin.com/events/7056412593510363136

_______________________________________

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

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.

_______________________________________

Expanding Team Member Capabilities

/in /by

The people on each project team have unique skills and strengths. To increase the effectiveness of your teams, look for opportunities to leverage and expand those attributes. Here are four approaches for expanding team member capabilities.  

  • Identify and leverage team member strengths. Take time to identify your team members’ strengths and weaknesses. Ask them questions to uncover their individual talents and preferences. Use what you learn to assign tasks that are best suited to their skill set. Also, look for opportunities to expand their experiences. Assignments that increase skills generate enthusiasm and loyalty, which can help you achieve better project results . 
  • Create a learning culture. Establish a culture of learning and continuous improvement. Set up opportunities to learn from you (the PM) and from other team members, such as lunch and learns, or cross-training sessions. Set up sessions where team members present their work and share their expertise. This can expand knowledge and perspectives throughout your project team. In addition, it will increase your team flexibility if a team member will be absent. When practical, support your team members when they try new approaches or work out of their comfort zone. You’ll improve team dynamics and project outcomes. 
  • Facilitate candid and courageous risk-based communication. Encourage team members to share their experiences, even when challenging the status quo. Every team member’s experience is valid. To reduce risk, use their collected pool of experience to determine the best direction . Make sure that stakeholders who are risk-averse don’t discourage team members from voicing their concerns. You will reinforce the value you place on team experience and enhance their sense of project ownership.
  • Focus on formal professional development. A learning-focused project environment creates significant professional development opportunities. You can go further by supporting team members in their pursuit of formal training and certifications. That way, they can increase their skills and stay up to date with industry trends. In turn, this helps you deliver better outcomes.  

Whether you are a project manager or team member, what are your preferred approaches for expanding capability? Share with us in the comments section.

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

Coming Up

On May 18th 4PM MT, I will be joining Christina Charenkova to talk about how Project Managers and Change Managers collaborate on things like scope, communication, and stakeholder management. We’ll discuss how to leverage and clarify roles and plans, avoid pitfalls, and collaborate better for awesome outcomes! Sign up here: https://www.linkedin.com/events/7056412593510363136

_______________________________________

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

_______________________________________

Reduce Risk by Managing Project Assumptions

/in /by
Reduce Risk by Managing Project Assumptions

Photo by Christina @ wocintechchat.com on Unsplash

Assumptions are an important and necessary part of launching a project — and you continue to evaluate them as your project progresses. Managing assumptions appropriately helps you reduce project risk. Here are four recommendations for handling project assumptions.

  • Determine when you can validate assumptions. Build a plan for how and when you can validate your assumptions. The earlier you can validate an assumption, the less risk it poses for the project. You can usually validate funding availability and internal staffing data early, because they require discussions within the company. Vendors’ staff availability should also be available early, but keep in mind how much experience you need. More experienced staff may not be available in the short term. Sometimes, validating assumptions takes longer. For example, waiting for a software release so you can confirm its capabilities. 
  • Identify the data you might need from stakeholders. Provide stakeholders with details about data you need to validate your assumptions and request it from them in writing as soon as possible. Don’t be surprised if you get incomplete data. Work with your sponsor to define the minimum amount of information you need to validate an assumption. If the data you require isn’t available, you need to manage that unvalidated assumption as a risk.
  • Plan your actions if an assumption is proved false. Investigate alternatives if an assumption is incorrect. At times, you might be able to take a different approach to complete your project. For example, create a more people-intensive process versus using automation that won’t be available on time. In other cases, an invalid assumption may mean cancelling or postponing the project is the best course. Discuss these possibilities with the sponsor in advance.
  • Plan around assumption validation events. You will validate assumptions such as government approvals or legislation being passed at specific times during your project. Treat these as significant milestones. Schedule meetings to confirm your plans going forward, such as modifying or cancelling the project. Communicate those potential outcomes and plans going forward with your key stakeholders. 

How do you manage project assumptions? Have you experienced any challenges not mentioned here? Have questions? Share with us in the comment section.

For more about project assumptions, check out my Project Management Foundations course.

_______________________________________

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

_______________________________________

Keys to Successful Integration Projects

/in /by

Photo by Chris Hardy on Unsplash

 

The world gets more complex and intertwined, which creates more projects involving complex integrations. What is an integration? It’s when separate systems or components are brought together to build a seamless solution. For example, building a satellite means integrating a propulsion system, navigation component, scientific instruments for research, communication components, and others. Here are crucial keys to managing an integration project successfully.

  • Approach the project in four phases: Define-Decompose-Build-Recompose.
  1. Define the entire integrated solution in detail. 
  2. Decompose that solution into pieces that separate expert teams can work on. 
  3. Build the solution, where the expert teams construct those pieces (systems or components).
  4. Recompose the components or pieces into a solution. 

Less experienced project managers might try to shortcut these steps. For example, they don’t decompose the solution fully and overlook an integration element. Let’s take our satellite example. Say the communication component is combined with the scientific instruments. That could lead to overlooking the integration between the communication system and the propulsion system (so people on the ground can reposition the satellite).

  • The best management flow is Centralize – Decentralize – Recentralize. Experienced integration project managers understand that success means giving up some control.
  •  As the total solution is defined, management is centralized and controlled by the project manager. 
  • When the product is decomposed and the expert teams are working on their components, management is decentralized. The project    manager releases control. Teams still report status and risk status to the project manager. But the teams work under their own management, exercising their specialized expertise. 
  • When components are integrated (recomposed), control is re-centralized. This affirms the accuracy of integrations. It also resolves any discrepancies between the expert teams. 

You can hamper the build effort and increase time and cost if you try to exercise too much control while components are under construction.

  • Understand the start-and-stop points of each component. The project phases and management flow depend on one critical element: the clear definition of components. It’s crucial to know where each team’s responsibilities begin and end, and where the technical component integration points lie. Using our satellite example, the scientific experiments include a communication element to share the output from the research performed. The overall communication module shares those research results and other data with staff on the ground. So you need to define in detail where the communication role of the scientific experiment modules end and where the primary communication module takes over. 

Integration projects amplify the risk of errors occurring, particularly when the expert teams are not co-located. Risks expand further when multiple unrelated vendors need to come together to integrate an overall solution. Carefully define your components and integration parameters!

  • Ownership of testing needs to be defined specifically. Don’t try to ask two teams to build their individual components and be responsible to “test the integration.” That usually ends badly. Project managers need to decide who specifically will take the lead on testing each integration in the solution. Often, an independent test owner works best. This person isn’t a member of either team with integrated products. With an independent test owner, you reduce the occurrence of pre-conceived ideas about how the integration should work. Also, the independent test owner will evaluate results more objectively. 
  • Add a lot of time and money to manage integration risks. This is the most under-estimated aspect of any project. Be conservative when estimating the cost of testing and completing integrations. Add at least 50% (yes, 50%) of the cost of building the separate products that will be integrated — to accommodate testing and correcting integration. Lots of unexpected things can happen. Errors often take a lot of time and effort to resolve. It’s better to surprise stakeholders with a less costly integration event than to explain why you need more time and money to make something work. 

Have any good stories about integration projects to brag about? How about horror stories that we can all learn from? Share with us in the comment section.

_______________________________________

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

_______________________________________

Negotiating Project Deadlines

/in /by

Photo by The Jopwell Collection on Unsplash

Have you ever had to negotiate a project deadline with your project sponsor? It’s daunting, but being prepared makes the interaction easier. Here are my top four tips for preparing to negotiate a project deadline.

  • Identify what’s driving the deadline. Ask questions about desired deadlines and what drives those dates. It could be a legal mandate, a desire to beat a competitor to the market, or pressure from the Board of Directors. By understanding the deadline pressures, you can address those considerations head-on. Adjusting the scope or bringing in experts might help you meet a mandatory deadline.
  • Research your project. To negotiate effectively, you need to know as much as you can about the project, particularly the project timeline, staffing challenges, scope, and potential risks. Don’t discuss deadlines until you complete that homework, so your discussion can be more informed and meaningful. If your negotiation identifies other items or risks, ask for time to research them.

Giving a timeframe without doing research is irresponsible. It would be like your car mechanic telling you what’s wrong with your car and quoting $1200 without looking at it. You probably wouldn’t trust that estimate! So, look under the hood before you agree to an estimate and project deadline.

  • It’s the sponsor’s project! Negotiation should be about sharing information and coming up with the best outcome. The result could be an aggressive project deadline. Remember, it isn’t the project manager’s job to prevent the sponsor from taking risks. Your job is to make sure the sponsor understands the risks they’re taking and the associated impacts. Try proposing alternative solutions that could make the deadline more achievable. This can include staffing, scope reduction, or delivering the project in stages.
  • Document assumptions. Once you have agreed upon a deadline, be sure to capture any assumptions you’ve made, such as staffing levels from operational personnel. Often, operational staff members get pulled from a project into day-to-day business dealings, which impacts your project progress and puts the deadline at risk. Other assumptions could be the availability of certain technologies or vendors to assist with project deliverables. Ensure that your sponsor and key stakeholders understand these assumptions. Track progress against these assumptions and report when any deviation occurs. That way, you can react to make corrections to meet your deadline.  

Do you have other tips for negotiating deadlines? Have you come across obstacles with deadlines that you don’t know how to resolve. Add your comments and questions to the comments section.

_______________________________________

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

_______________________________________

Supporting Your Sponsor’s Decision Making

/in /by

 

Sponsor decision making

Photo by Scott Trento on Unsplash

Sponsors provide financial support, champion the project and make key decisions. So, it’s crucial that you understand how your project sponsors make decisions. By watching for these types of decision-making, you can adjust your approach to get the best decisions and support your project’s success.

  • Fact-based decisions. Project sponsors want facts and data they can use to guide their decisions. For fact-based decision-makers, you need to know the data sources they value most. For example, internal trusted advisors or external entities like consulting companies. Find the data and the data source that your sponsor values to help them make decisions.
  • Intuition-based decisions. Leaders with sponsorship experience are often swayed by their intuition, which helps produce quick decisions. To support this type of sponsor, identify when they’re using intuition for decisions and then validate the assumptions they make. That way, you reduce the risk that flawed intuition presents.
  • Decisions based on team experiences. Many sponsors will poll their team members before making decisions, because they value the team’s experiences and opinions. This typically results in more buy-in from the project team. However, attempts to  gain consensus can delay decisions. For this approach, add buffer time to the schedule to offset these delays.
  • Political decisions. All too often, sponsors make project decisions from a political standpoint. Their bosses or other key stakeholders have expectations and sponsors hesitate to make decisions that may disappoint those stakeholders. While these decisions can be sound, they may add risks. Work with your sponsor to make sure you both understand those risks and their potential impact.
  • Market-driven decisions. The driving force for a sponsor’s decision making could be what’s happening in the marketplace. That makes sense because project success often depends on leap-frogging the competition. With a market-driven sponsor, keep a close eye on the status of the triple constraints (scope, cost, and time). Scope is often fixed, so you need to watch how that affects cost and schedule.

Have you seen other types of decision-making? If so, what advantages and disadvantages did they present? What can you do in those situations? Share with us in the comments section.

_______________________________________

This article belongs to the Bonnie’s Project Pointers newsletter series, which has more than 33,000 subscribers. 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 If I Don’t Agree with the Project Business Case?

/in /by

Photo by ThisisEngineering RAEng on Unsplash

What should you do if you don’t agree with the project business case? The answer depends on what about it makes you uncomfortable.

The project business case is the foundation for the project. Get it wrong and the likelihood of a successful project is low.  Here are four issues you might have about the business case and what you can do in each situation.

  • If you believe the business case data lacks integrity: Immediately discuss your concern with your sponsor. Compare your experiences with what’s in the business case and work through the differences. Be upfront about how your experiences differ from what’s in the case and the concerns you have because of your intuition. The business case sets expectations, so you’ll eventually compare project outcomes against the business case. Don’t wait until the end of the project to challenge the business case. Act now!
  • If you’re concerned the business case is too risky: Identify your sponsor’s risk profile. Your role is to ensure your sponsor and key stakeholders understand the project risks. Your role is NOT to ensure risk goes away. When you’re concerned with business case risk, point out the risks to stakeholders and develop response plans. Focus on the costs of executing those response plans. When you understand the level of comfort your sponsor has with risks and potential costs, you can support the business case accordingly.
  • If the business case was not built collaboratively: Review the business case with key stakeholders. They usually focus on their own interests and perceptions of risk and may be uncomfortable with the business case or its approaches. Hold discussions to analyze and align the business case with key stakeholders. Moving forward with a business case that hasn’t been reviewed and agreed upon makes it difficult to get staffing and decision-making support.
  • If the business case doesn’t address a specific problem or business opportunity (the WHY of the project is unclear): Ask your sponsor and key stakeholders questions to try to discover any alignment around the purpose of the project. In the interest of scope and clarifying the WHY for the project, recommend edits to the business case. If those recommendations are approved, transfer those clarifications into the Project Charter. If you can’t find alignment on a purpose, recommend against launching the project. If the sponsor decides to go forward with the project, add a risk related to identifying the purpose of the project. Ensure you include risk review points where scope expectation differences could cause trouble.

Have you found other issues with project business cases? What were they and how did you deal with them? Share with us in the comments section.

_______________________________________

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

_______________________________________