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.

_______________________________________

 

Dealing with Strained Relationships Between Senior Leaders

/in /by

business meeting

Photo by Cherrydeck on Unsplash

As a project manager, you need healthy relationships with influential senior leaders. That can involve dealing with relationship issues between those leaders. Here are pointers for dealing with strained relationships between senior leaders that can impact your project.

  • Understand the issues and impacts to your project. Resolving issues between senior leaders isn’t your job as a project manager. Don’t go there. You’ll waste your time. Instead, figure out what the issues are and how they might impact your project. That way, you can share those impacts as risks and work with your sponsor and the leaders to choose your response to handle them. Share when the risks are coming to fruition and launch your risk response. This approach may lessen the issues between senior stakeholders — at least as far as the project is concerned.
  • Leverage 1-1 meetings with senior stakeholders. Discuss the positive aspects and negative impacts of your project with influential stakeholders so you can understand the senior leaders’ perspectives.  That way, you can avoid unexpected concerns. Use this understanding to develop an approach that helps your project deliver the best outcomes for everyone. This might also reduce the impact of conflicts between senior leaders.
  • Refine your scope. When tension between stakeholders involves business concerns, design the project to minimize those concerns. Well-developed scope statements can address tensions around business priorities, process handoffs between departments, and process inefficiencies. If your project doesn’t address those concerns, propose a phase 2 or follow-on project to address your influential stakeholders’ needs.
  • Be a neutral supporter. Stakeholders who feel listened to are more likely to cooperate with project team members. You can enhance that support by understanding their issues and concerns, and then communicating that in your project. Key point! When stakeholders are in conflict, support them equally. You don’t want to be perceived as biased or favoring one stakeholder’s concerns over another’s. Informally share things you may learn during the project in 1-1 conversations, for example, an idea for streamlining a business process. This is more timely and personal than waiting for that information to be conveyed in a status report.

Do you have experience dealing with strained stakeholder relationships? If so, I’m sorry to hear that. If you have questions or solutions, share with us in the comments section.

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

Coming Up

On March 20, 2023, at 12PM MT, I’m joining Angela Wick on a live broadcast to talk about how project managers and business analysts work together. It’s going to be fun and informative. Bring your questions! To sign up, click this link. https://www.linkedin.com/events/7036184580965470208/about/

______________________________________

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

_______________________________________

 

How to Be a Sponsor Whisperer

/in /by

Ever notice that some project managers always seem to have sponsor support? Project managers who successfully manage sponsors use a handful of techniques. Here are the go-to tools for “executive whisperer” project managers.

  • Get to the point in status reports. Status reports should be short and concise . Talk with your sponsor to understand their main concerns. Highlight information related to those concerns in your status report. While you still compile detailed information such as the status of individual tasks or the hours worked versus planned, it’s best to leave that detail in the background. Include links to the data in your reports so the sponsor can access it.
  • For longer discussions, prepare a short intro and let the sponsor lead the discussion. Senior leaders want to process information in the sequence most meaningful to them. Avoid pushing your agenda of what to share and when. Sponsors might not hear what you’re saying until they get the information they want. Deliver a short introduction – 30 to 60 seconds– to set the stage. After that, let the sponsor lead the discussion. Have data available that you can reference to answer questions. If you don’t have an answer, share where you can get it and follow up after the meeting. If information you want to share hasn’t been discussed, bring it up at the end of the meeting.
  • Know your stakeholders’ points of view. Project sponsors might not interact with other stakeholders on a regular basis. If stakeholders raise concerns, talk with them to understand their issues. Don’t assume your sponsor has this information. Your sponsor has a greater span of responsibilities than you, as a project manager. So, do the legwork on stakeholder issues to offload the sponsor. If you need your sponsor’s help talking with a stakeholder, brief them on the data they need. Share your recommendation and a clear goal for what you want from the discussion. Follow up on any actions that may result from the discussion with the stakeholder.
  • Make clear recommendations. The most frequent complaint from project sponsors is that project managers dump problems on them. Even worse, the problem might not be well-defined. To become a sponsor favorite, analyze the problems and come up with potential solutions. List the pros and cons for each potential solution and recommend a solution. That way, the sponsor can consider different business options, which improves sponsor confidence and helps them decide more quickly.
  • Be calm. Your mood rubs off on your project team and your sponsor. If you demonstrate confidence by being calm and diligently performing your role, your sponsor will be more confident. In turn, you avoid extra reporting and questions because you have your sponsor’s trust. Being calm doesn’t mean holding back bad news. If something is wrong, share it calmly, along with how you’ll address the problem. Follow up in whatever way your sponsor prefers.

Remember that sponsors are individuals with their own preferences. Take time to understand your sponsor’s expectations to improve your chances of success.

Do you have any tips for dealing with project sponsors – or questions about how to deal with them? Join the discussion by posting in the comments section.

For more about project sponsors, check out Antonio Nieto-Rodriguez’s How to Be an Effective Project Sponsor course.

Coming up:

October 2022 will be a busy month. My updated Project Management Foundations course is due to go live. And you can see me in several LinkedIn Office Hours live broadcasts.

 

October 12, 2022  11AM MT- Project Baselines: Basics and Best Practices

Once management approves a project, the project manager baselines the project. What is a baseline? What do you capture in a baseline? What happens when you create a baseline in Project? What are best practices for making baselines more helpful to managing projects effectively?

In this interactive Office Hours presentation, Bonnie Biafore and Ira Brown will share best practices at all stages of baselining.

Link to the event- https://www.linkedin.com/video/event/urn:li:ugcPost:6978438578267664385/

 

Oct 17, 2022  11AM MT- Leading with Curiosity

Questions and answers are inputs into any system or project, and they drive the output — whether the system is making dinner or launching a new product. The more diverse the inputs, the more innovative the output! Asking the right questions from the outset is crucial to setting up a system or project for success and achieving the best outcomes. To turbocharge results, you need to go beyond the usual questions like “What is the goal for the endeavor?” and “What is the best strategy for achieving that goal?” You and your team need to be curious and creative throughout the endeavor. In this Office Hours session, Natalie Nixon and Bonnie Biafore will explore what it means for a cognitively and experientially diverse team to be curious and creative and what you, as a leader can do to support that effort.

Link to the event- https://www.linkedin.com/video/event/urn:li:ugcPost:6979155332908400640/

 

Oct 27, 2022- Sometimes, the hardest part of innovation isn’t coming up with the great idea. It’s implementing it. Across the organization.

If you are trying to lead your organization in thinking (or doing) differently, you need to balance inspiration and operations. In this engaging and interactive conversation, LinkedIn Instructors Bonnie Biafore (Project Management Foundations) and Robbie Kellman Baxter (Become an Entrepreneur Inside a Company) will share best practices in scaling your great idea throughout your organization.

Link to the event- https://www.linkedin.com/video/event/urn:li:ugcPost:6978746469797244928/

The Relationship Between Project Management and Supply Chain Management

/in /by

Guest post by Daniel Stanton, Mr. Supply Chain

Main point up front: Project management and supply chain management are both relatively new professions, and they are highly complementary. Supply chain managers have always spent a lot of their time working on projects to reduce costs and increase efficiency. These days, many project managers are learning the hard way about “supply chain issues” and the risks that they can pose to a project. And there is a growing demand for supply chain project managers – professionals who have the skills and experience to lead projects and transform a supply chain. Aligning project management with supply chain management can help companies increase resilience, improve sustainability, and enable digital transformation. 

This newsletter was inspired by a recent conversation with Bonnie Biafore. If you know us, then it won’t be a surprise that Bonnie and I found ourselves talking about the relationship between project management and supply chain management. We agreed that project managers need to learn about supply chain management, and that supply chain managers need to learn about project management. You can listen to our chat here: 

Project managers can’t truly address the risks to their scope, schedule, and budget if they don’t understand the supply chain in which they are working. On the surface, this involves learning about the procurement processes and systems. But supply chain management is really about integrating all of the processes that a company uses for creating value, which goes deeper than just procurement to include operations management, logistics, and more. 

In many cases, project managers have to work with procurement people a lot more closely. (Bonnie Biafore) 

Supply chain managers can’t implement or adapt to changes effectively if they don’t understand the tools, rules, and language of project management. Project management is about delivering value by developing or changing products, systems, and processes. Depending on the situation, today’s project managers can draw on a range of tools such as Waterfall, Agile, and Lean Six Sigma. 

It’s particularly interesting to see the growing demand for supply chain project managers – professionals who have knowledge and experience with supply chain management, and who understand how to lead projects which focus on improving supply chains. (At last count, there were more than 20,000 job postings for Supply Chain Project Managers in the U.S. on LinkedIn.) Given the rapid pace of change that’s being driven by technology, geopolitics, and the pandemic, I think the future is particularly bright for supply chain project managers!

Project Management Tips for Supply Chain Managers 

Projects are how businesses make changes. Project management is about defining and balancing constraints such as scope, schedule, and budgets. There are lots of different techniques for managing projects that can be tailored to the needs of your business. In construction projects, you will typically use the predictive Waterfall technique. For manufacturing and distribution, it will often be a Lean Six Sigma approach. For software development projects, Agile techniques have become common. Regardless of the techniques that are used the project leaders always have six key responsibilities to their project teams, that I describe as the DIRECT framework: 

  • Define the objective. Be clear about the change that needs to happen.
  • Investigate the options. Research alternatives and benchmark with others.
  • Resolve to a course of action. Build a plan and get buy-in from your stakeholders.
  • Execute the plan. Monitor the progress and address challenges as they emerge.
  • Change over to the new systems and processes. Manage your acceptance and launch.
  • Transition the people. Make sure that your stakeholders are prepared.

Supply Chain Management Tips for Project Managers 

A supply chain is a complex network made up of people, processes, and technologies that is engineered and managed to deliver value to a customer. Supply chain management requires you to view each business as part of a complex system that creates value for customers. In part, that involves integrating the internal functions in a company – especially procurement, operations, and logistics. But it also involves collaborating with customers and suppliers. In simplest terms, the goal of supply chain management is to get the right stuff, in the right quantity, to the right place, at the right time, for the lowest total cost. 

Supply chains are dynamic. How do we make improvements in a supply chain? By making changes. How do we respond to disruptions in a supply chain? By changing what we’re doing, or how we’re doing it. In other words, supply chain management professionals are responsible for launching and managing projects all of the time. 

The Supply Chain Operations Reference (SCOR) Model illustrates the six groups of processes that are key to managing the supply chain in any company. 

  • Plan. Develop your supply chain strategy and forecasts.
  • Source. Build and manage relationships with suppliers.
  • Make. Assemble products and create service capabilities.
  • Deliver. Take and fill orders from customers.
  • Return. Build and manage a reverse supply chain.

Enable. Manage all of the additional processes, including project management.

How does this affect supply chain professionals? Supply chains are how businesses create and deliver value. Projects are how we make changes in a business. Project management skills can help supply chain managers be more flexible and adaptable, and supply chain management skills can help project managers mitigate risks and be more resilient. Combining both skill sets can set you up to be a supply chain project manager, leading projects involving process improvement, sustainability, digital transformation, and more. 

What do you think? Have you needed to lead and manage projects in your supply chain? Would learning about supply chains help project managers anticipate and respond to risks? 

To watch the Office Hours session where Bonnie and I talk more about the relationship between project management and supply chain management go to https://www.linkedin.com/video/event/urn:li:ugcPost:6958149360392056833/. 

Choosing the Right Dependency Between Project Activities

/in , , /by

The schedule logic for a project is the collection of dependencies you create between activities. The goal of this schedule logic is to provide a realistic model of when project activities should occur. Want to up your scheduling game? This article explains when to use each dependency type to link activities.

Finish-to-start is the one you’ll use most often. A finish-to-start dependency tells you that when one activity (called the predecessor) finishes, the next activity (the successor) can start. For example, you have to finish writing some code before you can test it. If you don’t work in software, maybe this example will resonate: when your older child teases the younger one, the younger one starts crying.

On the other hand, the start-to-finish dependency type is rare (which is a gift because it’s also confusing). This dependency means that the start of one activity determines when another one finishes. It’s confusing because the predecessor occurs later than the successor, as shown in the figure, and most people think of predecessors occurring before successors. (Remember, with dependencies, the predecessor is the activity that controls the timing of the successor, not when it occurs time-wise.) For example, consider a sales clerk who works a shift in a retail store. To keep the store open for customers, the clerk for the next shift has to show up to start his or her shift before the sales clerk on duty can go home (finish the shift).

Let’s look at the remaining two dependency types: start-to-start and finish-to-finish.

Suppose one person is scheduled to spend 10 days writing software documentation and another one is scheduled to work 10 days reviewing the documentation to make sure it’s accurate and clear. At first glance, you might think start-to-start and finish-to-finish dependencies work equally well. When the writing starts, the review could start almost immediately. Or, when the writing is complete, the review could finish soon after.

But start-to-start dependencies can cause trouble if activities don’t occur as scheduled. Suppose the writer runs into issues with the software and the writing task is going to take 15 days instead of 10. As you can see in the figure, the writing and review started at the same time, which means that the review is scheduled to finish 5 days before the writing. Some of the writing wouldn’t get reviewed unless you caught this error in your schedule logic.

The writing and review activities should be linked with a finish-to-finish dependency. That way, the schedule logic guarantees that the review doesn’t finish until the writing is complete, even if the writing takes longer. This dependency also works if the review takes less time than writing—say, 5 days. With finish-to-finish, you could wait 5 days before starting to review documentation, as shown in the figure below. If the writing takes longer than you expect, the delayed finish date for writing also delays the finish for review.

As you can see, almost all your dependencies will be finish-to-start or finish-to-finish. Another dependency best practice is to avoid negative lag (also called lead), because it implies that you know when the predecessor activity will finish. (You can explore this practice in this movie from my revamped and updated course, Project Management Foundations: Scheduling, which was released in April 2018).

A Cautionary Tale: When Good Communication Goes Off Track

/in /by

Good communication is important on the smallest of projects. My co-author Jim Ewing and I were in the middle of a very small project: designing the cover of the comedic thriller we wrote. Things were chugging along when suddenly design elements were in a big messy pile like the catch of the day. As our protagonist, Juice Verrone, would say: “Is this some kind of a joke?” Sadly, no. Our project was derailed (temporarily) by poor communication.

Here’s how it all started. Jim and I decided to use a design competition web site, 99designs.com. The project started down a familiar path. When Jim created the competition, he posted information that sounds a lot like a project summary: a book cover design that would work in color and grayscale for both print and eBook (the goal and scope rolled into one), the price level (the budget,) a description of the novel’s plot, ideas we had, a sketch I had drawn (requirements of sorts).

The design competition has a process, which we followed. During the first round, people submitted designs. Jim and I discussed the entries, provided feedback, and received revised designs. We rinsed and repeated over the several days of round one. It was all very agile. Round two was similar, although our feedback became more specific and detailed.

Several of the designers were from other countries. This international competition was a crash course in communication issues due to cultural, geographical, publishing, and other differences. Who knew book spines run in different directions in different countries? It was also interesting to see how our novel got renamed by non-native American English speakers. The book title, “Fresh Squeezed,” morphed into  the grammatically correct Freshly Squeezed on a few entries.

We picked a winner and explained that the real work was now beginning. We were going to work with the winner’s basic design and iterate to the final cover. This is when things got shaky. We made specific requests but the results that came back seemed to be further off-track. Colors that had been correct in previous iterations were suddenly wildly off base.

Jim was the point person so he tried reducing the number of changes in each iteration. He asked the designer to go back to an earlier revision that had the colors we wanted. But the results were still off.

Jim and I were confused and frustrated. Then I thought of a technique that Stephen Covey recommends. Instead of descending deeper into micro-management, I suggested he say “Help me to understand why we are having problems with the colors.” Turns out that the three-dimensional fish on the cover was created in one program. Then the colors and other effects were added in a second program followed by some clean-up steps. And finally that polished image goes into the book cover file. Every time we asked for a change to the fish, she had to jump through all those hoops (with the potential for glitches.) No surprise, those steps took her quite a bit of time–for every individual request we made.

Fresh Squeezed cook coverUnderstanding her process clarified the situation and led the way to a more effective change management approach. We worked on the fish without color effects to get its shape and facial expression right. Then, moved on to applying the color — once. With the fish complete, we could move on to the other elements of the cover. Finally, when all the elements were finalized, she laid them out on the book cover.

All along, we felt like we were communicating. But messages weren’t getting across. When we went from brainstorming into “production,” we were really moving from an early project phase (completed prototype or proof of concept) into project execution. We should have taken some time to plan how we were going to work, ask the designer questions about her process and how we could work with her most effectively.

The moral of this story: communication is crucial and requires careful planning, followed by care and feeding–even in small projects like our book cover. Remote or multicultural (or multi-anything) teams complicate the process. Finally, we can learn a lot about managing big projects from small projects we perform every day, which brings us back around to the importance of lessons learned!