No news is good news: Management by Exception

Are you fed up with boring Project Management meetings? Are you in an interminable cycle of weekly meetings? Are you overdosed by tedious Powerpoints?

It could be that you are suffering from “management by meeting”. If the only way that your company can manage a project is to hold weekly meetings with everyone round the table, then they are doing management by meeting.  Another day, another meeting.

There is an alternative. There is a way to reduce the number of boring meetings. It’s called Management by Exception.

Management by Exception is based on constrained delegation. Delegation with limits. When the delegation is in place, then you apply the old saying “no news is good news”. If there’s nothing exceptional going on, then you probably won’t have a meeting.

Here’s how it works:
    •    you propose a plan with some defined constraints
    •    when the plan is agreed, your manager delegates
    •    during the period of the plan, the delegation is in place…
    •    … unless something “exceptional” happens, notably if you exceed any defined constraint

So you only need a meeting if something exceptional happens. You don’t need management by meeting!

Let’s look at an example. Let’s imagine a project to install some packaged software.
    1.    You divide the project into stages. Let’s say that one of them is the software selection stage
    2.    You write a short document with your criteria for software selection; you create a work-plan for the software selection stage, with two constraints
    ⁃    The software is supposed to cost 30k€, plus or minus a tolerance of 10k€
    ⁃    The stage is supposed to take 2 months, plus or minus 2 weeks tolerance
    3.    This plan, including the constraints, is approved by your project board, so you start work. They know what you are doing, and when you plan to do it, so delegation is in place. Limited delegation - you can’t exceed your tolerances!
    4.    You send a regular weekly report to the board, showing your progress.

Let’s now see why it’s called Management by Exception, by looking at two scenarios, the best case scenarios and the worst case scenario.

Best case: For this stage of the project, you are broadly on time and on budget. Nothing exceptional takes place. You find the software and finish this stage of the project. No weekly meetings are required during the stage.

Worst case:  For this stage of the project, things are difficult. Let’s imagine some possible exceptional events
    1.    You can’t find suitable software
    2.    You can’t find anything under 50k€
    3.    You will need 3 months to evaluate and select the software
If any one of these exceptions occurs, then you need to get back ASAP to your board. You are outside of the delegation limits, so you do need a meeting.

So we only have meetings when they are useful. That’s why Management by Exception has big benefits
    •    It saves management time - it limits the time wasted in meetings
    •    It lets the PM manage, and helps avoids micro-management by top managers

Let’s be clear, Management by Exception doesn’t means laxity and absence of control. It is a practical approach, it is is not an idealistic “zero meetings” dream.

Some meetings are needed - for example:  
    •    at the start of the stage to agree the plan
    •    at the end of the stage to review the stage, and to plan the next stage
    •    if anything exceptional happens

It’s a best practice approach. It’s a cornerstone of the Prince2 family of methods. Prince2, the Project Management method uses management by exception. It is also used in MSP (Programme Management), MoP (Management of Portfolios) and P3O (Project, Programme and Portfolio Offices).

So if you are fed up with boring Project Management meetings, then bring in a best practice alternative. Stop wasting time, week after week after week. Move to Management by Exception.

If you want to get things done, prioritise

If you want to get things done, you need to prioritise. Not all things are equal. In this busy world, if you don't prioritise, you won't get the right things done.

This simple truth applies at all levels. At the lowest level, it applies to your personal productivity. At the wider level, it applies to your project, your team or your company. If you don't prioritise, you won't drive things through and get the essential things done. You'll get distracted on the way by myriad lesser details and secondary priorities

Personal productivity

Getting things done (GTD) is the current fashion. An American guru called David Allen has pioneered a method called GTD which has been commercial success for him, but a disaster for many people's personal productivity, The fashion has created a tsunami of GTD offerings - there are hundred of Smartphone apps, Mac and PC software apps, books, websites and videos based on Allen's work. All of these can lead you into the same trap: you end up with long, long lists of un-prioritised tasks, which you try to pick off one by one. Do you get more things done? For many people, the GTD method doesn't increase productivity; it produces a mess. It's like a compost heap – a large, untidy mixture of assorted tasks, some old, some new; some urgent, some trivial.

