Are You Scared?

Size and Uncertainty

It might seem like an odd question to ask a Product Manager, but here goes … Are you afraid? If you’re working on a non-trivial, interesting product, of course you are! If you’re not at least a little afraid, you’re probably not being adequately challenged.

A better question to ask is: how afraid are you (or should you be!) about your organisation’s intentions for your product? Going even further: What impact does this have on the best ways to steer product efforts? What lessons have already been learnt about how to effectively deal with and manage this kind of fear?

It’s common knowledge that agile methods came about precisely because on most technology projects, scope has most uncertainty at the beginning, and scope uncertainty only reduces through continuous learning as the projects progress.

One way to get started in understanding the impact this has on the best approach to product management is to consider the range of all possible product initiatives on a scale of uncertainty. At the risk of stating the obvious, the less uncertainty there is, the more you can lean towards waterfall or step-by-step phase-gated project approaches. Conversely, agile methods come into their own for initiatives with more uncertainty. This can be represented as a spectrum of uncertainty: as uncertainty increases, agile methods become more appropriate.

Size1.jpg

Equally important is the project management approach and amount of rigour applied. A single project (for example, building a customer invoicing product) requires a different management approach to a portfolio of projects (for example, building all the modules that make up a full ERP system). We can represent this on a spectrum of project management approaches according to size: as size increases, more rigour is required.

Size2.jpg

At this point it is worth noting that project size is very closely related to project complexity. In fact, leading authors have explicitly called out size as the reason for complexity in large software projects, simply because as projects get bigger, interactions between elements of the system increase in a nonlinear way. For example, this is from the Fred Brooks 1986 classic No Silver Bullet:

…a scaling-up of a software entity is not merely a repetition of the same elements in larger sizes, it is necessarily an increase in the number of different elements. In most cases, the elements interact with each other in some nonlinear fashion, and the complexity of the whole increases much more than linearly.

What this means is that uncertainty and size are intimately related. If we plot uncertainty against size, we can see that each product initiative has a unique position on a 2-dimensional map. This position can be used to get a handle on when it is appropriate to apply which techniques.

It is impossible, of course, to determine the absolute uncertainty and size of a given initiative ahead of time. However, it is useful to consider the relative position of initiatives within your organisation’s context, on a chart of size plotted against uncertainty. This can inform as to the best product management approach to apply in each circumstance.

Size3.jpg

To help visualise how this applies practically, consider some familiar examples plotted relative to each other on a size/uncertainty chart.

Size4.jpg

Building a residential house is a relatively small initiative and it has low scope uncertainty. It can be considered as a single project and it is entirely appropriate to use waterfall together with conventional project management techniques.

Staging the Olympic Games is a large undertaking, consisting of many sub-projects. Yet it too has low uncertainty: after all, the Olympics has been run plenty of times before and the format remains largely unchanged, so we pretty much know the requirements upfront. It is appropriate to use waterfall, but this time with the significant added discipline and rigour of programme and portfolio management techniques.

Most mobile applications are relatively small projects, often with high uncertainty. Specifically, it is unlikely that the functional requirements are known in full up front, and the appropriate user experience (UX) can typically only be discovered with some level of trial and error. Agile methods are appropriate here, together with conventional project management.

A technology start-up is likely to be have very high scope uncertainty and potentially unbounded size. We know that agile methods are appropriate to help deal with the scope uncertainty and for all but the simplest examples, it calls for some form of portfolio management.

Size5.jpg

Taking this a step further, the diagram below shows common methodologies and when they are relevant in terms of size plotted against uncertainty.

Size6.jpg

PRojects IN Controlled Environments (PRINCE2)/Project Management Body of Knowledge (PMBoK): These methods were designed to bring discipline to individual projects, with low uncertainty. Both come with a significant body of knowledge and associated certifications. PRINCE2 was developed in the UK and is the most commonly utilised project management methodology in many industries and contexts. PMBoK was developed in the USA. PRINCE2 and PMBoK position themselves as complementary products – PRINCE2 as a “methodology” and PMP as a “standard”.

PRINCE2 Agile/DSDM: These are ways to apply the traditional single-project methods while simultaneously utilising agile methods to deal with uncertainty. PRINCE2 Agile combines agile principles with the discipline and governance of PRINCE2. The Dynamic Systems Development Method (DSDM) project lifecycle grew out of the Radical Application Development (RAD) movement in the 1990s, a precursor to modern agile methods.

Managing Successful Programmes (MSP): MSP is a framework for breaking large and complex changes into manageable, inter-related projects. It defines a set of programme management principles and best practices and is designed to be adapted to specific circumstances. Some MSP users include London Olympics and the UK Ministry of Defence.

Management of Portfolios (MoP): MOP was developed as a way to scale project management disciplines to the management of multiple programmes. It focusses on the needs of decision makers at senior levels and how to sustain progress across a range of parallel initiatives. MoP extends the programme and project management methodologies of MSP and PRINCE2 by putting focus on change management and organisation-level benefits realisation, rather than individual projects or programmes.

Scaled Agile Framework (SAFe) / Large Scale Scrum (LeSS) / Scrum@Scale / Disciplined Agile Development (DAD): These methods are appropriate for large projects with high uncertainty; the idea is to get the benefits of agile methods but at scales beyond single teams.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.