A bridge is a way of displaying financial information in visual format. You might also know it is as a waterfall chart, or ‘the one with the flying bricks that looks like something from Mario’. It’s just a way of showing how an initial position has been affected by subsequent changes, so you can see why that would be useful for a company’s financial position. It can show changes that are positive and changes that are negative, and ends up with the new cumulative position as you can see in this diagram.
This picture shows a completely made up scenario, but I think it illustrates a point. In September, the starting position for this department was $75,000. This could represent value, profit or anything else. Then there were some things that changed. These are illustrated by the small floating boxes: the first change that happened was a positive improvement of $16,000. Then there were some other criteria, inputs and changes that also increased the situation positively.
Now we come to the black boxes. These on my chart represent money out, so let’s say this department spent $2,000 on some new software licences and $1,000 on a big party for everyone. This has had an impact on the net position so if my maths is right, the closing position on the graph, the situation in October, is now $100,000.
Great. But how is this relevant to projects?
Typically this type of bridge is used to represent financial information and you have financial information on your project, don’t you? I think it is a great way to present the impact of changes on your project budget to stakeholders. It’s useful because it’s a good visual representation of how you got from there to here and where the money went.
So you could use it to show the financial changes on your project, but there is nothing to stop you using the same layout to display other sorts of changes. Take this version, for example.
This shows you the situation in September in terms of project days. There are 150 days allocated to this project. Then there are a number of changes put forward. The green boxes show what would happen if you add those changes – the number of days spent on the project goes up (it’s not rocket science really). There are also some changes that save you time on the project. Let’s say that the big one, the 20 day time saving, is because the project sponsor has decided that the overseas office isn’t going to be included in this initiative after all, so there is no need to train those team members and you can save a whole lot of time. Another little change knocks 3 days off your project total.
If all these changes are approved, your project will now take 152 days.
When you are looking at individual changes at the change board, some stakeholders might find it hard to keep approving changes that add time. Two changes that add 10 days each? That’s huge. But when they see all the changes on the table that month laid out like this they can see that approving them all only adds 2 days to the project overall. That’s a very different story.
Of course, you might not want all those changes approved – there might be some stupid suggestions in there or functionality that would be better pushed off to a Phase 2. But using this bridge diagram gives you a new way to present the same data to stakeholders and help them decide on the impact overall.
I hope you find it useful!
At 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.
“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.
As a project manager, there’s one big problem on projects – you are right in the middle of it. You have tight deadlines, unforgiving stakeholders and detailed plans. It is very hard to lift yourself up out of this and see the bigger corporate picture – many project managers can’t do this at all.
You should try.
Being able to see the bigger picture puts your project in context. It helps you operate more effectively. It helps you see what is important to your project and business customers. It makes you a better member of the company, as well as a better project manager.
Here are 5 ways to ensure that you can see the big picture.
Go to internal networking events.
Every company has them. And if, for some reason, yours doesn’t, start one. Got to lunch and learn events. Go to afternoon briefings, or drinks after work, or corporate team building days. Don’t opt out of anything. You never know who you might meet, but more importantly, what you might learn about the company’s focus. You can use this to sharpen your project’s focus to deliver what is really important to the business.
Read the annual report.
Yes, it’s boring. But it is also a great source of information about how the company operates. How does your company make money? If you sell shoes, it’s pretty obvious, but many firms have more complex ways of bringing in the cash. How will your project contribute to this? Is there a strategic thread where your project fits (or is it clear that your project is now irrelevant to the new corporate strategy?).
Read the business pages.
Follow your industry. Not project management, but the industry your company operates in – IT, construction, engineering, retail etc. What’s happening there? What are your competitors up to? Set up a Google alert for the name of your company and your CEO. How does your project fit with what your CEO talks about in the media?
Join an industry body.
In the UK, BCS, The Chartered Institute for IT, represents the interests of the IT arena. It’s not the only IT industry body, but it actually doesn’t matter which one you join. The point is to have another way to find out what’s happening in the big wide world. Read their magazines. Go to their events. Join their LinkedIn discussion groups.
Being able to see the bigger picture lifts you out of the detail and helps you operate in a project leadership role. How do you make sure that you know what’s going on outside of your project?
The OGC’s Portfolio, Programme and Project Office (P3O) guidance includes some information about project management maturity. Maturity is measured on a 5 point scale from Level 1 (not very mature) to Level 5 (very mature) against 7 areas – in P3O speak, ‘perspectives’.
One of the perspectives is financial management. Here’s how you should be performing at each of the different levels.
There is a “general lack of accountability” for monitoring what project budgets are spent on. Projects have few, if any, financial controls and generally don’t have formal business cases. This means it is hard for the company to properly assess potential projects and decide where the organisation’s funds should be spent.
There are a few more business cases around, although there is no standard template. The best business cases will explain the rationale for the project but not necessarily have a lot of financial information in. Still, it is something to go on when deciding what investment decisions to make.
Project managers are applying financial controls haphazardly, depending on their previous experience and skill level. Contingency planning and risk management are done without much consideration of costs. For example, contingency budgets are just made up, instead of being calculated on the basis of likely risk.
There are standards for business cases and how to get business cases approved. Business cases have one owner. Project managers manage cost and expenditure – and there are corporate guidelines that show how to get these done. There will be links to the Financial department or other teams who carry out financial controls.
Level 4 (this is where you should be aiming, if you aren’t already here)
There are processes in place to enable the organisation to prioritize investment decisions. In other words, the financial information available prior to a project starting is good enough to work out whether it is a strategically important project, given the available funds and resources. Project budgets are managed well by project managers, and there are tools in place to enable tracking and comparison of financial information.
Level 5 maturity is a significant jump up from Level 4 and really focuses on complete management and control at an organisational or portfolio level. Financial controls are integrated with the company’s general financial management plans and approaches. Estimates are accurate and produced using estimation techniques which are regularly reviewed: the information feeds into generating better estimates in the future. Most importantly, the organisation can show that project management and the projects that are delivered offer value for money.
I think most companies are a long way from Level 5, but in many cases they don’t need to operate at that level to be effective and to do a good job. Where do you think your company falls within the financial maturity model? Let us know in the comments.