Project Management in Practice

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

Tag Archives: prince2

How do I tailor PRINCE2 to deliver IT projects?

I had been reflecting on a comment Geoff Rankins made at a previous PRINCE2 User Group Meeting regarding most IT projects not delivering the stated benefits. I have concluded that I agree. Most of the business cases for these projects are put up by the IT departments and vastly overstate the benefits to get those approved. Some even go to the extent of hiding the cost in operational budgets, so they don’t have to put up a business case in the first place! The consequence is those benefits can never really be measured or met. IT is not the core business of most organisations. I don’t think many of us in the IT profession have quite grasped it. It exists to provide an answer to a business question. Therefore, IT should not be putting up business cases. Their role should be to be the subject matter experts that advise the business in how they can enable capabilities.

From my perspective, delivering IT projects, there are two significant gaps in PRINCE2. One the text readily acknowledges is the lack of guidance around specialist areas like IT. It is interesting given the genesis of PRINCE2 was to control capital it projects in the UK. The second is in transitioning the outputs into the business. Of the cabinet office products, MSP has the best guidance around transition, but what if your project is not part of a programme? Many it projects aren’t.

Now let’s consider the environment in which the projects are usually delivered. Rarely will a project be delivered in a Greenfield environment. Most organizations today will either have an infrastructure or existing capability of some manner. They have a framework for delivering to their business. More and more the best practice framework used is ITIL.

The process that wraps around service design, transition and operation in ITIL is the continuous service improvement process. This is responsible for measurement of existing services to identify areas of improvement to deliver maximum value. This is the crucial link to connect a service management framework like ITIL to a project management framework like PRINCE2. The organization has already put a value to having this service available to them. Tying this improvement process to business cases ensures what makes sense technically also makes sense strategically.

In a real life example … a software that is used by an organization was about to become unsupported. It was flagged as something needing upgrade. But the organization was thinking about changing business processes that would no longer require that software. The IT team had moved the cost of this upgrade into operational budget, so they wouldn’t have to go through a business case for it! What was the consequence? They upgraded the system, delivered within budget and time, but discontinued it in less than 4 months! Was this a successful project?

Paradigm is shifting in the way IT delivers to the business. Cloud is becoming a realistic option for many services, applications and even infrastructure delivery. The advantage of this approach is a known risk pattern and the level of elasticity it gives you. The fact that you can scale to demand and not have to design for peaks, are good ingredients for success. Custom development therefore should be the exception, rather than the norm. It is somewhat ironic coming from someone that started his career as a software developer.

There will be times when you will have to build custom systems. Either due to legislation, or simply the problem is unique. In my experience, software development is part science … we’re building machine instructions, part art … designing user interfaces for example … and part voodoo. The problem the customer explains, the BA understands, the developer codes … are often coloured by their interpretation of the problem. It is the role of the project manager to ensure the language isn’t muddled. This is where I have found agile practices very useful.

Agile methods allow for quick feedback cycles – starting early and often. The biggest benefit I have found is stopping unnecessary features being developed – all developers are guilty of that, trust me. It also ensures what is delivered does not come as a surprise to the customer. Agile requires delivery of working software at the end of each iteration. Lining iteration boundaries coincide with management stage boundaries will ensure if it is ever determined that the project is unlikely to deliver the desired benefits and is cancelled; the customer is left with the latest working product.

The model I strived to establish in projects is Continuous Service Improvement forming the basis for startup activities, using the service design principles during initiation as you define you product description, use agile practices to build the product and use transition processes to deploy to the organization and finally as part of closure to establish the operational practices so a new cycle of service improvement activities can begin.

I want to end by sharing a statistic from Keith Ellis of IAG consulting … only 1 in 3 software projects make it to completion in the United States. That is the good bit. Of the ones that do, 85% are late and over budget. Traditional project centric thinking has a lot to answer for in IT project failures. We must tailor PRINCE2 in context of the delivery environment and project challenges. Frameworks like ITIL; practices like agile can help us achieve that.

What methodology do I use?

There are a plethora of project management methodologies out there. Each have their own strengths and weaknesses. How do we choose what is right for our environment? I am presenting to a peer forum of Project Managers. This is a draft of my thoughts. The full blog post can be read here.

Prince2 ITIL Agile … what is best for me?

View more PowerPoint from Shoaib Ahmed

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 methodologies do not solve

Organizations evolve through various phases in their existence. Good organizations have a continuous focus on how they do business and strive for improvement. One of the most common realizations organizations come to is the need to utilize standard methods and best practices in order to ensure higher quality outputs from its staff. While this is a correct realization, implementing these is where a lot of organizations go wrong. Let us explore.

A lot of organizations, when they realize the need for standard methods and best practices will send staff away to courses. In the case of project management, they may get sent away to do a certification in PRINCE2, PMP or Agile, for service delivery management, they may get sent out to get certified in ITIL. You get the drift. What I see many a time is this is sufficient and the organization will suddenly become followers of best practice. There is then wide-spread surprise and the reality turns out to be something different. Why then despite the obvious intent, do many of these initiatives fail?

The first thing everyone needs to appreciate is no methodology can ever cover all the practical scenarios an organization will face. Best practices are just that … best practices. Knowing the theory is all well and good. Reading a particular scenario and understanding it to answer questions is different than what someone will face in their regular role. There is no benefit of hindsight. In many situations, you have to make a decision on the facts at hand, which may not be full. Later, you may be required to account for those decisions to someone with benefit of hindsight. This requires not only understanding of methodology, but also an appreciation of how to apply it to various scenarios.

If you have studied information systems, one of the first things they teach is the theory of normalization. However, what they do not necessarily teach is in certain scenario, it is a more efficient to de-normalize parts of the system. For non-IT readers, I can equate this to child rearing. The best practice is to always keep a routine and not deviate from that, so you set clear boundaries of expectations. However, every now and then it is good to indulge your children slightly to build a warm reciprocal relationship with them. There is always fine balance here that requires judgement and constant review. What is best practice may not always be a good practice in certain scenarios.

I have seen selection of methodologies as a response to a project disaster or an attempt to cover gaps identified in a procurement process like responding to a Request for Proposal. That usually leads to selection of methodology from a very narrow focus. There is also a huge difference between selecting a methodology and adopting a methodology. Selecting one is on the easy end of the spectrum. Once selected, the organization may send some people to training. When these people come back into the organizations with new ideas, they challenge the established way of doing business. This challenge may go beyond what management had intended to address when it embarked on the process. Unless there is a willingness from management to re-examine the practices, then there is little or no value in selecting a methodology.

Methodologies do not solve any business problems. It is the people that absorb ideas, question existing practices, design improved processes appropriate to the organization and have the will to see it through that make the difference.

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: