Project Management in Practice

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

Category Archives: programme management

Building capability in organisations


My personal reflection time during the week is on Saturday mornings, when I take my children to the local swimming pool for lessons. I was looking at the pool this week, with children of various abilities learning to swim – all in separate lanes. I recalled how my children had gone through the grades. It occured to me that building capability in organisations is an identical process. If you try to go to the quick lane before existing skills are bedded in, you will sink.

Business Change

I have been in the process of delivering a geospatial capability improvement plan for a company in the energy sector. This organisation had expressed a view that it wanted to get the process under way immediately. However, our assessment based on stakeholder feedback and existing capability, indicated the organisation had a low change appetite. This conclusion was accepted by the stakeholders.

As a result, we recommended a multi-phase approach with the first phase centralising disparate systems and processes, a following phase increasing awareness by integration with other business systems and a mature phase looking at bespoke capability for high return on investment analyses. It is however the final phase capabilities that the management is most keen on. In this instance we have been very fortunate to have successfully achieved by in from the stakeholders on the phased approach.

Getting to mature capability from little or no capability is not something that can be achieved successfully. The first two phases and the time it takes to bed those capabilities in are like teaching the children to breath under water and float, before they can be taught the various strokes. Before getting to lane 8, you need to have mastered lanes 1 through 7. Without this you will be swimming upstream – forgive the pun.

Beware trying to deliver the desired future state in one go. Be prepared to go through intermediate states if necessary. Success is not what cool applications the project delivers, it is what business advantages the organisation can achieve through those.

Image Credit: ChinoHills.Com

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.

What are the challenges in establishing a PMO?


I was recently talking to Terry Teoh from Deloitte in Wellington regarding some of the challenges in setting up a Programme Management Office (PMO). It was a very interesting discussion, which he kindly agreed to have published as a blog post.

The first challenge Terry identified is the one of lack of stakeholder buy-in at leadership level. It is imperative that the PMO lead constantly weaves in the business benefits of the PMO approach – i.e., why are we doing this? This needs to be done at the leadership and management levels. This paves the way for team members to work effectively with project teams at the delivery level. To be effective, the PMO also needs to constantly articulate the benefits of the process to the programme teams as well – i.e., why would filling out this report for the governance meeting help?

Another challenge identified was the one of the PMO being an administrative function. It is critical that the scope of the PMO includes activities that provide strategic and governance value. This can be delivered by ensuring PMO is responsible for frameworks and programme structures, methodology and metrics for performance measurement, integrated views of work plans and dependencies and budgets and capability development for governance of projects and programmes. As soon as a PMO gets a reputation as chaser of reports, their value becomes questionable.

Flexibility of process and approach was identified as another key challenge. The worst approach a PMO can take is a text-book one where a “thou shalt do” culture exists. Approach needs to be tailored to suit the organisation and its culture. The effort of support and hand-holding necessary at the beginning of establishing a PMO to ensure people understand and do things correctly, is often underestimated. This also enables the PMO to recognise how to enhance and tailor the process and provide guidance along the way.

The last major point of discussion was the necessary skills within the PMO staff. One comment Terry made that resonated well with me is the fact that the worst PMO staff you can get are the ones that have done PMO work all their life. PMO requires expertise in a range of fields that directly relate to the programme and the projects it is likely to commission – IT management, financial management, project planning and control etc. This also enables the PMO to put themselves in the other person’s shoes with the right perspective. Without this, success is difficult to achieve.

I’m keen to hear what challenges you have faced in establishing PMOs.

Visualising risks and issues


Risk Management - Image from bigthink

One of the key tasks of a Project Manager or Programme Manager is to identify and control and mitigate issues and risks in projects or programmes. Traditionally these are done using an issue number as an identifier and using plenty of text to explain the context of the risk, how you identify it, estimating and evaluation methods, plans to mitigate, how you implement the actions and communicate with stakeholders. If you are lucky, there may be some risk maps that outline the risk assessment process and some graphs, if the risk is of financial nature. Again if you are lucky, you are utilising some web based mechanism that has an instant ability to raise and assign risks and allow dynamic reporting. More often than not, it is actually a spread sheet in someone’s laptop!

