PMP Certification Training: Business Value
Free PMP Training: Business Value
The PM PrepCast is your complete PMP training. With over 35 hours of in-depth video lessons it is a complete PMP online course. Please enjoy this free lesson:
Summary
Projects don’t have to be 100% complete to be valuable. Many projects begin accruing value at very early stages, and there are approaches that can help ensure value is realized as early as possible. This task is part of the Process domain and has three enablers.
Until Next Time,
Cornelius Fichtner, PMP, CSM
President, OSP International LLC
Transcript
F03.01 Business Value
[00:00] [Introduction]
Hello and welcome to The PM PrepCast™, your one-stop shop for all information that you need in order to complete your projects in time and on budget while delivering busines value. I’m your instructor, Cornelius Fichtner. Yeah, so projects don’t have to be 100% complete to be valuable. Many projects begin accruing value at very early stages and there are approaches that can ensure that value is realized as early as possible as well. This task is part of the process domain. It has three enablers, let us take a look.
[00:48] Executive Project with the Urgency Required to Deliver Business Value
First is assess opportunities to deliver value incrementally. Here, we want to plan for ways to begin seeing a return on investment sooner than later by delivering working components of the project as soon as they are ready. And this will provide value to your customers, revenue for your company, and possibly allow you to capture feedback as well to guide your next steps. Examine the business value throughout the project. Knowing the current value of your project will ensure that you are staying on budget and delivering a solution that truly benefits your customer. We will discuss the various types of value some of which are less obvious than others. And lastly, support the team to subdivide project tasks as necessary to find the minimum viable product. Otherwise known as the MVP, the minimum viable product, is the smallest set of working features that provides value to the customer. An MVP can be released quicker than a fully-featured solution and then analysis of customer usage can help you prioritize which features should be worked on next. That’s it for this quick overview. And we’re now going to discuss business value incremental delivery and minimum viable products in more detail and I will tie it together at the end with an example that you and I can very much relate to. However. We begin with an example that illustrates how a phased approach can give your users a working product quickly while the remainder of the project is still underway. Bridges like the one you see here. This can be built in a single phase or through an iterative development process. Here’s how.
[02:54] Single Bridge
Traditional thinking when building a bridge says: You build the bridge all at once. You could start from one side and build toward the other. Or, start from both sides and meet in the middle. Either way, the result is a single bridge that isn’t very useful until all the work is complete. Half-built bridges, they do not deliver any business value because nobody is able to cross the river. Once motorists, however, are able to drive across the bridge without falling off midway, then business value has finally been delivered.
[03:35] Twin-Span Bridge
But, let’s now consider a twin-span bridge. This is technically two smaller bridges, each one representing half of the original bridge’s throughput. In the first stage, we focus on building one smaller bridge using a fraction of the overall resources required in order to be completed. Obviously, it cannot carry as many vehicles at the same time as the full bridge would, but motorists can safely cross. This means, it has value already even though the work isn’t fully completed. Once Stage 2 completes, then the bridge will be at full capacity bringing the maximum possible value to motorists, who will likely have already been enjoying the bridge at half capacity. Even though it took a while to reach the final stage of the bridge, business value was delivered all along.
[4:34] Tangible Versus Intangible Value
Alright! So obviously, when we talk about business value, it’s easy to assume that we are talking about money. But, that isn’t always the case. There are many ways that something can bring value that might not be obvious. Tangible value is the most commonly thought-of type of business value. These are things that you can see or touch, and sometimes they are literally cash flow. Revenue is probably the first thing that, well yeah, comes to everybody’s mind. This is when cash is flowing into your organization for goods or services rendered. Sometimes cost savings are even higher than the revenue. This is typically the result of a project that improves efficiency in some way. Financial assets and facilities, these are the physical items and buildings that a company owns and operates. These are valuable in and off themselves. Market share, that could denote how successful a company or its products is compared to others who are selling the same product of service. A project that increases market share often increases other types of value as well. Intangible value is a bit less obvious at times. You can’t see or touch it, and you generally can’t associate it with a dollar amount. A project that enables new strategic options for a company’s future is valuable even if it doesn’t directly earn money. Improving the organization’s reputation amongst its competition; that is valuable. Similarly, trust and goodwill, doing something for the public good. Something that improves peoples’ lives in some way is quite valuable. It endears a company to the public in a way that could grow the customer base or maintain customer loyalty. And finally, intellectual properties, such as inventions, patents, and copyrights add value by protecting a concept that is critical to our organization. This can provide an edge in competition.
[6:52] Iterative vs Incremental Delivery
In our example with the bridge, we discussed how this bridge project could be completed all at once, and then we saw how it could be done in pieces to provide value sooner. Let’s now look at how we can approach dividing such larger efforts into smaller ones. The verb ‘to iterate’ means to perform repeatedly. So, when we say we work iteratively, we are saying that we will revisit previous work to improve on it. You can think of each repetition as a loop, and each loop aims to take what was done in the previous loop and improve on it in some way. It could be adding a new feature that wasn’t there previously. Or, it could be enhancing a feature that already existed. In Iterative development, once all the project has been completed through iterative evolution, the final product is now ready for release. Incremental development and deliveries suggest, on the hand, that a project be broken into pieces such that each piece can now be released on its own. Work is divided into these cohesive pieces like the first half of the twin-span bridge in our example. This could be seen as the first of two increments that we deliver. Just like in the iterative approach, each increment could be an enhancement over the previous. But the key difference between these two is that incremental results can be provided to users prior to the project completion. This way, business value can be earned much sooner in the project life cycle.
[8:44] So What’s The Difference?
To better explain the difference, allow me to take you to our PrepCast discussion forum where our student, Tahar, asked the following: I am struggling to understand what difference there is between iterative versus incremental life cycles? Well, luckily, we have a really great discussion forum, and we also have 12 community moderators and here are two responses that Tahar received. First, we have Steven Mudrinich, who responded with this explanation: “The main difference between them is that an iterative process makes progress through continuous refinement, while an incremental process makes progress through small increments. So, if I am a project manager for a software project, an iterative approach would be to initially build the overall product, and then refine the weak areas. While an incremental approach would be to build each individual area one at a time. Generally, an iterative product will get to market before an incremental product. But, the incremental product will be more complete when it is initially released.” And then second, Luke Ho gives us this example here: “An example of an incremental life cycle is developing a fully-functional website. There is a new functionality being added to the website for each iteration, but the full website is delivered to the customer at the end of the project. As for iterative life cycles, think of a demo, a prototype of that website that you build and then let the customer decide to proceed with the full-blown product.”
[10:40] Iterative + Incremental
Well, yeah! And now that we know what iterative and incremental approaches look like, let’s imagine how we can benefit by combining the two. The iterative incremental approach allows a project to benefit from the best of both worlds. Work is still being performed in feedback loops. Each iteration still improves on what came before it. But now, the result is delivered to the user after each iteration. This means, the project team can receive feedback from customers very early on in the project life cycle and the information that is gained can help steer the course and correct it. The entire trajectory of the project may be different in the end. It is always possible that internal stakeholders are not aligned properly with the customer needs. So, what better way to maintain that alignment to the customer than by presenting your customer with a working solution as quickly as possible? Yeah, and in order to accomplish this though, each iteration needs to deliver a working product increment. It won’t have all the bells and whistles yet, but it gets the jo done. And at that point, we can more confidently say that the project is already providing business value while the product is still under development.
[12:12] Minimum Viable Product
Remember how I said that the information that is gained from iterative and incremental delivery can help steer or course correct the entire trajectory of the project? Well, this is the key premise behind the idea of an MVP, the minimum viable product. So, a minimum viable product is a product with enough features to attract earlier-adopter customers and validate a product idea early in the product development cycle. Because the Agile methodology is built on validating and iterating products based on user input, the MVP plays a central role in Agile development. MVPs allow a product team to collect useful feedback from customers about the product without having to build the entire product. Once the MVP is launched, initial feedback is collected and based on this feedback, the team will reiterate to fix the bugs and introduce new features that those early adapters suggested.
[13:27] The MVP Approach
A company might choose to develop and release an MVP because it’s product team wants to attract early adopters and release a product to the market as quickly as possible giving them a competitive advantage. They might also want to test an idea with real users before committing a larger budget to the products full development. Makes sense, right! Who wants to waste time and resources working on a product that nobody wants and will not succeed in the market? If your new product or service fails fast and cheaply, you will have the time, energy, and resources to try something else. And keep trying until you have a hit. And a product team may also want to release an MVP in order to learn what resonates with the target market and what doesn’t. In turn, the team can work effectively towards developing a fully-fledged product that integrates user feedback and user suggestions. Henrik Kniberg, who is a certified Agile and Lean author and coach, came up with a metaphor to help illustrate the MVP concept. Now, imagine that your customer orders a car, but you don’t just build a car. Instead, you focus on the underlying need that the customer wants to fulfill. Let’s say the underlying need is: I need to get from point A to point B faster. And a car is just one possible solution to that. Remember, a car is just a metaphor. Think of any customized type of product or development situation.
[15:21] [Product Development]
So, in response to that need, your team delivers the smallest thing that they can think of that will get the customer testing things and giving you feedback. In this case, a skateboard. The skateboard is actually a usable product that helps the customer get from point A to point B. But, is the customer happy? Well, no, not really. He still wants a car. But in the meantime, he is usually using this product and giving you feedback. As you continue to release iterations and gather feedback, the product morphs into a scooter, then into a bicycle, then a motorcycle and ultimately, it becomes a car. A car that actually meets your customers’ needs. This is the value of doing iterative and incremental product delivery. Maybe you were initially planning on building a large gas-guzzling SUV. But along the way, you learned that your customer is environmentally conscious and appreciates a car with good fuel economy and reduced emission. So in fact, we ended up with an electric car. We just saved ourselves and the customer a ton of time and money and deliver the better product in less time. Well, and now you may be thinking: But shouldn’t we already have known what the customer wanted by collecting the requirements upfront? That’s a good point. But in most real-life product development scenarios, it’s not so simple. You’d be surprised how often a company will put the final product into the hands of their customers and then discover that many of the assumptions turned out to be just plain wrong. We call this scenario the innovator’s nightmare. Gathering requirements upfront is important. But, don’t rely on that alone. Start prototyping and releasing instead. That’s where the real learning happens.
[17:34] [Quote]
Ultimately, your goal is to introduce a product, service or solution that fits the market’s needs. Like Alberto Savoia said: “Make sure you’re building the right ‘it’ before you build ‘it’ right!”
[17:53] Minimum Viable Product (MVP)
You’re maybe wondering what all of these looks like in practice. Well, here we go. Before the first incremental release can happen, some planning needs to take place. Around what exactly should be included as part of the release? Customers or other stakeholders may have dozens or even hundreds of features in mind for the product. And not all of them can or even should be developed in the first iteration. The project team and relevant stakeholders, they need to discuss the features and determine which ones are absolutely needed to deliver the product or service or result and which ones simply improve on it. The project team can then develop a prototype to rapidly test the basic ideas and assumptions behind the product. Now, this might sound eerily similar to a minimum viable product, but in essence, a prototype is the foundation for what will become the minimum viable product. The MVP is created once you have tested out any hypothesis through prototyping and gotten proof of the concept. So, an MVP is a prototype at heart but further along in the product development process. Then the set of features that are the only ones completed necessary can now be bundled together in a first release. Yeah, the MVP. Remember, the goal of the MVP is to do the least amount of work that is required in order to deliver the product and validate the product idea with early adopters. The MVP has no fancy balls and whistle. It’s often isn’t really pretty and that is why it is sometimes called a walking skeleton. Here you go! And almost certainly, it doesn’t have hundreds or thousands of hours of perfection applied to it. It simply gets the job done as directly as possibly, but most importantly, it can be placed into customers’ hands. Since it is a usable version of the product with just the core features or features that are ideal for testing, you will want to share with the biggest number of people. And if that isn’t feasible, then testing on even a single user will teach you more than doing nothing. Alright. And then the final product is released in the market only after getting sufficient feedback from the products’ initial users. But we can see in this graph, an MVP can provide business value long before the product is mature, as well as before work cost climbs higher and higher and higher. When it comes to timing, these phases are pretty flexible and there are no ideal length for each phase. For instance, sometimes an initial concept is entirely obvious and you can move quickly to prototyping and MVP development. Other times, you might spend months doing market and customer research before you proceed to the next step.
[21:15] Example: The PM PrepCast
And now, as promised, let me give you an example that will bring everything together. An example, you and I know very well, of a product that used iterative, as well as incremental, and then also an MVP at the same time. Because you’re watching it right now. It is this product here, the PMP Exam training course called The PM PrepCast. So, first of all, we recorded a prototype lesson like you’re watching right now and we sent that out to a focus group. And then, we got feedback from the focus group. And for example, they said: ‘Your background needs to be better. It was very plain.’ So I improved my background. They also said: ‘Cornelius, those headphones that you are wearing,’ I used to wear this really big headphones with a microphone like this here, ‘that doesn’t work. You really need to get rid of those.’ So, we did. As you can see, the background has changed and I am now using this much, much smaller microphone here, alright. Then, we rerecorded the prototype and we showed it internally to our other stakeholders. And one of them said: ‘Why don’t you have a mystery object back there?’ That was actually me who suggested that. Why don’t we put a mystery object behind you, a little bit of gamification there in the process as well. So, it’s something different to look at behind me all the time, and wonder: ‘What is that today?’ Alright! So, there’s that! And then we just continued doing that until we had the final look and feel of the lessons as you see them now, okay. And then, we moved on to the MVP. The project manager and I decided that our minimum viable product is going to be the people domain. So, we want to record all the lessons, about a dozen or so, within the people domain and publish them and get them out as the minimum viable product. And once the minimum viable product is released, we will then continue incrementally to record, publish, and repeat every lesson that is not part of the people domain. Now, you might be thinking to yourself: Ah, so this lesson here is part of the process domain. That must mean it was recorded after the minimum viable product was completed. Well, wouldn’t it be nice if everything always worked out the way you had it planned? It wasn’t. because this lesson that you’re watching right now was finished before the MVP was done. I still have a couple of lessons to record for the MVP. So, we’re recording out of order, completely, right? We don’t record these in order. We record whatever lesson is finished, and this lesson here just happens to be finished before the MVP was finished. So, it became part of the MVP and from where I’m sitting right now, it will be released as part of our MVP. So, there you have it. An example that includes iterative, incremental, and MVP that you hold in your hands.
[24:49] Takeaways
Yes! And this concludes our lesson on business value. Do keep in mind that many projects can deliver value to customers prior to project completion and start realizing benefits sooner than later. Value comes in many shapes and sizes. Organizations undertake projects with any combination of tangible and intangible values in mind. Most commonly, however, revenue is being sought but intangible benefits like goodwill and intellectual property can change a company’s trajectory. Iterative and incremental development processes are powerful tools on their own. But when combined, they form a method of repeatedly improving upon a solution while continually delivering that solution to customers, and the early feedback from those customers can shape the future of the project. The goal of the first release should be the minimum viable product. It contains only what is needed to attract early adopter customers and validate a product idea early on the produce development life cycle. Building towards an MVP will place the product in customers hands much, much sooner and allow for value to be realized well ahead of project completion. And that, brings us to the end of our discussion on business value. Thank you for joining me today.
Until next time.
[End of transcript]