Tailoring Praxis

The central philosophy of Praxis is to provide a flexible framework that can be tailored to the context of any project, programme or portfolio. It seeks to provide sufficient structure to enable organisations to develop their capability maturity while not being overly prescriptive or restrictive.

Tailoring the framework is therefore essential to its success. This section could not hope to describe every possible way of tailoring the framework to accommodate the infinite variations in project, programme or portfolio context. The aim is simply to illustrate ways in which different aspects of the framework may be tailored

Knowledge

The knowledge framework is the foundation of much of Praxis. Tailoring it is a matter of deciding which functions apply to your context and at what level. For example:

  • In an organisation that only manages low complexity projects, the descriptions of programme management are probably not applicable. The descriptions of portfolio management may be applicable if you want to govern your projects in a co-ordinated and integrated way.

  • If you run projects that use purely internal resources, procurement and contract management may not be relevant to your context.

  • On simpler projects it may be perfectly adequate to consider scope management at the summary level and not address its components (solutions development, configuration management etc.) at the detailed level.

All these examples are about omitting the parts that are not relevant to your context, i.e. you should take from the knowledge framework, the elements and detail that are appropriate to the context and complexity of your work.

Since competencies and capabilities are structured in the same way as the functions, this then forms the basis of how you tailor the competency framework and the capability part of the capability maturity model.

Method

All aspects of the method should be tailored to suit the context. The process models are based on the life cycles and will be tailored depending on questions such as:

  • Does the complexity of scope suit a project or programme approach?
  • Is the project using a serial or parallel life cycle?
  • Is the work using a standard or extended life cycle?
  • Is a project part of a programme?

The first step is therefore to select the processes that suit the context of the work. For example, if an organisation only delivers outputs for clients, it may omit the benefits realisation process from its tailored model. If a portfolio organisation is producing guidance for projects within programmes, they may omit the identification process as that is done by the host programme.

The documentation within the method section should be tailored to match changes elsewhere. For example in the case of the organisation that omits benefits realisation from its version of Praxis, it won’t need the benefits management plan and other benefits related documents.

Smaller projects may be able to combine various detailed documents into fewer more general documents.

Conversely, an organisation performing work of a more complex or specialised nature may have to include additional documents. For example, an organisation that used value management to perform requirements management and solutions development may need to add a value management plan in the style of other management plans. A project delivering a complex set of components may need to focus on configuration management in a configuration management plan.

Competence

Once the host organisation has decided which functions and processes are appropriate to its context, it should tailor the competence framework accordingly. Each competency in Praxis aligns to a function or process and so those not required can easily be omitted from a tailored framework.

Once the required competencies have been selected, the tailoring process can look at the content of individual competencies and how they might be used within role descriptions or learning and development programmes.

The standard Praxis competencies are aimed at someone who is responsible for the whole of a function or process. For example, manage risk is aimed at those who will operate the risk management procedure and produce the relevant documentation. On a small project that may all be the direct responsibility of the project manager but on a more complex project or a programme the manager may oversee the work of a member of the support team or a risk management specialist. Of course a performance criterion that says “maintain risk management documentation” can be interpreted as covering both situations. It is up to the person tailoring Praxis to decide whether this needs more explicit description.

It may be necessary to split the competencies. For example, while the manager may be responsible for planning and initiating the risk management procedure, there may be others responsible for the identification and response planning. Each competency should be seen as a set of criteria that need to be performed but not necessarily all by the same role.

It can be argued that these amendments only affect the performance criteria since whether someone is supervising the procedure or only performing part of the procedure, it is still necessary to have knowledge of the whole.

The tailoring also needs to take the context of the work into account. For example, someone working on a programme may be responsible, not only for preparing the programme risk register, but also for consolidating multiple risk registers to provide an overall measure of risk.

In some contexts, it may be necessary to be competent in specific techniques such as (in the case of risk management) Monte Carlo analysis or decision trees.

The standard Praxis delivery competencies are aimed at the general application of each function. These would need to be supplemented with contextual performance criteria and/or knowledge criteria to suit. Each competency in the framework is supplemented with ideas on how it may be affected by role, complexity and context, although these cannot cover every situation and are for guidance only.

Some general issues that may be applied are:

  • When applied to a portfolio, any reference to ‘life cycle’ should be replaced with the word ‘portfolio’.

  • The words ‘accountable’ and ‘responsible’ can be introduced to take account of how a competence applies to a role, e.g. a sponsor will be ‘accountable’ for some performance criteria for which the manager is ‘responsible’. In larger, more complex situations, the manager may be accountable for criteria and responsibility lies with support staff.

  • In complex projects, programmes and portfolios it will be necessary to combine information from their component work packages, projects and/or programmes. In this situation performance criteria should be reviewed to address the collection, consolidation and summarisation of information from multiple sources.

  • Where projects are part of a programme, or projects and programmes are part of a portfolio, several versions of a competency may be required to accommodate the different levels at which a function is performed.

Capability maturity

The capability maturity model can be used in two ways, internally and externally.

Internally, it is simply a reference guide that enables an organisation to improve the effectiveness and efficiency of project, programme and portfolio delivery. Externally, it may be used as a benchmark for comparison of one organisation’s maturity against another.

Each organisation will have its own context. It may only use a selection of the functions, processes, and documents described in the Praxis framework. When using the capability maturity model internally, it will be natural to only use the capabilities or maturities that are relevant. The more important aspect of tailoring the capability maturity model is when it is being used for external benchmarking.

It would be unfair to assess the maturity of a small contracting organisation and an organisation that delivered complex internal projects against the same maturity model. An organisation’s maturity should be assessed against its own context, i.e. maturity is context sensitive, much as ISO 9000 certification is assessed against adherence to core principles of quality management as applied in different contexts.

The content of a capability maturity model for a particular context will reflect the tailoring of the functional framework and the process model. Since the capabilities correspond to the functions and the maturities match the processes, a contextually relevant capability maturity model emerges naturally from other tailoring work.

Organisations can then develop and assess their capability and maturity in their own context. An organisation that reaches level 3 capability maturity using the Praxis approach is demonstrating that it is at level 3 for the work that it does, not at level 3 for an idealised, ‘one size fits all’ model.

It’s like comparing an international footballer with an international athlete. They have both reached the level of ‘international’ but have done so by mastering different skills relevant to their sport.

 

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