There are better ways to work, and better apps. An early app came 10 years ago with the Palm Pilot, before Allen wrote his book. The Palm was a predecessor of the smartphone, and part of its success was due to its excellent ToDo app, which prioritised tasks as ABC (and, of course, also by category). You knew what was important. Today, there are a few good alternatives to GTD, such as the 2Do app, which prioritises tasks in 5 ways (Star-High-Medium-Low-None). This works, this really does help to get the right things done. You know what's important, even if you have hundreds of pending tasks.

Project priorities for on-time delivery

In the work environment, some project methods prioritise to stay on target and on time. The AgilePM method, based on the DSDM Atern variant of Agile, uses MoSCoW prioritisation. The MoSCoW acronym stands for "Must Have", "Should Have", "Could Have", "Won't Have". Using MoSCoW prioritisation, you prioritise your scope (features or needs) both at the project level and also timebox by timebox. This is a powerful technique, which really does help you to get the right things done, and - very importantly - to guarantee on time delivery. (It's an Agile technique which you can transfer to non-Agile projects, using Waterfall methods or methods like Prince2).

Portfolio prioritisation model

At the big picture level, it's important to prioritise too. If you are running a set of projects and programmes, you have a portfolio which you ought to prioritise with care and intelligence, so you can deliver your strategic objectives. If you don’t prioritise, you can end up busy, but getting nowhere.

The best practice approach is to prioritise using a combination of the attractiveness and achievability of each project or programme.

·       Attractiveness should be based on multiple criteria, such as alignment to your high level strategy and expected ROI (return on investment)

·       Achievability is typically based on the delivery risk (probability of success)

Best practice guides like MoP (Management of Portfolios) and P3O (Project, Programme and Portfolio Offices) tell you how to do this. They suggest that you start by getting agreement on a Portfolio Prioritisation Model. Once this is agreed, you can use it to assess both your current portfolio and your "demand" (the pipeline of new ideas and requests which could become lines of your portfolio). This is proven best practice. This works.

So whether you need to get things done at the personal level, the project level or the portfolio level, you need to prioritise. If you don't, you'll probably lose your way. If you do, you may really get the RIGHT things done.

Time for timesheets.. or wait until tomorrow?

If you want to get control of your projects, you should use timesheets. Or should you? Is the accepted wisdom really wise?

Timesheets allow you to measure effort; i.e. man-days of work. All project management methods suggest you should control time and cost. Human effort one dimension of cost. It is normally expressed in man-hours or man-days of work (which usually can be  converted into a financial cost). To control effort, you need to estimate it when you plan and then track the actual effort. That’s where timesheets come in, to track the actual effort.

The Prince2 project management method follows this approach. The Prince2 planning process has an estimating step. For Prince2, effort is the primary resource estimation for each task. (Secondary resource needs include equipment, travel or money). By saying that you should control effort, Prince2 ask you to plan and then to track effort. Prince2 therefore assumes that you will use timesheets.

That’s what they are doing at one major bank using Prince2. Effort is indeed the main measure of project resource estimation. A small banking project may have a budget of 50 man-days of effort, whereas a large project may have a budget of 3000 man-days. To monitor progress, the bank uses timesheets to record actual effort by the project teams. So, for example, a 10-week project estimated at 50 days may finish with 45 (or 55 or whatever) actual days of effort. This is calculated from the timesheets of all the project team members submitted during the 10 weeks.

So timesheet solutions aggregate a lot of data from a lot of people. You need timesheet software, which lots of people need to use correctly and regularly. That’s where the problem starts. The software vendors will tell you that the software is easy to use (maybe true, maybe not!), but they won’t always tell you how much work is needed to achieve a sustained, widely-used solution which truly delivers benefits to your wider organization.

In some organisations, there can be hundreds of people working on various projects. A large hospital tried to implement a timesheet solution to control project effort.  Inside the IT department of about 50 people, this worked OK.  But most projects go beyond IT. The hospital has about 3000 staff, very many of whom could work on a project. You can’t ask 3000 people to fill in timesheets, just because some of them may work on a project from time to time.

Even for the small IT department, the hospital hit another problem, of scope creep. Once they had estimates of project effort for their teams, they had a partial forecast everyone’s future work plans. So they decided to go for a 100% solution, and complete the picture with plans on non-working time (holidays, etc.) and non-project work (support, maintenance, staff meetings, etc.). Once you try to manage the full working week for your entire team, you add extra complexity for little benefit. The hospital could not sustain the effort, and the timesheet solution failed.

There are a lot of failures with timesheet implementations. It’s hard work and there can be a lot of resistance. People don’t like filling in timesheets. It takes a lot of work to get everyone to submit a time sheet each week (and to sustain this 52 weeks per year). Furthermore, if you succeed, the data quality may be low, and consequently the benefits for project control may be slim.

Timesheets can work well in certain environments, for example where hours are billed to the customer. Or in closed environments, such as software development teams, where all projects are done by a limited number of project team members. In these cases, there is a clear benefit to the organization, so you can more easily succeed with timesheets.

If you choose not to implement timesheets, what can you do? One major chemicals company has decided not to use timesheets today for their projects. They know it’s premature – timesheets wouldn’t work today. Their solution is to track cost and time, but not effort.  Costs are tracked (expenditures); time is tracked (activity start and finish dates); but effort is neither estimated nor tracked.

So should you use timesheets? If your goal is to improve your team’s or your company’s project management maturity, yes, it should be on your long term agenda. Should it be a priority? You need to analyse timesheet deployment as a long term project. It’s not a quick-win software implementation project – you need sustained long-term commitment to get any benefits. Work out the business case, study the risks of failure.

You’ll possibly find that deploying timesheets is not a priority project. Your return on investment is perhaps too uncertain, your risk too high. Focus instead today on easier project management improvements with more certain benefits. Wait a while until you tackle timesheets. Mañana, demain, morgen, tomorrow.

Four ways to build value in Portfolio Management

Getting started with Portfolio Management is typically quite easy. Essentially it’s all about reporting. But once this is in place, what next? It’s easy to lose momentum and get trapped in a weekly cycle of reporting.

To make sustainable progress on Portfolio Management you need identify how to add additional value from Portfolio Management. This way, you can make sustainable progress. You won’t lose momentum.

The first step in Portfolio Management is reporting. You gather all the various project, programmes and change initiatives together. This may take time, but it’s reasonably easy. If you are working at the enterprise level, your enterprise portfolio is the sum of all the approved, active change initiatives in your company. If there are a lot of initiatives,  focus on the bigger ones. If you are working in a department such as I.T., your I.T. portfolio is the sum of all your approved, active I.T. initiatives, including those which support other departments.

This first step is typically fruitful, as it invites answers to several pertinent questions:
- what projects and programmes have been approved? 
- are project and programmes well defined (are there overlapping projects? are some projects part of bigger programmes?)
- do you have wildcat projects?(unofficial, i.e. active but not actually approved)
- do you have zombie projects? (dormant, i.e. approved but not active)
- do you have straggler projects? (the project should have closed, but instead has drifted into maintenance or support work)

Reporting is the first step. What comes next? How to sustain momentum and avoid the trap of low-value repetitive reporting?

The way forward is to identify where your company needs to add value with Portfolio Management.

There are basically four ways to add extra value

1) Target the right projects, to generate value
    ❑    You choose to focus on the project approval process. You start to build a project prioritisation model, which is a decision support tool for choosing which projects to run. The model will help to build a balanced, achievable portfolio, aligned to your strategy
2) Help projects to deliver, to protect the value-adding process
    ❑    You choose to focus on tracking and monitoring projects. You ensure project inter-dependencies are managed. You work on resource bottlenecks. You highlight problems and push forward issue resolution.
3) Push for better performance, so more projects deliver well
    ❑    You choose to focus on project performance. You monitor actual performance against plan (on time? on budget? how good are the estimates?); and whether projects following your expected ways of working. Then you feed back lessons and drive improvements.
4) Follow up on business cases, to ensure real long-term value-for-money
    ❑    You focus on delivering value. You ensure all projects have a solid business case, which is reviewed before work starts, at key milestones, at closure - and most importantly in the weeks and months after closure, to ensure benefits are really sustained.

When you can identify where to add value, you have a goal. A destination. Once you understand your destination, you can plot the journey: your next next steps become clear.

An invaluable next step is to benefit from other people’s experience to guide your journey. For Portfolio Management, you now have guidance in the form of the MoP framework (Management of Portfolios) and the P3O guide (Portfolio, Programme and Project Offices). For example, the MoP guidance explains how to build a portfolio prioritisation model, while the P3O guidance explains how to to build a value proposition.They are interlinked - MoP helps you to define your destination, while P3O helps plan out the journey.

When you know your destination, when you have a plan for the journey, taking the next steps is easier…

