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!