We are currently looking at how we can introduce more agility into Praxis and would welcome comments on this draft approach.
Our opening words were chosen carefully. We are not seeking to produce a ‘Praxis Agile’ or any other sort of alternative version of the framework. We see Agile as a method that introduces agility into software development but agility can be introduced into any management discipline, including project, programme and portfolio management. Our aim is to introduce more agility into the Praxis Framework in a way that is not in any way exclusive to software projects.
‘Agile’ as the term is widely used does not represent a solution to the objective of introducing greater agility into the broad spectrum of projects, programmes and portfolios, although many ideas and approaches from Agile software development can be translated for a broader audience.
The draft approach is set out below – it is deliberately kept short so it won’t take too long to read (but with plenty of diagrams to speak thousands of words). We appreciate that some of the assertions we have made will be controversial. We could have written a lot more to explain these assertions but we decided to keep it brief and deal with the points that arise in the ensuing discussion.
Firstly, The Praxis Framework already has a unique approach to dealing with projects, programmes and portfolios. We maintain that these are simply points on a spectrum of initiatives and the best scale we can use to represent this spectrum is ‘complexity of scope’*. (The thinking behind this is explained in the article ‘Projects, programmes, portfolios and the discontinuous mind.’)
All initiatives (projects, programmes and portfolios) are unique, and to pigeonhole them into one of only three categories is misleading. Tools and techniques are often arbitrarily allocated to one of the three categories when in reality an experienced manager will draw from all three as required by the characteristics of the initiative he, or she, is managing.
To address this, every relevant page in the Praxis Framework deals with a function or process (e.g. schedule management or risk management) generically and then talks about how the general approach needs to be applied as scope complexity increases, from projects through to portfolios.
We now plan to add another dimension to this spectrum called ‘Uncertainty of scope’. This is done on the fundamental premise that agility is a quality that is needed when scope is uncertain. The greater the uncertainty of scope – the more agile you need to be.
The terms Waterfall and Agile are too binary to realistically represent the range of uncertainty that applies to the scope of projects, programmes and portfolios.
Just to further illustrate this, we’ve put in sample initiatives in the centre and four corners of the spectrum but the principle is that there are initiatives that cover every point on the two scales. These will draw upon approaches from all of the ‘standard’ five pigeon holes. We need to give those in our profession a perspective of the full spectrum rather than just the narrow conventional categories.
And finally just to reinforce the point, this is how some of the guides in the current paradigm fit onto the spectrum.
So how will Praxis Framework differ? Our aim will be to ensure the framework covers the full spectrum without labels that promote restricted views. Based on the principles outlined above, we simply propose a new section on each page to deal with agility. For example, if you are reading about requirements management or schedule management you will still see the ‘general’ section, then the ‘project, programme, portfolio section’ that deals with complexity of scope and finally, the ‘agility’ section that deals with uncertainty of scope.
Managers using the framework simply have to evaluate the levels of complexity and uncertainty they are faced with and tailor their approach accordingly.
We would really value your thoughts and comments on this approach either through our LinkedIn discussion or the ‘comment’ tab at the top of this page or if you prefer by email to email@example.com. We look forward to hearing from you.
* Our use of the word complexity in this context is best defined by the Collins dictionary: "Complexity is the state of having many different parts connected or related to each other in a complicated way." So, for example, the difference between a project and a programme is not that one delivers outputs and the other delivers benefits. The difference is the number of interconnected elements and the relationships between them An initiative that includes one output and one benefit could be run as a project. It is only when you get multiple outputs with a many-to-many relationship with multiple benefits that you need to run it as a programme.