Hello and welcome to the Parallel Project Training podcast. These podcasts are being recorded for the APM PMQ syllabus, which will be used for exams starting in September 2024. My name is Ruth Phillips, and I’m here with Lisa Regan, one of Parallel’s senior trainers. Today, we’re going to be discussing solutions development. Welcome to the podcast, Lisa.
Hi, Ruth. I’m looking forward to discussing this topic.
Great! As with all our podcasts, we’re using the PMQ syllabus as our guide. The APM defines solutions development as the ability to determine the optimal solution to satisfy agreed requirements. We also have another podcast on requirements management, which might be useful to listen to alongside this one. Solutions development is a relatively small, self-contained topic within the syllabus, with just one learning objective: to know how to evaluate and prioritise requirements in order to deliver the optimal solution. So, Lisa, what do we need to do in our projects for this?
This is where options appraisals come in, which are really about evaluating different options. We start with the business case, where these options are considered, and it’s crucial not to forget the “do nothing” option. It’s important to assess what would happen to your organisation if the project didn’t go ahead—what are the implications of that? Sometimes, the “do nothing” option can be a compelling reason to take action, especially if there’s a legislative change, regulatory change, or if an IT system is no longer supported. In such cases, “doing nothing” isn’t really an option—it’s what we used to call the “burning platform” scenario.
That’s right. I was reflecting on options appraisals and realised that in my project management career, I haven’t always given them the attention they deserve. This is often because options appraisals are done during the concept phase, and by the time I’m involved, the project plan and resources are already set.
That’s an interesting observation because if the requirements can be met by very different solutions, those solutions would essentially be different projects, each with its own plan, budget, and benefits. Often, some form of feasibility study is done during the concept phase to determine the best solution before the project is formally launched.
Exactly. So, when involved in this process, it’s essential to consider the acceptance criteria—whether time, cost, or other factors are the most critical, as these will constrain your options. You also need to consider user priorities, as they may have different perspectives. The choice of lifecycle approach, whether linear or iterative, will also influence your options. In a linear lifecycle, decisions must be made upfront, while an iterative lifecycle allows more flexibility and evolution of the solution throughout the project.
Yes, iterative lifecycles are more open to exploration and evolving solutions, whereas linear lifecycles require a clear decision at the start. It’s also important not to be swayed by stakeholders’ preferences, as their favourite option may not always be the best one. Sometimes, people have pet projects without realising it, so it’s crucial to explore different options thoroughly. This is essentially a problem-solving activity, where brainstorming can be very effective.
The syllabus also mentions prioritising requirements to deliver the optimal solution. Is there a particular technique you’d recommend for this?
The MoSCoW technique is very effective here, categorising requirements as Must Have, Should Have, Could Have, or Won’t Have. Although typically used for scope prioritisation, MoSCoW can also help prioritise options. Another useful approach is conducting an investment appraisal to compare the financial viability of different options, which takes the emotion out of the decision-making process.
Involving stakeholders in this process is important to ensure all requirements are considered, and being open to different options is key. It’s also essential to think about practicalities, such as whether the market can supply the materials or resources needed for a particular option.
A method I like, coming from my background in Japanese manufacturing, is the Five Whys technique. By repeatedly asking “Why?” you can uncover the root reasons behind a preferred option, which can reveal unconscious assumptions or deeply ingrained practices that might be limiting innovation.
That’s a great approach. Particularly when user requirements are driving the decision, you might be constrained by their technical knowledge. There are always new materials and techniques that they might not be aware of, so it’s important to dig deeper.
The syllabus also asks us to understand different approaches for different lifecycle models. We’ve already mentioned that in a linear lifecycle, the optimal solution needs to be decided upfront, whereas in an iterative approach, the solution evolves throughout the project. The syllabus refers to MVP and MMP in iterative lifecycles. What do these terms mean?
MVP stands for Minimum Viable Product. When I first heard this term, I was put off by the idea of producing a “minimum” product, as it seemed like settling for less. But it actually refers to the first version of a product with just enough features to gather feedback. The key is that it’s viable enough to be tested with users to gather their reactions and make improvements.
That early feedback is crucial because it allows you to make changes before you’ve invested too much time and money. There’s a saying in iterative and agile projects: “Fail fast.” The earlier you identify what doesn’t work, the less costly it is to fix. An MVP allows you to fail fast, make adjustments, and minimise risks.
Absolutely. The further along the project you get, the more costly it becomes to make changes. An MVP allows you to test and refine the product early, reducing the risk of delivering something that doesn’t work.
The other term is MMP, which stands for Minimum Marketable Product. After multiple iterations of an MVP, you develop an MMP, which is a version of the product refined enough to be launched to the wider market, not just for testing. It’s about being market-ready—something you’d be proud to present to the world.
Yes, and it also implies that the product is good enough to be monetised and marketed. You made me think of the development of Facebook, which started as an internal product used by Mark Zuckerberg and his college friends. This was their MVP—something basic but functional, which they could gather feedback on. When it became publicly available, it evolved into the MMP.
Exactly, and it continued to evolve with new features being added as the platform grew.
Fantastic. That’s solutions development in a nutshell—developing the optimal solution by evaluating and prioritising requirements, and using different approaches depending on the lifecycle model. We’ve focused on the iterative lifecycle and the use of MVP and MMP concepts in iterative projects.
Thank you for your insights, Lisa. It’s been a really interesting discussion.
No problem. Thank you, Ruth.
Thanks. Bye.
