Authors: John Moore & Peter Dillon-Parken
So, it's your first week on the project, you look around for the requirements documents, and what you've got is basically a bunch of notes. In short, very little project definition has been done. This is the situation that quite often confronts project managers - does Praxis help with this at all?
I believe it does by giving a complete framework for the business project from idea to benefit realization. A project manager knows what is needed as a baseline before the work is started. When the bunch of notes lands on their desk they have to assess what is missing and then plan to fill in the gaps. This first part of the project may be assigned to a business analyst who are for all intents the project manager at this point. Then the requirements are handed to the project manager for delivery, subsequently to the business to carry out benefit reviews, and possibly on to a business change manager. Praxis can be used by all of the roles, who are all using the same framework. That provides consistency of approach and so the 'bunch of notes' becomes a structured 'bunch of notes' that evolves as we travel across the business project.
Another issue that is quite common to project managers is competing for resources. Although resources will always be an issue what approach does Praxis take to managing resources across portfolios, programs, and projects?
There is no magic dust that we can apply but what Praxis is not afraid to do it to actually call out this topic as part of the capability maturity model. To support this there is a specific checklist of key capability attributes specifically for resource management. Being a P3 framework the sharing of resources is managed across the management levels. With that communication it means that the P3 manager can be fully supported.
Praxis is an open source - free - framework for managing projects. What value, and what risk do you think this open source approach embodies?
Great point. Open source is now a frequent catch-all meaning 'free' and that could be a risk if not maintained. However, the term was originally used for software. Without any control untested code can be included in solution leading to disastrous results. In this case Praxis is a framework of best practices, such as PMBOK, and a supporting structure that anyone involved in solution delivery can use within their business environment. I would describe Praxis as the wrapper around successful business solution delivery. The risk is around whether we take notice of the embedded knowledge base.
In their literature Praxis point out that despite numerous best practice guides been available for project management none of them look at all the areas necessary for project success. Would you agree with this and how is Praxis different?
Not sure I would agree, as the best practice guides focus on project success, but often only from the standpoint they are written from. For example PMBOK is focused on the project manager perspective, PRINCE2 on the business case, MSP on benefit realization, Agile, on the development. Praxis encompasses these approaches and so gives joined-up-thinking for the business rather than more working in bubbles.
Praxis recognize that tailoring - as opposed to blindly following a methodology - is key to its success. Might it not also be the key to its failure, if it were tailored by people who lacked a fundamental grasp of project management principles?
You are quite correct. Many people take and pass an exam and then believe they are a project manager and think that tailoring is a pick and mix, leaving out what they believe is not necessary. My view is that Praxis, more than any other framework is an indicator of what we have to be aware of and the competencies we may need including how to tailor the framework to meet the need. The supporting material gives some great ideas of how to approach this delicate concept and it is really up to the P3 manager learn from the advice and knowledge that this framework contains.
The collective risk to an organization can be increased when risk management across projects, programs and portfolios can be in siloes. Does PRAXIS help with this?
Because of the integrated nature of Praxis, risk can be thought of as one single risk register that is managed and maintained at each level. Because you're always interrogating a single repository shared knowledge of the risk is promoted across the entire initiative. Of course, a single risk register is not mandated, and it is quite possible that a risk register could be owned at each level. However, the standard approach of a single risk register is part of the risk approach that praxis promotes.
I find that inconsistent processes across a project framework can be held within program or portfolio frameworks. Has PRAXIS tackled this problem?
Praxis mandates that the process undertaken at each level is identical, although we must remember that the specific activities that are carried out at each level will vary. So, at the portfolio level you may review the yearly investment available to help you decide which initiatives you will pursue. For a programme the same process may result in a review that ensures strategic alignment around the benefits at project level. In other words, "do we have a viable project?" So, said the project manager controls undertaking the appropriate activities and the detail of those activities within the process itself.
At the heart of all successful or failing projects is people. And yet many project frameworks don't provide project managers with guidance on tackling people issues. Does PRAXIS deal with the real world people guidance that project managers need - possibly more than line managers, because projects often have a matrix set up.
Yes, your right. Although people skills are often implied, the actual level of guidance is limited to zero to none. Experienced project managers know that project management is about communication, communication, followed closely by communication. It's fine suggesting a communication plan, but how do you deal with people? The problem is that communication skills are often thought more as a business analysis competency but increasingly project managers don't simply sit in front of a laptop and plan. Modern project managers need to use a wide range of soft skills, and Praxis shows this throughout. To support communication skills Praxis has competencies areas. This has now been recognized in PMBOK v6 and the content has been expanded. Between them we are beginning to fill a void in the project management arena, and that can only be a good thing.
When you talk about a competency framework in Praxis, could you be more specific.
One aspect of the framework that really comes to the fore is the recognition of differing methods and approaches, both traditional and agile, and the Praxis knowledge base includes some great articles from key players from the project management world who belong to both Praxis and the PMBOK.
The standard Praxis competencies are aimed at someone who is responsible for the whole of a function or process, but Praxis recognize that these competences may need to be tailored. What specific advice does Praxis give for doing this?
Well if we take the example of risk, the standard "manage risk" competency defines who will run the risk management procedure and produce the risk documentation. On small projects that might be the project manager, but a more complex project might need someone specifically assigned to the role. If we take the "maintain risk management documentation" competency it it's a little ambiguous. But whoever tailors Praxis can decide whether they need a more explicit role description, or even whether the competencies should be split. A "competency" in Praxis is really a set of criteria that need to be performed. But whoever tailors Praxis can decide whether those criteria are performed by one or multiple roles.
We all deal with change and the impact of change on projects. How could have PRAXIS have helped you with a change nightmare on one of your projects?
Ask most project managers and you will find their project is always on track and change is never an issue at all! Seriously, we know change will happen, and configuration management and managing change requests are key competences when defining the project. Praxis, due to its integrated nature, has a consistent approach that integrates the decision making about change and its escalation. So, if we need a decision at portfolio level it can be communicated to program and also to project. Even if you are in a stand-alone project your business approach should be one of visibility and transparency to all. If you take an agile initiative to projects change management is addressed by requirements definition and business prioritization as the project works through the iterations
Planning and dependencies across projects and programs can create problems with conflicting priorities. How does PRAXIS tackle this?
It is not so much Praxis dealing with it, but that the Praxis integrated framework gives an overall platform to manage dependencies because the repository of information can be open to all. This is not new as project portfolio management (PMM) solutions have been on the market for many years. The issue has been "how do we make the best use of them?" The agile approach where we focus on visibility and transparency is the methodology used in the supporting framework knowledge base and articles.