I have been thinking … what is the purpose for having a Risk and Issue Management process? The main aim is communication. You want all the stakeholders to be aware of the risks, allow the Senior Responsible Owners (SRO) to make sound judgements on the level of risk the programme or project should carry and the teams to know what to do when one of these risk events come to fruition. Human brain isn’t really programmed for reading huge amounts of text to understand context in an efficient manner. A picture tells a thousand words is true. When you think about traditional risk registers … are they really helpful in some situations?

I have identified some of the issues with the risk registers. Do we now draw pictures instead of writing the details? No, I am not advocating that. You need the details for implementation purposes, which cannot be ignored. How do you achieve the “communicate” bit?

One obvious area that comes to me is recording of risks spatially. In a lot of programmes, different projects are commissioned that deal with areas that overlap, or have interests in achieving different outcomes in the same area. An appropriate use of spatial context can give the stakeholders and SRO a good understanding of risk patterns over specific areas. There may be multiple projects coming up against similar problems in the same geographic area. This is a likely situation in a lot of disaster management and recovery scenarios.

Another area is likely to be temporal reporting. There may be specific risks associated with specific times during the day, week or month. Some candidates are service oriented programmes that deliver IT services. There may be specific times of day that have spikes associated with it. Some social programmes may also be candidate for similar communication strategies. Examples are risks of anti-social behaviours, accidents etc.
While I have been thinking about some of these risk communication challenges, I don’t think I have it totally sorted in my mind. I am keen to understand what techniques you use to achieve this. Any comments most welcome.
Related articles

How do I make sense of chaos?


Snowfall around Beehive (NZ Parliament) - courtesy stuff.co.nz

Snowfall around Beehive (NZ Parliament) - courtesy stuff.co.nz

I’m sitting in a transit lounge while I write this post. I’m heading to Los Angeles to undertake programme planning for three major pieces of work we’re delivering to our clients over the next twelve months. I was supposed to leave Wellington last night. If anyone has seen the news recently, Wellington has been hit by once in a 50 year snowfall, which has unravelled my travel plans. As I sit here in the lounge and kill plenty of idle time, it occurs to me, actually this is not too dissimilar to projects and programmes. How you may ask … read on.

If you think about it, going to LA is not really a task, it is an activity undertaken to achieve some outputs (planning for the programme of delivery). Any time you travel, one of the risks you must take into account is disruptions. In effect, it is just a project risk that I need to take into account. The fact that weather was going to be marginal, wasn’t obvious at the time of planning. However, as the travel was nearing, it was looking likely that I needed to actively monitor the risk and set out some responses. In order to transfer some of the risk, we had purchased travel insurance (corporate). At the same time, I was thinking of mitigation plans, in case disruption happened.

It appeared everything was on track, until about an hour before my flight out of Wellington. A sustained period of heavy snowfall whitened the runway and Air Traffic Control had closed all landings and take-offs. I knew I had no chance of catching my connecting flight out of Auckland even if the runways were opened again. I was straight on to the reservations to ensure I was first to get re-booked on to connecting flights for the following day. I also wanted to mitigate a further risk of not making the connecting flight again, thus rendering the travel less beneficial. This time, I ensured I took an earlier flight to Auckland, allowing me plenty of opportunity to re-book if necessary.

All done, it is now time to head back home for the night. As I come out, gale force southerly were lashing outside. There were thousands of people queued and not a shuttle or taxi in sight. I had to make a quick decision, to ensure I got home in time to get a decent sleep, so I could start my travel again in the morning. I decided to hire a rental car for the night and head off. This is no different to projects, where you have to take decisive action to ensure success.

All the planning that I do for projects and programmes, is to ensure that I don’t have to wade through this amount of chaos 🙂 Wish me luck.

Technorati Token: 8BB6S6NTA3XB
%d bloggers like this: