The Seven Habits of Highly Effective PPSOs - July 2009
Sorry to take some inspiration from Mr Covey, but he gives us such a good framework, it would be wrong to reinvent the wheel! Here in PPSO world, being highly effective is really a must. Not just as an individual, but also as an organisation, and finally we must have an effectively aligned purpose. So here we go:
1) Be Proactive
This is the easy one to start with, and one we should already be good at... when it comes to projects. But are we being truly proactive as business leaders? If you work in a Portfolio Management Office (PfM in the new P3O terms), then your whole world is based around proactively managing discretionary investment spend in the company. If you're not, why not think about the PfM, or if it didn't exist, whatever or whoever does make the investment decisions - they need to have the "eyes and ears" all around the business to help informed decision-making to take place. It's a two way street too, because the business leaders will know about the upcoming trends and activities that will change the needs of the business, and that means they will help you to understand the relative importance of your projects, so you can prioritise resource and conflict accordingly, which leads nicely to...
2) Begin With The End In Mind
Do you know what you're doing and why? This is all about alignment and prioritisation, again sitting quite clearly in the PfM world. The new PfM guidance takes us on a journey starting with strategic objectives - this is definitely the "end game" and every project in a well-run business needs to be strongly aligned to and consciously contributing to strategic delivery. Your PPSO should be instrumental in asking this tough question of all of the projects you are close to - never forget the bigger picture. A great opportunity for individuals and teams to move out of the "support" role and into the "governance" or even the "leadership" mindset!
3) Put First Things First
While company leadership sets strategic direction, it is the management structure in the company that is empowered to deliver it. Your PPSO is very much part of that management structure and as such is in a fantastic position to influence and control how well the company executes against strategy. "Putting first things first" is all about doing the important stuff before everything else. Like Habits 1 and 2, being connected as individuals and as a group to the strategic imperatives will allow you to be key contributors when priority calls need to be taken. Grasp the opportunity to be seen as custodians of strategic alignment and arbiters of priority, and your PPSO will not look back!
4) Think Win-Win
Stakeholders. We talk lots about stakeholders in the setup of PPSOs and also in our programme management frameworks. Do we really understand what our stakeholders want to achieve, and how in helping them to win we can also be winners? Top-notch PPSOs know who their stakeholders are, and actively look to regularly demonstrate value to them. Let's face it, PPSOs need all the friends they can get in the business as especially in these troubled times, the suspicion of being an overhead is hard to defend against. When our stakeholders stand up for us based upon the value we've added to their area of the business, we can truly say that the PPSO has reached partnership status - a mature and developed contribution.
5) Seek First To Understand, Then Be Understood
The old adage that we have two ears and two eyes and only one mouth, and that therefore we should communicate in the same proportions has never been truer. Going back to habit 4, the more we can place ourselves in the shoes of our stakeholders, the better we will be able to help them achieve their goals. That means we have to listen a lot, ask questions, and then confirm our understanding. In other words, as individuals we need to practise active listening skills. Only when you understand your stakeholders problems can you then convey how you can help them. When you can demonstrate that as a PPSO you are aligned to the same needs, then your stakeholders will understand you and support you.
6) Synergise
What a horrible word! But the concept is a hugely important one, and the PPSO is in an almost unique position in the business to ensure that synergies can be realised. Where else in the business is there a maintained picture of the activities under way in the business at both a holistic and a detailed level? Where else can we The very best PPSOs make information sharing a key part of their existence to enable duplication to be eradicated, to ensure that change dependencies are dealt with across the enterprise and most importantly to look for those precious opportunities to get more from less. The mature PPSO and mature PPSO staff alike are constantly conscious of emerging possibilities and strive to create a whole that is greater than the sum of its parts.
7) Sharpen The Saw
"Sharpening the saw" is a metaphor for making sure that the toolbox of the other 6 habits is in good order, and that the tools are regularly used. To make a useful and valuable PPSO, we need to do what we do best with the habits firmly in mind. We need to be expert at using these tools within the business and we need to be seen to be expert, and have our expertise valued. It's taken for granted that we can plan, report, record, organise and all of the other attributes generally associated with a "support" kind of organisation. But to really drive ourselves out of "support" and into "management" or "leadership" we need to be brave and step out of the comfort zone that we're in.
Are you up for that challenge?
The Many Ways of Structuring a PMO - June 2009
Unless you are a hopeless geek like me, this question is of no interest unless it helps you structure your own PMO, right here, right now. Well, attending the ppsosig event in September could take you a long way towards your answer. There is a session on Day 1 that, taking the comprehensive P3O framework as a starting point, runs through the more stable configurations of 'P' Offices in various types and sizes of organisations. At the very least you will come away with an understanding of how your peers are facing the same challenge, what works, and what is a long shot, but worth a try.
Why is structure important? On a pragmatic level it is the most visible aspect as far as the rest of the organisation is concerned: how many staff, what roles, what levels or roles, what authority, how do they relate to other areas, etc. Any business case to establish or re-energise a PMO must be absolutely clear on the proposed structure. After all, others in your organisation may not be too clear on what you do or its value, but they can certainly read an organisation chart.
On a deeper level, structure is important because it dictates how you choose to deliver the services you offer, and how you propose to evolve your PMO to continue improving and being relevant.
Let's look at the Pyramids. Relax; this is not the usual boring aside on how project management has been around for a while. It is way more boring than that. Egypt is not the only place in antiquity to produce pyramids. There were older ones in Mesopotamia, there were stranger ones in South America, and even an inverted one near Xian, where the emperor who built the Great Wall of China was buried with all his terracotta warriors. The diagram below shows a ziggurat, a pleasant ancient type, one of which was the Hanging Gardens of Babylon. Another was the Tower of Babel, but we won't dwell on that.
Fig. 1: Functional areas within a P3O model
Form should follow function, and when it comes to PMO that means that the best structures are those that facilitate the delivery of the services you choose to provide. It's no use denying that the ground on which your PMO structure is built is made up of those old admin and support facilities that were initially provided by PSOs to single big projects. You may no longer do that, but that is the historical foundation. It is important not to forget it, even if you outsource that work, because mundane as it is, it provides real value to your internal customers. Somebody has to do it. Your mission is to make it clear who does it and ensure it gets done. You don't have to do it yourself, and there are real advantages to leaving all that 'admin' label behind.
The first level of structure that needs to be built for our ziggurat is made up of the delivery or support functions and services. P3O recognises that helping programmes and projects succeed directly is the first step. In some organisations, a pretty flat pyramid that ends here is the most appropriate solution. The next stage, building on the previous one is the COE - the Centre of Excellence functions and services. At this point your PMO is setting the standards, possibly training programme and project managers, and certainly setting the pace for what is best practice in all aspects of change management. The final level, which requires the previous two, as well as a certain level of organisational maturity is the strategic planning or portfolio support functions and services.
The ziggurat gives you a clue as to what you need to have in order to tackle the next stage, but it doesn't give you an organisational chart. At this point you need to consider whether your PMO is centralised or decentralised, whether it is permanent or temporary, whether it is physical or virtual. So how do you decide that?
The key is to ensure that your PMO fits your organisation, not some external theoretical model. Hands in gloves, and all that. So you need to consider what are the types of structure that your own organisation actually favours. For instance, if 'decentralised' seems to feel right to you it may be because your organisation has many geographical locations and other departments are already distributed geographically. Or it could mean that every executive or board member likes to control all aspects of delivery in their patch. Your PMO has to match the business goals and the ethos of your organisation. You may have found the perfect PMO described in some journal, but tails never wag dogs: you wouldn't get away with it and you shouldn't.
This is why events like the ppsosig Autumn Conference are so valuable. You can ask other PMO practitioners how they are dealing with the question of structure, what has worked for them, whether your respective organisations are similar in some way, what they hope to try next, etc. You could even keep in touch. And every one there is focused on PMO, no other roles - a small and select band of fellow travellers.
Consider the next question, once you have a broad org chart - how big should it be? If you look at the P3O book (pp. 58-59) you are told that a PMO could be as big as one person, on average between 5 and 10, and easily up to 100+ in some cases. So how do you know? Well, for programme offices you could use a rule of thumb related to the monetary value of the programme (3% to 5%), or another rule related to the team size, where a PMO would be 10% of a 30 strong team or 3% of a 100 strong team. Asking others PMO practitioners what they have done and why is even better.
A more accurate method (same source as above) for larger multi-programme offices asks you to list your functions or services and then estimate about how many hours per week it takes to deliver each, broken down by the different skills and levels involved. Keep in mind that to use this method you need to be sure about your services, i.e., why you offer what you offer and how, which ones are essential, etc.
Also keep in mind that you must take into account the impact of the maturity of the organisation you serve, before settling on a menu of functions.
Given that you may not get a bigger budget (safe bet?), you should also consider upgrading the skills you have and re-aligning existing resources and structures to cope with actual requirements.
Behind the Plan - December 2006
By the time you read this I will away in New Zealand – and might not make the next conference – so what to cover was my dilemma – well two things contributed to the selection of this subject – first it’s a new year and also before I went I attended the first meeting of the PMO specialist sub group in Stratford (M&SPOF) and found this was a hot topic.
Its time to update your Terms of Reference and the Business Case for your PSO/PMO! The start of the New Year and resolutions etc. make this the topic of this month's Behind the Plan.
All PSO/PMO need not just to have these vital documents, but also to update them and or at least review them every year to reflect the inevitable changes in demands for your services that have occurred or just happened.
So what should these look like – First of all they must match – i.e. the Terms of Reference describe what you are doing and how you are to be measured – whilst the Business Case shows the benefits or worth of those services to the organisation and thus the costs that can be expended in delivering them. It is vital that these documents match and are kept in synchronisation.
So what should these documents contain –well each organisation will have its own standards but if not (and anyway as a useful checklist) try these:
Terms of Reference
Background
In this section of the Terms of Reference you must state the background to the PSO/PMO - why was it set up and what is it designed to do. This sets the context of the PSO/PMO. This statement not only defines the situation now it also provides the ability (when reviewing the PSO/PMO at a later date) to see if this background is still valid – if not then of course the whole of the Terms of Reference should be updated.
What does this look like? – Something like this!
“This organisation uses programmes and projects to make changes to its existing business products, services and processes in order to deliver the business strategy and associated targets. The effective management and support of these programmes and projects is critical to the organisation being able to deliver the required business strategy and targets.
The PSO/PMO been established to assist the organisation in two ways:
Firstly to assist in defining what programmes and projects are to be commissioned and ensuring that where relevant all the all elements of the business strategy and targets have a programme/s and or project/s commissioned that will enable that strategic item or target to be obtained. Also that the during the development of those programme/s and project/s they are effectively monitored and controlled in respect of their contribution to their planned contribution to the business strategy.
Secondly to assist in ensuring that programme/s and projects are managed correctly by providing an effective and project support infrastructure which produces added value reports and information to business departments and to programme and project Managers.”
Objectives
The objectives statement must define the performance indicators or service levels that are set for the PSO/PMO. It is vital to select and include in this section those that represented and are acknowledged to reflect the purpose of the PSO/PMO and can be measured.
The more detailed performance measures for individual activities should be defined in a service level agreement document which should also be referred to in this section of the document. This section may look like this.
“The PSO/PMO's objectives are:
• To help the Management Board ensure that the contribution that all commissioned programme/s and project/s make to the defined business strategy and targets is agreed, defined, regularly reviewed and updated to reflect changes in the business strategy and targets
• To provide the management team defined for each programme and project with the information of which a defined percentage is directly applicable and used in that programme and or project as follows.
• Programme and project management control documents (90%)
• Programme and project plans 70%
• Example deliverables for each component in that plan 75%
• Estimates for each deliverables for each component in that plan 75%
• A list of Hints and Tips from previous programmes and projects directly relevant to that type of programme or project and used 25%
Provides the agreed progress and other reports to each of the divisional managers to the agreed timescale 100%.
Provide other services as defined in the prevailing PSO/PMO service level agreement meeting the agreed targets overall for 90% of all occasions
Scope
The scope statement explains the extent of the PSO/PMO services. This statement can define that scope either in terms of the processes that are supported, the people or the parts of the organisation that they support. In most cases it’s a combination of all three. In addition it is worth stating what is not within the PSO/PMO Terms of Reference.
“The information provided the PSO/PMO directly supports the following staff:
• The Board of the organisation in respect of the portfolio of programme/s and project/s commissioned
• Programme and Project Management Teams in respect of programme/s and project/s plans etc.
• Systems development teams in respect of example deliverables hints and tips, tools and templates etc
In addition the PSO/PMO indirectly supports the following processes
•Procurement – By supplying information on the probable requirements of each programme and project.
•HR - By providing a forward projection of required skills in the forthcoming year and analysing shortfalls.
• Service delivery –By providing information to the service delivery team about what programmes and projects will impact the existing infrastructure and when they will need to be tested and adopted by the service delivery teams”
Assumptions
The assumptions section is used to define any working arrangements that the PSO/PMO will adopt. The most common one in this area is to define the relationship between the PSO/PMO and line management in particular in respect of who is responsible for disciplinary matters.
This is particularly important as otherwise it is unclear as to who is responsible for dealing with programme or projects that do follow either the standards that have been agreed or the recommended advice of the PSO/PMO. In addition this establishes whether what the organisation wants is support from the PSO/PMO or a policing role. I personally believe the policing role is not one the PSO/PMO should take on as having such a role can make the provision of support and advice problematic. Thus typically this section looks like this
“The PSO/PMO will operate under the following assumptions:
The PSO/PMO is responsible for assisting programme and project managers and other members of the programme and project management teams to use the relevant components of the programme and project support infrastructures. In addition they are responsible for facilitating the updating of the support infrastructure to ensure that meets the organisations needs.
In performing this function the PSO/PMO will be supported and assisted by the programme and project management teams and also the relevant directors of that part of the organisation.
The line management of programme and project managers are responsible for the enforcement of disciplinary and other measures related to any non conformance of programme and project management team members in following the agreed standards and processes. The ultimate responsibility for ensuring that these standards and processes are used rests with Mr XXX XXX manager.”
Reporting
The reporting section of the Terms of Reference must define both the line management reporting i.e. to whom the PSO/PMO reports in the organisation - often colloquially referred to as “pay and rations” and also the department or committees that it provides reports to. This section may look like this
“ The PSO/PMO is part of the Operations Department and reports direct to the Operations Director.
It also functionally reports to the following managers and committees;
• To the programme and projects commissioning committee for the provision of the agreed reports on the contents of the programme and project portfolio and the progress and analysis reports
• To the head of procurement for the provision of reports on the required procurements by the programmes and projects so that the procurement department can effectively and efficiently procure the required items.
• To the director of HR for the provision of reports which summarise the requirement for skills in excess of the existing resources for the programmes and projects in the portfolio.”
Infrastructure
This final section of the Terms of Reference defines the infrastructure or knowledge that the PSO/PMO will store and hold on behalf of the organisation.
This sectional is optional because the contents of the infrastructure may already be defined in other sections or in the Service Level Agreement that accompanies these Terms of Reference. If it is included then it may look like this:
“The PSO/PMO will store, hold and facilitate the updating of the following information:
• Programme and Project Management Processes.
• Programme and Project Control Documents.
• Template Programme and Project Plans.
• Library of previous programme and project deliverables.
• Estimating guidelines.
• Advice on the techniques used by Programme and Project Managers
• Hints on tips and lessons leant from previous programmes and projects”
Summary
Without Terms of Reference the PSO/PMO and the organisation stands little or no chance of understanding what the PSO/PMO was commissioned to do.
The Terms of Reference will need to accurately reflect the true situation – If the Terms of Reference are defining what the PSO/PMO will be - it is vital to ensure the current services are also clearly defined as well.
The structure of the Terms of Reference must follow the organisations standards – however it is vital that the Terms of Reference defines the performance levels that the PSO/PMO will be judged against.
These performance levels must reflect what the PSO/PMO does and also the value added services it provides “Helping programme and project managers deliver successful programmes and projects” is not a true measure of the success of a PSO/PMO.
This is because that even if the PSO/PMO does supply the programme or project manager with all the support possible they can still make a mess of the programme or project –
The PSO/PMO must be measured on how they supply useful things not their use.
Now for the Business Case – again this must follow the organisations standards and match the Terms of Reference – the one I have included in this article is different to the Terms of Reference above because I felt it was an interesting example as it covered the initial development/set up, as well as the operation of the PPSO, all the figures are of course fictional.
Business Case
Introduction
The following document describes the business case for the operation of the Programme and Project Support Office (PPSO) for XXXX. This document has been developed in conjunction with the proposed Terms of Reference for the PPSO attached as annex XX.
The Aim of the PPSO
The PPSO will perform the following major functions:
• Support the masterplan committee in ensuring that XXX has a portfolio of programmes and projects that will enable it to meet its strategic goals and targets.
• Support the masterplan committee in monitoring and controlling the agreed portfolio.
• Supporting programme and project managers in using the organisation’s programme and project support infrastructure.
• Act as the custodians of the programme and project support infrastructure.
Options Examined
The options examined in this business case operating this service are:
1. No nothing - do not have a PPSO.
2. Set up an internal PPSO .
3. Outsource the operation of the PPSO.
Option One has not been evaluated as it has been established that without the PPSO the required benefits will not be obtained.
Operation of the PPSO
The PPSO will provide the following services.
1. Maintenance of the masterplan, including progress reports.
2. Support of the masterplan committee.
3. Research work for the masterplan committee.
4. Provision of information to other business departments.
5. Provision of coaching to programme and project managers.
6. Assistance with planning and using other parts of the programme and project support infrastructure.
7. Maintenance and updating of the programme and project management infrastructure.
Operation |
Man Days |
1. Maintenance of the masterplan, including progress reports. |
200 |
2. Support of the masterplan committee. |
100 |
3. Research work for the masterplan committee. |
100 |
4. Provision of information to other business departments. |
50 |
5. Provision of coaching to programme and project managers. |
100 |
6. Assistance with planning and using other parts of the programme and project support infrastructure. |
100 |
7. Maintenance and updating of the programme and project management infrastructure. |
50 |
Contingency 12.5% |
100 |
Total Man Days |
800 |
Benefits
Quantitative 1 |
Current |
Future |
Saving |
Direct |
Increase in number of projects managed by each project manager. |
Each manager looks after 1 project. |
Each manager looks after 2 projects 1 large and one small. |
Elimination of recruitment of 3 project managers |
3 x £60,000 |
Reduce number of programmes and projects |
Current portfolio is 150 |
Estimated to be £100 |
Reduction in number of contractors required |
10 x £100,000 |
Elimination of unnecessary programmes or projects |
Currently £3 million expenditure |
Reduced by 10% |
10% of £3 million |
300,000 |
Quantitative 2 |
Current |
Future |
Saving |
In Direct |
Reduction in effort in correcting repeated mistakes. |
Currently approx. 1000 man days per year |
Reduced to 250 |
750 Man days |
750 x £200 |
Time spent by staff developing standards. |
Currently 75 man days per year |
Eliminated |
75 man days |
75 x £200 |
Reduction in external audit requirements. |
Currently 40 days per year |
Time spent on each reduced |
10 man days |
10 x £1000 |
Reduction in the time new project managers take to “bed in”. |
Currently 6 weeks |
Operational (with coaching after one week) |
25 man days x 1.5 |
25 x 1.5 x £300 |
|
|
|
|
£186,250 |
Cost Profiles – External Developer £700 per day, External Operation £500 per day, Internal Developer £300 per day, Internal Operation £ 250 per day, Users £200 per day
Cost Benefit Analysis
Option Two |
Year 0 |
Year 1 |
Year 2 |
Year 3 |
Costs |
|
|
|
|
Development |
475,000 |
|
|
|
Operation |
100,000 |
200,000 |
200,000 |
200,000 |
Total Costs |
575,000 |
200,000 |
200,000 |
200,000 |
Benefits |
|
1,136,250 |
1,136,250 |
1,136,250 |
Net Cash Flow |
(575,000) |
936,250 |
936,250 |
936,250 |
Discount Factor |
1 |
.909 |
.826 |
.751 |
Net Present Value (NPV) |
(575,000) |
851,051 |
773,342 |
703,123 |
Cum NPV |
(575,000) |
276,051 |
1,049,393 |
1,752,516 |
Option Three |
Year 0 |
Year 1 |
Year 2 |
Year 3 |
Costs |
|
|
|
|
Development |
475,000 |
|
|
|
Operation |
200,000 |
400,000 |
400,000 |
400,000 |
Total Costs |
675,000 |
400,000 |
400,000 |
400,000 |
Benefits |
|
1,136,250 |
1,136,250 |
1,136,250 |
Net Cash Flow |
(675,000) |
736,250 |
736,250 |
736,250 |
Discount Factor |
1 |
.909 |
.826 |
.751 |
Net Present Value (NPV) |
(675,000) |
669,251 |
608,142 |
552,923 |
Cum NPV |
(675,000) |
(5749) |
602,393 |
1,155,316 |
Risk and Sensitivity Analysis
The major risks to this Business Case are:
1. Delayed realisation of the benefits (up to 6 months).
2. Only achieving 50% of the benefits.
3. Initial development and subsequent operation costs are 25% more than budget.
Effect of Risks on the Cost Benefit Analysis
Baseline |
Approx. Cum Year 3 |
Option Two Cum NPV |
1,752,516 |
Option Three Cum NPV |
1,155,316 |
Risk One |
|
Option Two Cum NPV |
1,652,516 |
Option Three Cum NPV |
1,055,316 |
Risk Two |
|
Option Two Cum NPV |
48141 |
Option Three Cum NPV |
(549059) |
Risk Three |
|
Option Two Cum NPV |
1,577,516 |
Option Three Cum NPV |
1,155,316 |
As a result of the evaluation of the impact of the risks – It would be unwise to proceed with Option three.
Recommendation
The recommended option is two - internal staff operate the PPSO.
Best Wishes for the New Year
David Marsh
Previous "Behind the Plan"
Published during 2006:
September 2006
This last three months I have been helping set up a Project Office in an Information Systems Unit – This has been an interesting task as I was building this PPSO on the back of a new IT Services outsource contract.
The department had been run previously on what is best described as Heroic Endeavours – every one running around but not much co-ordination.
Anyway the new contract demanded that way the department did its business became the subject of formal processes and procedures and in doing this the new head of the department identified that a Project Office should be established.
The Project Office role first of all got to grips with supporting the running of the contract – i.e. defining and agreeing the processes for everything from service requests to procuring new bits of kit. This resulted in approx. 80 plus processes plus also system build documentation running to many hundreds of pages – having got this straight their attention then moved to dealing with management of the work packages and small projects undertaken by the department staff.
A large number of such projects were found - however very little in the form of project control documents or governance was to be found even though they searched high and low.
Politically the situation was on fire – these projects were overdue and it seemed that everyone and his dog were involved. My advice was to put all of these into moratorium and get them all gateway reviewed to level “O” (strategic fit). This was communicated to all the interested parties and the reviewed commissioned.
The Gateway Review was carried out in a couple of days and showed that in essence stopping them all was the right answer as really what was required was in essence two projects – one to improve the intranet and its operation and the other to review of all the business support data bases and work packages and develop them into a more co-ordained framework.
Over 10 projects became just two – Each now was a meaningful bit of work. So what abut the ten projects I hear you cry – in essence these were potential solutions to the requirements of the new over arching projects. However now work is underway in defining these two large projects it seems as if these original project’s don’t all make sense. Yet again it’s a question of making sure you do the right projects before worrying about doing them right!
To see this change through the management of the organisation has commissioned one further project – To expand the Project Office into helping it ensure that this sort of situation doesn’t happen again.
So what’s that got to do with the next conference – well more and more I see the PPSO moving into this sort of role. The next conference examines this is in depth and will help you formulate your business case for expanding your PPSO into this vital role
See you there
David
August 2006 - What is a Benefit?
We are helping an organisation with a PPSO that is dedicated to the definition – planning for and delivery of the benefits from a series of programmes and projects. This interesting assignment is unusual because the PPSO is targeted at that rather than the conventional area of activity.
One of the first problems we had to face was to arrive at the definition of benefit.
Is it financial, quality or what is it. This started us thinking – first stop the dictionary – well the web - this revealed the following useful definitions;
- Something that aids or promotes well being – for the common good –
- Profit
- Be beneficial for – “this will do you good!)
- A term used to indicate an advantage profit or gain attained by an organisation.
My favourite was:
“Inclusive terms used to quantify the positive expected results or outputs of a proposed activity, project or programme expressed in monetary or non monetary terms – ideally estimates of all benefits outputs or effectiveness expected to be received or achieved as a result of undertaking a proposed activity, project or programme. Realistically a particular programme and its outputs – some intended and very specific beneficial outputs, although some attendant outputs may be negative or non beneficial”
So what did this mean to us –first we needed to ensure that the programmes and projects used this term in the same way – otherwise total confusion would ensue. So a workshop was facilitated by the PPSO with all interested parties to discus and come up with the definition they were to follow together with a sort of code of practice which gave illustrations or examples of such benefits.
The next step was to amend the standard programme and project documentation and management processes to include a new product – the Benefits Definition Report.
(This report rapidly became regarded as important as if not more important than the plan!)
The definitions definition report contained the following;
- A list of the benefits to be provided
- How those benefits supported the business plan
- A definition of how and by whom the benefits were to be measured during and after the programme
- A definition of any dis-benefits that had been identified and a plan for how these were to be managed/minimised
- Formal sign off by the board that they understand what and why the programme was being done and their authority to proceed
The programme and project organisation structure was modified to include the relevant senior manager as the benefits manager with a defined role and activities in the programme and projects. This person reported directly to the Board.
The measurement of the changes made and the benefits realised was the main focus of the work of the PPSO. This meant that the PPSO got involved in lots of the business functions to get the required information.
This new PPSO is now 3 months old – I will be interested to see what it looks like in six months – I think as a minimum it will have a name change.
February 2006 - I recently went to see a new client who was interested in having some advice on setting up a PSO. The trip although a long way away seemed straightforward – I calculated the possible time it might take and added on a half hour for contingency. However on the day it proved not to be so straightforward– the travel gods obviously decided it was my turn to have all the bad luck going.
At the first problem (road works to deal with a collapsed sewer) I assessed how late I was likely to be and added a bit more for any further bad luck that may occur and phoned the client to let them know about the problem and the new ETA.
Having cleared that obstruction on I went for a hundred or so miles only to arrive at the admittedly short tail of a queue on the motorway caused by an RTC Road Traffic Collision (have you noticed how its not an RTA any more!).
A further calculation revealed I was still within the tolerance I had given myself – however as a precaution I phoned to tell them I had been further delayed.
The final problem was I suppose of my own fault – for the last two years I have grown to rely on Norah for navigation in the car – Norah is the sat nav – so called as she nags me to do things - hence nagging Norah! – Anyway in adjusting the screen to make the image larger I managed to crash the whole system – by the time I found somewhere safe to stop and restart her I had missed the turn off and had to do a twenty mile detour. (I suppose it’s the equivalent of your partner throwing the maps out of the car when you ask - ever so politely for directions).
This used all the contingency I had – however I did arrive within the time I had last estimated. Very interesting hear you say – what’s that got to do with us?
Well a number of things – first that trip was really a project – So when I missed the first checkpoint I recalculated the possible outcome based on experience –but I added extra for further bad luck. I continued to monitor and to keep an accurate picture of where I was, not just as compared to the original but to the new timetable and informed the client accordingly. Did the client mind you being late? – well no – because I had updated them well in advance they had been able to reschedule.
Again just like a project - - well no because in most projects the overall lateness usually comes as a surprise to the client at the end – when suddenly the project becomes weeks late in last couple of days.
So the moral – ensure you update the client early and continue to do so – if one thing goes wrong then usually more will follow so allow for this – (if you don’t believe me look at the records of projects in your organisation).
Published during 2005:
October 2005 - The Trouble with Search Engines
One of the main reasons for having a PPSO in a lot of organisations is that they provide information – information on lots of things for – hopefully lots of different folks!
Anyway what got me thinking was the problem I recently located a hotel for a trip to London – Not a problem I hear you cry – however it is when what you want is a hotel with a Secure Car Park (for the Beast – those of you who attended the September conference know what I am talking about) that would be able to give a guaranteed car park space.
I tried the normal route – using Google and then other search engines – but all I could find was hotels that had car parks and the only way to find out if they did have a secure car park was to phone them.
The fun really started then – in one case I was connected to a call centre in Holland – then in another to one in goodness knows where.
So what’s this got to do with you then – well I got to thinking – what would happen if I asked a similar question of the information you store – can you handle multiple level or complex search questions about the information you collect and store.
That’s a good question I hear you say – most of ours’ is stored away in the same sort of structure or the categories that we get it in – plans in plans – hints and tips in hints and tips etc..
As a consequence we may be missing a big trick here – what about storing the information in a mechanism that could answer the same sort of complex query that I was trying to solve?
Some years ago I helped set up such a system using a document management software suite and search engine – we had to do this – not because of the ideas I have been talking about, but because they had lost the plot as regards Configuration Management of key documents. The search engine was slow because the PCs etc were slow so it only just about met the requirements.
However the world has moved on and so has the technology – perhaps its now time to turn the information we have into a knowledge warehouse and deploy such software systems as will enable a new and different groups of users to find the answers to their query
David
PS – The only hotel I found (were it was not going to cost me £24 (plus VAT) per day for the car) was the IBIS Hotel in Lillie Road
July 2005 - In Computer Weekly published on the 12/7/05 there was an interesting article on the Getaway review process used by government to attempt to stop runaway projects – If you can get access to this then I would add it to your library of cuttings. This article had some interesting statistics. 67 Gateway(ed) projects were examined and it was found that:
50% of the projects had a green status
28% had amber
22 % were red
43% of projects improved after the gateway review
38% remained the same
19% got worse
What got me thinking was – how could a project actually get worse after a Gateway Review.
Its one thing to let the project get out of control or whatever – but to ignore the advice given and then when it is reviewed again its even worse strikes me as criminal. The blame for such a situation must lie at the feet of the Project Board and in particular the Senior Responsible Owner. So why would a sensible very senior manager not do something about the situation I mused. The only conclusion I could come to is that they didn’t know what needed to be done or how to do it. So what’s this got to do with you PPSO people – I believe rather a lot – how much of your time do you spend helping the Project Board and SRO? If it’s like most –it’s very little apart from sending them the various reports. I believe this is an area where you can help make a difference by considering moving up from the little help you are currently giving to the BIG help that is obviously needed for these folk.
This help could in the form of a training course in how to be an SRO – perhaps get the Gateway Reviewer to come and explain what is a good SRO. The concept of establishing centres of excellence in Programme and Project Management which is tasked with doing this sort of thing is another answer.
Whatever you succeed in doing even if its small – may help – doing nothing will do just that.
The final thought I had on this was – Is this a typical set of statistics for projects – probably – Gartner Group statistics nearly always show that up to 25% of projects are a total write off – QED?
June 2005 - Will it ever be right?
I received an interesting email the other day from the old PRINCE User Group – They have metamorphosed into a new organisation which now covers nearly all the Government methods – Great Idea.
So what was it that caught my eye – well it’s about the issue log they keep on behalf of OGC for changes to and corrections etc to the methods. The PRINCE2 method has been corrected at least 7 times to my knowledge – However this newsletter told me that they had received so many issues that they were forming a technical panel to deal wit them. So what was it that interested me – well whatever happened to Quality Checks/Reviews – are these methods exempt from them – probably is the answer I must conclude if they are still finding such errors etc. This leads to the main part of this article – how do you plan and organise for Quality Checks/Reviews.
In all too many projects the Quality Check of a product or deliverable is not included in the plan – so little thought is given to it. So what happens is either it’s not reviewed or it’s given a review by not by the right people with the right instructions of what to look for.
The start point of this problem is in the plan – all deliverables or products are in essence three – the draft – the quality check/review report on the draft and the final product. Only if you structure the plan this way will you ensure that the product has a fair chance of being reviewed. You would number them 1.1, 1.2, 1.3. Each of these sub products would then be resourced and a product description produced for each. The Product Description for the check/review report should include the criteria the reviewers have been told to use in the review as well as the Quality Criteria for the product itself.
Again the use of the quality criteria in the product description is vital and so is updating them to reflect lessons leant – say later on if the product fails in some way – the reason for the failure should be investigated and quality criteria devised that can be added to that product description next time to avoid that failure in the future.
So what does this mean for you?
First change all your template plans to show the three part set of each products, (Draft, Quality Check, Final Product).
Second produce some product descriptions for the review activity/report and finally make sure whenever something which passed review and is later found to be faulty – that the cause of the problems are ascertained – quality criteria to stop it happening again are added to the Product Description Library. Perhaps the owners of the PRINCE method should consider this as well!