Praxis delivery model

Introduction

“All models are wrong, but some are useful” is a statement attributed to the statistician George Box although the basic principle was well known before he summed it up so succinctly. Similarly, the French philosopher, Paul Valéry said “What is simple is always wrong. What is not is unusable.”

When Praxis uses the term ‘Project delivery’ it is referring to the management of projects, programmes and portfolios.

The world of management theory is awash with simple models that are wrong but useful, because the complicated ones are unusable. Many of these are described in the Praxis Encyclopaedia. Although they are not ‘right’ insomuch as they accurately describe fundamental principles that apply in all situations, they help project managers build a mental picture of the project delivery landscape.

This begs the question, why create another model? To answer this, we need to explain why the Praxis Framework exists. The underlying objectives of Praxis are to:

  • Integrate the four elements of organisational project delivery (knowledge, method, competence and capability maturity) into a single, consistent framework.

  • Unify the many different flavours of project delivery into a single, adaptable framework.

  • Describe the components of the framework in concise, discrete elements and structure the content in an accessible and intuitive way.

  • Provide tools and techniques that support the practical application of the framework and make good practice an effective and efficient habit.

The purpose of the Praxis Delivery Model is primarily to achieve the second objective and create a foundation for the third. 

The model provides a basis for describing the rich and varied spectrum of project delivery while retaining terms and concepts that are in common use. We hope you find it sufficiently correct and simple enough to be truly useful.

 

The underlying model

Like many models, the Praxis Delivery Model has two dimensions: ‘Extent of scope’ and ‘Uncertainty of scope’. These axes are the most appropriate when describing the many different processes, tools and techniques involved in the diverse world of project delivery.

 

 

On that basis the first thing to clarify is what is meant by ‘scope’. Scope must have limits otherwise the work is unmanageable. It should be clear what is included and what is not. Scope is everything that is included: the objectives and the work required to deliver them.

Scope is usually divided into ‘product scope’ (the objectives) and ‘project scope’ (the work to achieve the objectives). These are combined for the purposes of the Praxis Delivery Model.

Similarly, uncertainty could relate to uncertainty of objectives and uncertainty in how to achieve the objectives. These are also combined for the purposes of this model.

Scope is often uncertain and always changes, and at different points in the model, different approaches to effectively managing uncertainty and change will be needed.

The extent of scope, from simple to extensive, indicates the breadth and depth of what is to be performed and delivered. A simple initiative may only have one output to deliver while an extensive initiative may have multiple outputs with many-to-many relationships with multiple benefits.

The uncertainty of scope, from low to high, indicates how much we know about the scope at the outset. Building a house to a previously used layout has very low uncertainty while a manned mission to Mars has extremely high levels of uncertainty.

While the extent of scope and uncertainty of scope are the fundamental properties of an initiative, modern conventions of project delivery identify a number of paradigms. On the extent of scope axis these are projects, programmes and portfolios. On the uncertainty of scope axis these are predictive and emergent (more commonly, and inaccurately, referred to as waterfall and Agile).

 

 

The uncertainty of scope, from low to high, indicates how much we know about the scope at the outset. Building a house to a previously used layout has very low uncertainty while a manned mission to Mars has extremely high levels of uncertainty. Work with low scope uncertainty is often referred to as ‘predictive’, while work with high levels of uncertainty is often referred to as ‘emergent’.

The shading of the model indicates that most projects, programmes and portfolios lie on a band from bottom left to top right. While some simple projects might be highly uncertain, these are rare. Similarly, while some extensive portfolios may have low levels of uncertainty (for example, a portfolio comprising only simple projects), this is also rare.

 

Applying the model

The model has three practical uses:

  1. As a basis for describing the application of functions and processes in the Praxis Framework.
  2. As common ground to explain related models.
  3. As a reference point for tools and techniques.

This positions the model as the cornerstone of the framework. Everything else is derived from this model. As a result, Praxis is able to address the common categories of project, programme, portfolio, agile and waterfall in a single integrated framework and explain how they are relevant to all situations. It is up to a competent project delivery manager to decide where to place the emphasis and how to draw on a combination of these categories to effectively manage their work.

 

As a basis for describing functions and processes

The Knowledge section of Praxis is made up of functions, such as stakeholder management, risk management and benefits management. These are the functions that collectively comprise the discipline of P3 management.

The Method section is made up of processes such as identifying a project or programme and delivering a project or programme. These are the processes that describe the management of life cycle phases.

While these functions and processes are common throughout project delivery, the way they are applied depends on the extent and uncertainty of the work being managed.
Using the delivery model, the descriptions of the functions and processes can explain common principles and then go on to discuss their application in different contexts based on the extent and uncertainty of scope.

 

Common ground to explain other models

Two models that are very useful for understanding the progression through the model are the WHOW matrix and the Cynefin Framework. Both of these are summarised in the Praxis Framework encyclopaedia.

The WHOW matrix addresses the fact that uncertainty is made up of two components: uncertainty about how to define objectives and uncertainty about how to achieve them. It focuses on how these two components of uncertainty affect the life cycle.

The Cynefin Framework is a ‘sense-making’ framework for dealing with systems with differing degrees of complexity. For example, it would indicate that the best approach to the simple project in the bottom left corner would be to ‘Sense, Categorise and Respond’ and use ‘best practice’. Whereas, were you have an extensive portfolio of highly uncertain projects and programmes in the top right corner, you need to ‘Act, Sense and Respond’ using ‘Novel practices’.

Superimposing these models on the Praxis model provides a catalyst for seeing how knowledge gained from both these models can be brought to bear.

 

 

A reference point for tools and techniques

Different tools and techniques have different strengths and weaknesses in relation to the uncertainty and extent of the scope. This is not an exact relationship, the positioning of the various tools and techniques on the diagram below are purely indicative and is used purely as an aid to understanding where and how different tools and techniques are relatively best applied.

The corresponding pages on the Praxis Framework web site provide a better understanding of how each tool or technique relates to the extent and uncertainty of scope.

 

 

For example, Critical Path Analysis is ideal for projects with low uncertainty. If there is uncertainty in estimating the activities, then something like Monte Carlo analysis can be used.

Where there is uncertainty about how to achieve objectives but there is a high cost of change once delivery is under way (e.g. physical projects like a communications satellite), then Concurrent Engineering is useful. Where there is high uncertainty about the finished outputs, but the cost of change is much lower, then agile development approaches can be the best way to work, perhaps using scrum or kanban.

As the scope of the work becomes more extensive and more uncertain, more effort needs to be put into understanding the complex system that the project is creating or changing. That’s when Systems Thinking comes into its own using tools such as Causal Loop Diagrams and Actor maps.

SHARE THIS PAGE

Please consider allowing cookies to be able to share this page on social media sites.

Change cookie settings
No history has been recorded.
Back to top