Mapping the future, mapping the past

 This is about understanding the past. It’s a case study, but it’s more than that. It’s about how we can better understand the past if we have a frame of reference.

The case study explains how a large company improved its project & portfolio management.

This multi-national organisation was structured as 7 business units. They had an ambitious change agenda. To deliver this huge amount of change, they needed to improve their project management.

They ran a 3-phase improvement initiative to improve project management
    ❑    Phase 1 introduced Prince2 project management, supported by heavy-duty EPM tools (Enterprise Project Management software)
    ❑    Phase 2 measured regularly the improving maturity, by measuring the use of Prince2-based methods and the tools. With these measures, they found the weak spots, and took corrective action
    ❑    Phase 3 introduced portfolio reporting. It started once the level of maturity of Project Management was acceptable - it needed good quality project data as the starting point for consolidated portfolio reporting.

We can understand this case study in terms of P3O. That will be our frame of reference. P3O  provides organisations with a top-down approach for improving their P3 (P3 stands for projects, programmes and portfolios). The O stands for Offices, so P3 + O gives P3O.

So let’s use the P3O framework.  How does this case study look in P3O terms?

Retrospectively, we can detect the gradual construction of a P3O model, as the 3 phases advanced
    ❑    Phase 1. Local CoE functions were set up (Centres of Excellence) supporting the deployment of Prince2.
The local CoEs
    ⁃    published standards, procedures, templates
    ⁃    provided training, coaching
    ⁃    ensured tool support
    ❑    Phase 2. A centralised the CoE function emerged. The local CoEs were merged into a single unified CoE.
The central CoE
    ⁃    measured the maturity of Prince2 and tool using with a P3P3 approach (P3M3 is a maturity model)
    ⁃    provided an Information Portal with standards, procedures, templates, etc
    ⁃    continued to provide coaching to teams with low maturity
    ❑    Phase 3. A Portfolio Office structure was deployed, with a central Organisational Portfolio Office managed by a senior manager.
Each Portfolio Office
    ⁃    introduced Portfolio Design - budget management, demand management, resource optimisation, portfolio optimisation
    ⁃    coordinated Portfolio Delivery - monitoring and control of projects, data consolidation, status reporting

This provided the foundations for solid Project Management.
We can see that the P3O support was a key enabler
    ❑    The P3O structure was a key enabler of for project management.  Without support from the CoE structures, this major Prince2 and tools deployment would not have succeeded, and the high maturity levels in Project Management would not have been achieved.
    ❑    The P3O structure was also an essential enabler for Portfolio Management structure. Without the Portfolio Office, the ambitious work to structure Portfolio Management would not have progressed. It was beyond the reach of the business managers responsible for the portfolios - the support of the Portfolio Offices in the P3O model was vital.

By looking back at the past, we learn lessons by finding a good frame of reference.

Now look forward to the future. To improve your organisation’s project management, use a good frame of reference. Try using the P3O framework to map out the future.

Focus on transformation not PMOs

How a focus on business transformation programme gave the right PMO solution

I recently spent a couple of days with a fast growing hi-tech company in snowy Stockholm.
I was invited to help them with their PMO deployment, but it soon became clear that their urgent needs were based on an upcoming business change. They needed to shift focus.

They were looking at their PMO needs because their business is growing FAST and they are running more and more projects, so they had identified the need for a PMO solution. However, the company founder has recently announced a new organisation structure. The business is expanding worldwide, and the company needs regional operations. It can’t operate only out of Stockholm any more.

We started out as planned, working on the PMO agenda. I took the team through the basic P3O guidance. P3O is the OGC guidance about Projects, Programmes and Portfolios (that’s the P3); and specifically, on the “Office” structure needed to support the P3. Just to be clear, “P3” plus “O” gives P3O. The offices are commonly called PMOs, but the guidance is called P3O.

During day one, the picture became clear. The new organisation chart announced by the boss was going to transform their portfolio structure. So indeed P3O could help. However, faced with business transformation, P3O is not enough.

The P3O guidance does explain that a transformation programme based on MSP is a good way to roll out your new PMO solution. However, in the context of imminent business change, what’s the way forward?

According to the P3O best practice, the best way to add a PMO solution to your existing business is by running a transformation programme. So it became clear to me that the way forward was to wrap the two initiatives together, both the business reorganisation AND the PMO solution, all in one transformation programme. The programme should address the immediate business reorganisation first; and postpone some of the less urgent PMO work to later.

So here is what we did in the remaining time. We covered a lot of ground!

Step 1: Make sure everyone understands the basics of Portfolio Management as the business reorganisation will create new portfolios. For this, I used the new Management of Portfolios guidance from OGC, which is called MoP

Step 2: Focus on the business transformation programme. As a meeting room exercise, we drafted some of the key documents of the early MSP processes, notably
- Vision statement
- Blueprint after business transformation, including some basic PMO elements

Step 3: Focus on the final goal, including additional PMO elements. We drafted more MSP documents
- Final blueprint
- Project dossier
- Risks

This leads to a two-tranche programme which should deliver short and medium term solutions. Tranche 1 is business reorganisation, supported by the basic PMO structure; tranche 2 adds a full-strength PMO solution.

This has to be two tranches. The major change of reorganisation will be a big effort for this company. The second tranche will consolidate the work of the first tranche; and drive out more benefits.

So the lesson is this. Don’t focus on PMOs when you need wider business change. The business change is the priority, and your PMO structure should come out of that change programme.

A long term vision for PMOs

A bonus for a Danish public sector organisation

In November, I was in Copenhagen to work with people from the IT side of a large Danish public sector organisation

The plan was to focus on training about PMOs, but we went much further. They got their training but they also got a bonus.

The training was loosely based on P3O. The Danish team uses Prince2 for Project Management, and MSP for Programme Management. These are the existing cornerstones of the OGC guidance, so quite logically they are now looking at P3O, which is the OGC guidance on PMOs.

The P3O guidance for OGC is about Projects, Programmes and Portfolios (that’s the P3); and about how to support the P3 with an “Office” structure. That’s where the acronym comes from: “P3” plus “O” gives P3O.

In the first half of my visit, we covered all the P3O basics, of how to justify a PMO solution (that’s called the P3O value model) and how to design a PMO solution (that’s the P3O model itself).

In the second half, I expected to explain how to roll out a PMO solution (that’s called deploying the P3O model). But I spotted an opportunity. As the Danish team are skilled users of MSP best practice on programme management, we could do more than training. I put away my training material and all my prepared case studies, and focussed on the one case study which really interested my client – their own organisation.

So we started work on designing and implementing the client’s own PMO solution. That’s better than training. As the Chinese proverb says, “Tell me and I'll forget; show me and I may remember; involve me and I'll understand.”

We drafted several MSP documents
- Vision statement
- 5 year blueprint
- Risk analysis
- Project dossier

This went fast, and was very productive. As the Chinese proverb says, the Danes were involved, and they understood. But they didn’t only learn. They also concretely started work on their future P3O programme. That’s a bonus.