The Money Files

A blog that looks at all aspects of project and program finances from budgets and accounting to getting a pay rise and managing contracts.

About this Blog


Recent Posts

8 Expert Interviews To Improve Your Projects

20 Project Cost Management Terms You Need To Know

The Future of Your PMO is Safeā€¦

6 Tools for Project Cost Control [Video]

5 Barriers to Effective Benefits Realisation Management

3 Levels of Risk Management

Categories: events

At the PMI Hungary Chapter international Art of Projects conference in Budapest this month, Rick Graham spoke about risk management in the globalised world. He talked about how Monte Carlo analysis is used to establish risk and how companies gather sophisticated data to make good decisions about the actions they need to take as a result of identifying risk.

Rick said that there are three levels of risk management that apply to projects.

1. Project risk

This is perhaps the most obvious. These risks do not recognise interdependencies and risks outside the scope of the project. Rick recommended doing Monte Carlo analysis at this level to identify project risk. He also talked about scenario building as a good tool for project risk identification and management, giving the example of Shell.

Shell was the only company which modelled the risk of the OPEC countries putting up the price of oil. Because of their analysis they were able to adapt their plants to deal with less refined oil and gained a two-year head start on the competition when the prices did go up.

Rick recommended “building limited models around sensitive areas”: in other words, not spending time on modelling when the risk is low or when it isn’t worth doing. Models and analysis help explain the risk you are taking at the project level in comparative terms, which helps set them in context for team members and stakeholders.

2. Project selection risk

At this level the question relates to how risk plays a part in making decisions about which projects should be started. The challenge here is whether the business just says yes or no to a project without looking at the overall position and the wider business requirements.

For example, a risky project may not be inherently bad for the business. If you always say no to risky projects you end up with a portfolio full of low risk but also probably low benefit projects that present reduced opportunities for the company.

This level links to the strategic objectives and how the deliverables will be achieved in the organisational context.

It should also include the risk of not doing or deferring the project, as that decision presents a different path forward for the business with its own challenges.

3. Project portfolio risk

This is where you start to look outside the projects as individual initiatives and start to gather rich data about the organisation’s approach to risk management as a whole.

Rick recommended doing Monte Carlo analysis at programme level to identify risks across dependent streams of work. He then talked about using this output to identify the right combination of projects to work on at portfolio level.

The problem I found with this model is that there isn’t any level that I can see where risks fit that fall outside the project but that are managed in some shape or form by the project manager. For example, dependencies on other projects – the risk that the other project may not deliver on time. Or the risk that the company might go bust – this is out of scope of the project but something like this could feasibly be on your risk register.

This model also assumes that you have a process to apply risk management to.

Rick said that you can only do portfolio level risk management if there is one single repository of project data. This isn’t the case in many businesses where project managers are based in functional silos and even if there is a PMO it serves one business unit and not the enterprise as a whole.

A spreadsheet is good enough for this: no need to invest in anything more complicated, he said. You can start to put some science behind your spreadsheet once you have everything documented in one place.

Do you measure and manage risk at these three levels? Let us know how it works for you in the comments.

Posted on: November 08, 2014 10:59 AM | Permalink | Comments (3)

Creating a stellar delivery organisation

Categories: events, methods

Donna FitzgeraldAt the Gartner PPM & IT Governance Summit last month Donna Fitzgerald gave a presentation about the factors that go to support a stellar delivery organisation. That’s a fancy way of saying getting your project management maturity levels up so you have a better chance of project success every time.

The Gartner PPM maturity level model includes 5 levels of maturity but Donna said very few clients make it Level 5. “Life at Level 2,” she said, “is no longer good enough. Many organisations are facing the crash and burn. They are operating in a perfectly acceptable paradigm for yesterday.”

The jump for Level 2 to Level 3 is what Donna called ‘crossing the chasm’. It’s the difference between process controls, governance and management and balancing capabilities and delivering measurable business value. That is quite a leap.

Don’t project manage everything

One of my top takeaways from Donna’s presentation was the fact that you don’t need a project manager for everything. Too often I see little projects managed by project managers when the development team or a business team could have managed it perfectly well by themselves (and 10 years ago did exactly that). If you want to do more with the skilled project resources that you have, stop asking them to work on business as usual projects that other teams can handle. “For optimal project success you want the work done in less than 6 months and full time staff of 5 for a half-time project manager,” she said. Project management deals with the uncertain, risky and complicated, she concluded, so if your project isn’t like that, then it doesn’t need a project manager.

If you do have a half-time project manager on the team she recommended time boxing their commitment. It’s now commonly believed that multi-tasking is bad and that humans aren’t very good at switching between tasks. Therefore if you are scheduled to work 50% of your time on one project and 50% on another project, make it so. Work Monday, Tuesday and Wednesday morning on one project and the rest of the week on the other. Don’t try to do both at the same time. A consulting firm wouldn’t expect someone to jump between assignments with an hour here, an hour there, she explained, so you can make fixed time allotments work.

I’m sure you can, but it’s going to be a mindset change for the workplaces I’ve experienced. Project queries and stakeholder phone calls don’t stop because it’s a Thursday.

Define ‘done’

“Done,” Donna said, “means the short list of things that define the business capability [being delivered by the project].” This is not the requirements document as that document is really a contract with an external supplier, she said. I would argue that it’s also often a document for internal supplier teams to work from and while you’re not likely to sue the team that sits on the other side of the office to you, there is a chance that you’ll use the requirements document as a basis to sue a vendor for failed delivery.

Define ‘done’ with your project team and sponsors so that you’ll know when you get there and you can work towards achieving that.

Don’t start without committed stakeholders

This was another major takeaway for me. Donna is ruthless! She said we shouldn’t start a project without committed stakeholders. She said that if they don’t turn up to the initial meetings (as sometimes happens) then don’t be afraid to ‘throw them under the bus’.

Say: “I’m sorry, I didn’t realise this was a bad time to start this project. We’ll reschedule.” And leave the meeting room or their office. Sometimes you’ll come across stakeholders who genuinely aren’t able to support the project right now and that’s OK. Reschedule project initiation for a time when they can commit. But sometimes people are just lazy or unclear on their responsibilities or happy to delegate everything to you and take no role in their project at all, and that’s where the bus comes in.

Make time to reflect

Part of delivering a stellar project organisation is knowing that things need tweaking. And with the stresses of managing projects it is unlikely that you, as a PMO Manager or even as a project manager thinking about your own project culture, have time to do that.

Make time was Donna’s recommendation. “Nothing ever gets fixed if you don’t realise it’s not working,” she said.

Book two afternoons per month to get away from your desk and think. Start with saying, where am I, where are we, what’s the health of my projects, what’s bothering me. Sometimes you can’t see patterns in behaviour because you are too close to them day-to-day so this gives you the opportunity to reflect and objectively assess what is going on.

She recommended we spend 20% of our time talking to sponsors and extended stakeholders as this is good for careers, and it’s what successful PMO Managers do. I don’t think I do that, but it’s certainly something I would like to focus on.

These were the top tips I took away from Donna’s very practical presentation. I hope they help you!

You can follow Donna Fitzgerald on Twitter @nimblepm.

I attended the Gartner Summit as a guest of Genius Project.

Posted on: July 03, 2014 10:14 AM | Permalink | Comments (0)

Project Management Metrics: The Hot Topic at #GartnerPPM

Categories: events, metrics

The Gartner PPM and IT Governance Summit was held in London last week. Lars Mieritz, a Gartner analyst, gave a good presentation about using metrics for communicating project success and effectiveness. He started out by saying that the top concerns of C-level executives and their direct reports, based on their research, were:

  • Demonstrating PMO value
  • Effective reporting and executive dashboards
  • Measuring the business value of projects, programmes, and portfolios.

Gartner has many years of research in this area and he shared an interesting trend: in 2003 the top concern of CIOs with regards to IT strategy was the need to improve governance and provide leadership. In 2013 the top concern was delivering business solutions. There’s been a shift towards integrating IT more effectively with the rest of the business.

Why metrics count

Project management metrics based around portfolio performance help improve the perception of success. When researchers asked people what they thought of their PMO the views were pretty poor:

  • 29% said they got some value out of the PMO but it was largely bureaucratic
  • 33% said it was an integral part of getting things done
  • 28% said it was a useful admin/support function.

As Lars said, he hasn’t spend decades in PPM only to be considered a useful admin function, so it’s clear that PMO customers believe there is certainly room for improvement in the services the PMO provides.

KPIs, said the verbatim comments that formed part of the feedback of this study, don’t link to business strategies. They don’t talk about shareholder value. Metrics relating to output don’t explain how to improve this output. Metrics don’t identify or clarify issues relating to performance. And finally, business management teams can’t relate to technical measures.

So, PMOs have plenty of metrics, but PMO customers don’t understand them or think they are useful. What should we be doing instead?

Creating good metrics

The main takeaway for me from this section of the presentation was that you shouldn’t copy someone else’s dashboard. What works for one business isn’t going to work for another, so templates aren’t actually that useful here. Every PMO is unique and provides a variety of bespoke functions to the rest of the organisation, so you should tailor the reporting and metrics in use to reflect that.

Metrics, Lars said, should reflect a strong customer focus to ensure they are well-understood and take a business view of project success. How is success viewed? he asked. Then shape management communications (i.e. reporting and metrics) along those lines. He offered some questions to ask yourself when putting together the relevant metrics for your PMO:

Is there organisational acceptance for standardisation around a single approach or method of reporting? This is particularly relevant if different business units have built their own measures and techniques over time or due to mergers and acquisitions. Different techniques mean different results.

Are the definitions of KPIs and metrics simple and useful for external comparisons? Even if you don’t need to compare performance of your PMO and projects with other companies right now you can be that someone will ask you to benchmark performance at some point in the future. Make your life easy and prepare for that now.

  • Can you use data from other departments to save reinventing the wheel?
  • Is all the underlying data readily available and more importantly, credible?
  • Does everyone understand why you are gathering metrics and the purpose and objectives of this initiative?
  • Are there sufficient resources to put together a full, comprehensive metrics plan? Do you have enough people or budget to support any training required?
  • Is there senior management buy in? Setting up metrics is, after all, a project and it needs executive sponsorship.

Implementing project metrics

Once you’ve defined what metrics are relevant for your PMO, you then have to go ahead and implement them. Lars recommended engaging with users to ensure they understand the process and how these metrics will help improve things. For example:

  • Average time lag between identifying an issue and corrective action – shows you delays in addressing problems and then you can work on speeding this up.
  • % of projects with complete documentation – shows you where projects might be at risk due to information not being gathered; identifies project managers who many need additional support.
  • % of projects with a status report over 10 days old – shows you where project data is out of date and who needs a kick to remind them to update it.
  • % of total effort required to reach end of first phase – shows you potential for project to deliver on time and accuracy of planning/estimates.

“Good dashboards show where the problems are,” he said. And that gives you the chance to show what you are doing to eliminate the problems.

Dashboards should track what is important. He also had a great recommendation for PMO leaders who have to produce short reports for their colleagues or sponsors: if you don’t have much time to present statistics (or many pages to present on) then cycle round the metrics you show each time. For example, average number of training days per project manager won’t change much from month to month so show this one month and then report on something else next month. Over time it will give you the chance to report on more metrics, and of course if someone wants to see the training days figures they can always ask for them.

In summary, Lars concluded that metrics should enable us to take action, otherwise what’s the point of them? He said that we should seek metrics that are simple, intuitive and focus on goals and that finally metrics don’t replace judgement. You’ll always have to apply your contextual knowledge to a dashboard to interpret the full situation.


I attended the Summit as a guest of Genius Project.

Posted on: June 15, 2014 05:30 AM | Permalink | Comments (2)

3 Types of Complexity

Categories: events, leadership, pmi, research

At PMI’s Synergy conference at the end of last year, Stephen Carver gave a well-received presentation which included some information about the different types of complexity, as perceived by the brains at Cranfield.

He talked about what success looks like on projects and said that the level of complexity faced is part of whether a project is deemed to be a success or not. The 3 types of complexity he identified are:

  • Structural
  • Emergent
  • Socio-political.

Let’s look at each of those in turn.

Structural complexity

This is the ‘easiest’ level of complexity and it involves the scale of the work on the project. A project is structurally complex when it has many stakeholders, workstreams or other elements. There is a lot for the project manager to manage and control, with many variables.

Emergent complexity

This is where the project is changing around you, for example increases to the price of steel in a construction project or stakeholders who were not identified at the outset suddenly needing to be included. It encompasses projects where there are a number of unforeseen issues or where the situation is unknowable, for example where there is a great deal of novelty perhaps in the technical set up or the way the commercials are being managed.

Socio-political complexity

This is where the project suffers from hidden agendas and lots of politics. There is little transparency and at the worst end of the scale maybe even sabotage. There are conflicting priorities and resistance. Cultural IQ becomes really important for the project manager along with being able to adequately manage the people involved and creating a shared understanding of objectives and the project’s vision in order to align agendas effectively.

Stephen said that most training courses cover dealing with structural complexity but in a survey of 246 project managers who were asked which of these 3 areas they found most challenging, socio-political complexity came out on top.

Which is hardly a surprise.

“Projects,” he said, “are deeply emotional things.” Whether the Millennium Dome, for example, was seen as a success or failure is down to your point of view and the passage of time: rebadged as the O2, it’s now a very successful arena and venue. The Sydney Opera House, Concord and Terminal 5 at Heathrow were other examples he gave of projects where the definition of success was difficult to pin down and would mean different things to different people.

“If you don’t do anything, you won’t make any mistakes,” he added. “We do a lot so we are bound to make mistakes.” Unfortunately, on complex projects these mistakes tend to be in the socio-political arena and they can be very hard to undo. Not setting up proper workstream reporting, for example, might give you a structural problem at the start of your project but it’s easy enough to address that sort of complexity and put it right. Dealing with damaged egos or senior stakeholders who each think the project is going to address their own pet issue is a far harder situation to deal with.

He didn’t give any pointers as far as I can remember about being able to deal with socio-political complexity, although I imagine that a 45 minute presentation about project success was never going to have much time to touch on what project managers can do differently (better) in order to address these challenges.

What tips do you have for managing projects with this type of complexity? Is it just good stakeholder management or are there other things that you can do to deal with it successfully? Share your thoughts in the comments below.

Posted on: January 08, 2014 12:44 PM | Permalink | Comments (2)

Hamish Taylor on innovation: think outside your industry

Categories: events

At the PMI UK Chapter Synergy conference (you can see the stage in the photo) last month Hamish Taylor spoke about innovation and getting projects off the ground by looking outside your current industry for inspiration. He is ex-CEO of Eurostar and took over there at a time when the company was facing a loss of £206m. On the day he started they didn’t even have a product to offer as a fire had closed the tunnel and stopped the service.

However, he started off his talk on innovation by introducing his experiences from working at BA. He was instrumental in the project to deliver the world’s first flat bed – while now that doesn’t seem very innovative as all airlines off them, at the time it hadn’t been done before. He started off by approaching the normal company that made their airline seats but the manufacturer wasn’t able to think creatively and the finished designs didn’t really do what Taylor wanted. So he looked outside his industry for people who were used to designing luxury in small spaces.

He ended up approaching a yacht interior designer and they went on to design what eventually became the beds that were used in First Class.

Taylor used the same innovative approach when looking at how they could improve the customer experience at the airport. In 1993 they were struggling with check in queues and customer complaints were going up. So he looked at places where queuing wasn’t a problem, and could even be fun. He got executives from Disney Parks to come and observe the airport and point out what they were doing wrong.

This was at a time, he said, when each check in desk had an individual queue, and whichever queue you chose it was always the slowest. No one was doing a ‘zig zag queue’ where you join one queue and go to the next available desk. But that’s what was happening at Disney. Taylor’s team also picked up some other useful points from the Disney visit:

  • Make the queue really narrow because then it moves faster, even if it makes the total queuing time the same. People will be moving forward so they feel as if the queue is going down and be more satisfied.
  • If there’s a 25 minute wait from this point, tell them it will be 30 minutes so they feel s if they’ve beaten the system when they arrive earlier.

As a result of these simple changes, customer complaints about check in time went down – but the answers weren’t available in the airline industry at the time.

Understanding your customer for projects

“We need to change the way we understand customers,” Taylor said. “We’ve got to get better generally at soft insights, not data.” Insightful customer understanding, he explained, comes from understanding the customer’s world, and to illustrate this he gave an example from his time at the helm of Sainsbury’s Bank.

The project was to set up the bank in the supermarket. The traditional approach suggested a bank information point, with leaflets and a desk staffed by people in uniform. In short, a traditional bank, but just situated in the supermarket.

It didn’t work.

The ‘soft insight’ here was understanding the customers’ mood. When you go food shopping, most people want to get in and out of the supermarket as quickly as possible. They are in a bad mood. They don’t want to have a 20 minute discussion about credit cards while the ice cream melts in their trolley. So instead, the project team created simple products marketed at the right place in the store, for example, pet insurance by the pet food.

Making it customer focused

Taylor gave another BA example in his presentation, that of a project designed to increase the amount of people travelling business class. In their first advertisement, the focus is on the fact that business class has the widest seat in the world. It’s safe, secure, extra comfy and so on. But it’s not about the customer – it’s about the features of the seat.

Then Singapore Airlines launched a seat that was half an inch wider, and the ad campaign had to be scrapped.

Two years later, the ‘BA Club World’ project team had a different focus. It was about helping travellers arrive ready to work and making their journey as smooth as possible. The whole company was engaged with the vision: “How else could you help people arrive better prepared for business?” Taylor knew this approach was working when a member of staff from the lounge called him up and suggested that they serve a meal there as an alternative to having to dine on board. This way, business travellers could get more sleep on the flight and arrive better prepared for their working day.

“Project management is the catalyst for change,” Taylor said, and while he gave plenty of examples of projects, the key message was that unless you look for innovation, you won’t stay ahead of your competitors. As project leaders, we should be encouraging innovative approaches in our project teams and supporting projects that take a slightly different approach – you never know where that might lead in terms of innovation and success.

Posted on: December 09, 2013 06:56 AM | Permalink | Comments (5)

"A noble spirit enbiggens the smallest man"

- Jebediah Springfield