Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Category Archives: PRINCE2

Managing Projects Better

Australasian trends in MSP and impact on PRINCE2

The Wellington PRINCE2 User Group met last week at the Deloitte House. The guest speaker at the event was Geoff Rankins, a programme and project management professional with over 35 years of experience across ASX50 organisations, Federal and State Governments in Australia and international not for profit organisations. He is also a contributor to PRINCE2 2009, MSP 2011, ISO 38500 and ISO 21500. Usually the user group has a format of three seven minute presentations followed by Q&A and networking on a single event. Due to the calibre of the speaker the committee adjusted the format to have only a single speaker with interactive Q&A with the speaker. Three main threads of discussion centred around trends in Australasia, MSP implementation lessons and co-existence of MSP and PRINCE2.

There were some interesting insights from Geoff regarding the pattern of adoption he has seen in Australasia. Consulting firms are using MSP to manage company mergers and state wide eHealth programmes. One of the largest construction companies is using MSP to manage building of 800 building in an 18 month period across the state of Queensland. The Australian Government Information Management Office (AGIMO) is promoting the use of MSP to the Federal Government Departments. The Capability Development Group of the Department of Defence in Australia already use both MSP and PRINCE2. There is also a trend in the various State Government Departments using MSP to deliver strategic programmes. In Australia not for profit organisations are using MSP to deliver process re-engineering and coordinating national mental health programmes. In New Zealand telecommunications and hydro-electric companies are taking up MSP as well as the national rail company and the Department of Corrections. Internationally, UNDP has adopted MSP to deliver aid programmes across 160 countries and in the UK the London Olympics is delivered through MSP. If you were ever wondering why so many examples on the MSP text appear from the London Olympics, this is the reason.

Like any other change initiatives, there is different between deciding to use MSP and adopting it. Some of the implementation challenges Geoff shared has a ring of familiarity. The biggest issue he highlighted was not treating adoption of MSP as an organisational change project on its own. Unless the organisation changes the culture of its programme delivery, success is going to be limited if at all attainable. In the same manner PRINCE2 has to be tailored to suit the organisation, so should MSP. That leads to implementations not challenging the existing environments and the necessary organisational change is not achieved. Using consultants was also identified as a limiting factor. Consultants being used must have implementation expertise, rather than simple certifications. At the same time the organisation must invest in internal capability building. In many case consultants move and and all the knowledge is lost. Consultants can help implement, but not maintain and evolve the framework as the organisation changes.

There is also a tendency to jump to a solution mode too quickly, what Geoff called inadequate “optioneering” and resulting in sub-optimal business cases. Organisations where programme management is less mature there are tendencies to treat a set of projects as a programme and not using it a vehicle for achieving organisational change. This also leads to focus to too much detail at programme level – defaulting to project management mode. The senior management in the organisation have to focus on the bigger picture of the programmes, rather than details of individual projects. Intervening too low results is focus on outputs rather than benefits and threats to them. There also needs to be a realisation that programmes are inherently more uncertain than projects and some element of learning is expected. The benefit an organisation can derive from having a well defined MSP framework are providing quick start to project business cases, oversight in project governance, escalation path to the senior management, lessons capture and dispersal across many projects. The biggest benefit of all is the focus on benefits realisation – something a PRINCE2 project is tasked with considering, but not well placed to achieve as the project is long finished before the benefits are scheduled to be achieved.

Sometimes organisations spend too much effort to identify if something they need to achieve is a project or programme. The key message from Geoff was to start with either and change the approach if necessary as the business case gets refined. Integration of PRINCE2 and MSP should happen on the basis of roles, assurance requirements and governance strategies.  The idea that resonated with me was there is nothing stopping cherry picking parts of MSP into projects if the organisation is not mature enough to handle MSP implementation. There is no reason why stakeholder engagement strategies, benefits profiles, blueprint and transition planning concepts of MSP cannot be used in a PRINCE2 project. In fact those should be transferable to any project. Right tools for the right environment.

Adoption usually comes because of governance and accountability reasons. For that reason frameworks like MSP and PRINCE2 usually are adopted by Government entities first. This then forces all service providers to comply. It appears there is substantial acceptance of MSP and PRINCE2 as Programme and Project Management frameworks in Australasia.

Where is the line between agility and chaos?

We are living in an age of social media. One where opinions are best expressed in 140 characters or less, hashtags galore and needs need to be met instantly. There is a level of agility required to work well in this environment. If an organization rigidly sticks to how business used to be done, more than likely they will be left behind by others that are willing to alter course. However, can one get into the habit of altering so much that they go around in circles? There are many misconceptions about Agile. Let us explore some of those.

Aglie is NOT Agile IS
A methodology Agile is a set of principles.

  • Individuals and interactions over process and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

People have created methodologies around these principles – namely Scrum, Kanban, Extreme Programming (XP) etc.

License to dive straight into code All Agile methodologies have a significant emphasis on continually solidifying user stories. A successful delivery is judged by how closely the delivery met the user stories.
License to develop without scope User stories are the definition of scope. User stories must contain enough information for the developers to quantify a particular story “done”.
License to change your mind daily User stories are worked on continuously. More imminent a story is to be worked on; more time is spent detailing it. Adjustments to requirements are accommodated during sprint planning and treated as any other requirement, which it is being prioritised against.
License to leave half finished work floating around Most agile methodologies will restrict the number of in-flight tasks. If some of the team complete their work before others, it is their role to help others complete tasks at hand.
License to continually chop and change the team Most efficiency is gained when you arrive at a team that gels well. The sum of the capability of the team dictates the velocity at which it can operate at. Constant swapping of resources makes it near impossible to measure progress through burn-rate. One area where you expect change is in the role of the subject matter expert, based on tasks at hand.
License to pull resources mid assignment Once the sprint starts, resources are committed to getting the sprint ‘done’. It is acceptable to commit a resource to part of the sprint or a portion of the resources availability. But once committed, they see it through.
Something that only works on its own Agile is perfectly paced to be used in conjunction with other project management methodologies. For example, one can use PRINCE2 and manage by stages, where the stage boundaries represent iterations in an Agile methodology. Agile requires complete software at the end of iterations. PRINCE2 requires the ability to close a project if the business case can no longer be satisfied. Using the two together allows for tangible benefits to remain with the customer even if a project has to be cancelled.

To avoid chaos, you need a level of planning. When planning is impossible, chaos is the more likely outcome than agility.

Do procurement processes allow Agile software delivery?

Longer projects run, higher likelihood of project failure. One of the moves in recent times to reduce complexity in software development is to adopt Agile delivery approaches. The desire to build confidence and leave tangible benefits even if projects are cancelled has provided further impetus to adoption of Agile practices. This approach has delivered good outcomes for teams that work in in-house and product development teams. However, challenge remains in successful adoption Agile practices in contracted deliveries.

It is rarely the willingness of the project teams or suppliers that is the barrier, but the way organisations work. A quick review of how most organisations initiate projects will highlight this. In most organisations operational staff will identify areas of improvement. Organisations have processes to provide feedback to management to achieve this. Management then compile business case, which is then reviewed and approved by the organisation. It then moves through the procurement cycle, supplier selected and contracts agreed. These contracts are on the basis of deliverables (outputs in PRINCE2) from the project, rather than benefits.

Let us now review the consequence. The project is set up with A, B and C as deliverables. As the project starts, it becomes clear that modifying B will provide far more benefit, even if C is dropped off altogether. In an agile project, the customer is able to provide immediate feedback and the product backlog would be adjusted accordingly. Here the project team consists of suppliers who are under contract to deliver C. They cannot alter the required deliverables. The project team from within the organisation is also not authorised to make this adjustment.

As you keep moving up the organisation challenges still remain. Project governance is set up to hold people accountable for the delivery. Benefits are more difficult to quantify than outputs. Therefore the culture is usually to hold people accountable for the outputs. Modifications to business cases are usually treated as acknowledgement of omission, rather than as an evolution of the project.

So why this inertia for reviewing the deliverables in order to extract the best benefit? Consider what else the people in charge of procurement acquire for the organisation. For most things they are able to show something tangible – an air conditioning unit, an executive table, a new building. Other things they procure are services that are usually measured in time – 3 weeks of consulting. Software development is somewhere in between. You have time, the deliverable is something abstract and it is difficult to judge whether you got what you had asked for – a lot of grey areas. The people to judge is often not the ones that approve the procurement or control them. Auditing the procurement is therefore difficult terms of benefits. As a result you end up with controls on outputs.

In order to successfully embrace Agile delivery practices it is imperative that procurement and auditing methods in the organisation is geared towards measuring benefits, rather than outputs.

Working with Project Sponsors

I went to the Wellington PRINCE2 User Group meeting this week. The topic of the meeting was working with project sponsors. The user group has a format where it invites three speakers, each speaking for seven minutes and no PowerPoint is allowed. At the end of the talks, there is the opportunity for Q&A, group discussions and networking. The three speakers were all of exceptional quality – Philippa Jones, Don Robertson and Dr Judith Johnston.

It was an interesting discussion led by three very experienced project sponsors, some of who also had experience in project management. The key point that came out consistently during the night is that the Sponsor and Project Manager need to work in partnership to achieve successful outcomes. In a PRINCE2 project, the sponsor is someone from within the business and is called Executive. Project sponsors are usually individuals with significant responsibilities and consequently limited availability. Yet, they are ultimately responsible for the project and therefore need to be consulted with effectively to ensure the project is likely to achieve the outcomes sought.

This requires effective planning and delegation of authority. The Project Manager is responsible for managing day to day activities of the project. The sponsor is not there to help on day to day matters. The sponsor is there to advise on direction of the project, help with organizational knowledge. One effective use of your sponsor can be to handle resource commitments from teams where the Project Manager is not a line manager. However, that should not delve into the management of individuals in the team. Levels of authority and tolerance should be set out in the Project Charter (PID in PRINCE2).

Preparation is key in establishing working relationships with project sponsors. Providing the status report just before the meeting does not augur for a productive Project Board meeting. At the beginning of the project the Sponsor and Project Manager need to establish the outline of the reporting structure. Reporting is likely to be different based on what the project is trying to achieve and what are considered the Key Performance Indicators. Ground rules need to be set out regarding communication procedures – when the reports should be sent, in what format, how risks and issues should be reported and escalation methods.

Trust is the basis for this working relationship. Communication needs to be open and transparent between the Sponsor and Project Manager. If there are issues in the project, do not hide from the sponsor – report Red as Red. If the issues are with Senior User or Senior Supplier groups then approach the Sponsor directly to appraise them of the situation. Bringing something to light too late in the piece will take away the Sponsor’s ability to influence outcomes. Uncertainty is usually what causes status reports to be rosier than what they should be. The Project Manager must agree with the Sponsor how uncertainty should be reported. Uncertainty, especially in the early stages of the project, is quite common.

The Sponsor’s exposure of the project is usually not on a continuous basis – usually monthly in large programmes. If everything goes according to plan, then this may be sufficient. However, it is a good practice to have an informal meeting with your sponsor in between status meetings. This ensures your sponsor is kept abreast of developments. Any issues from the project should not get through to the sponsor from other channels than the Project Manager. This will only serve to undermine the trust between the two. The Project Manager must also ensure what is submitted in written status reports correlate to what is being communicated informally in between the formal reports.

Involving the Sponsor is usually associated with something going wrong in the project. This does not have to be the only reason to involve your Sponsor with the project team. One of the speakers related how she looked forward to celebration of achievements in her projects and the ability to say well done. Although it was not necessarily the key message of the evening, it is one that stuck with me.

Project Manager runs the project on behalf of the Sponsor. The role of the Project Manager is to manage the project within the tolerances afforded to him. The role of the Sponsor is to enable that environment to flourish, so the desired outcome is achieved.

Image Credit: GlenKnight.Com

%d bloggers like this: