Project Management

The Money Files

by
A blog that looks at all aspects of project and program finances from budgets, estimating and accounting to getting a pay rise and managing contracts. Written by Elizabeth Harrin from RebelsGuideToPM.com.

About this Blog

RSS

Recent Posts

Who really owns the project budget? Clarifying financial accountability

How to learn AI the sensible way

Making sense of project cost reports

How real PM mentoring actually works

The Accidental Product Manager: What project managers need to know

Categories

accounting, agile, ai, appraisals, Artificial Intelligence, audit, Backlog, Benchmarking, benefits, Benefits Management, Benefits Realization, Bias, books, budget, Business Case, business case, business case, Career Development, Career Development, carnival, case study, Change Management, checklist, collaboration tools, communication, Communications Management, competition, complex projects, Conferences, config management, consultancy, contingency, contracts, corporate finance, corporate finance, cost, Cost Management, cost management, credit crunch, CRM, data, data security, debate, Decision Making, delegating, digite, earned value, Education, Energy and Utilities, Estimating, events, FAQ, financial management, financial management, forecasting, future, GDPR, general, Goals, Governance, green, Information Technology, Innovation, insurance, interviews, it, Knowledge Management, Leadership, Lessons Learned, measuring performance, Mentoring, merger, methods, metrics, multiple projects, negotiating, Networking, news, Olympics, organization, Organizational Culture, outsourcing, personal finance, Planning, pmi, PMO, PMO, Portfolio Management, portfolio management, presentations, privacy policy, process, procurement, product management, productivity, Program Management, project closure, project data, project delivery, Project Success, project testing, prototyping, qualifications, Quality, quality, Quarterly Review, records, recruitment, reports, requirements, research, resilience, Resource Management, resources, risk, Risk Management, ROI, salaries, Schedule Management, Scheduling, scope, Scope Management, security, small projects, Social Impact, social impact, social media, software, software, software, Stakeholder Management, stakeholders, Strategy, success factors, supplier management, team, Teams, testing, testing, timesheets, tips, training, transparency, trends, value management, vendors, video, virtual teams, workflow

Date

4 factors that make a project risky

Categories: risk

linkedin twitter facebook Request to reuse this  

Risk is inherent to all projects, and you need to know the risk profile of your project in order to be able to budget accordingly and prepare your contingency funds. So what does make a project risky?

In his book, Risk Happens: Managing Risk and Avoiding Failure in Business Projects, Mike Clayton shares some of the typical factors that bump up the risk level on projects. These are categorised into 4 areas.

Strategic

Strategic factors include weaknesses due to operational strategy. For example, if there is a weak link between the objectives of the project and the organisation’s goals, that increases project risk. Poor sponsorship and buy-in at senior levels also increases the risk of a project. This can lead to unrealistic expectations – again, another risk factor. Finally, if you have a poorly defined scope, or project goals that keep changing, you increase the risk of the project.

Capability

Even strong project sponsorship and clear goals won’t help you if you or your project team don’t have the skills to do a good job. Poor processes in place across the project organisation can also increase the risk levels on the project, especially if these are not designed to be scaled up (or down) to fit the size of your project. Finally, if your team is under-resourced this also influences the risk profile.

Process factors

Processes keep projects running. Communication is one process that has a major impact on project risk. Don’t forget communication between the team and any partner organisations, as well as communication between team members and other internal departments. Using technology that doesn’t work because it hasn’t been properly tested, or technology that you don’t really understand are also ways to increase the project risk profile. Inadequate (or non-existent) governance processes including a suitable way to quality assure your project are contributing factors to increasing risk.

Organisational factors

How the organisation works can also influence the risk levels on the project. For example, low morale across the company makes a project more risky, as does resistance to change. If your company is focused on price and cost as the way to determine if something provides good value, that could also introduce more risk to your project. That ties into immature procurement practices – buying stuff is normally a risky area of projects anyway, so a poor organisational approach to procurement can have a detrimental effect on project risk.

Managing risk

You can use these four headings as way to categorise and structure your risk log. I’m sure you’ll also find that there are other risks affecting your project that don’t fit into these headings – there are a number of other ways to structure and organise risk logs, so you should adapt your own to meet the needs of your project and your team.

What additional factors do you consider that increase the risk profile of your project? And how do you manage them?

Posted on: September 30, 2012 06:05 AM | Permalink | Comments (3)

How customer-centric project management processes evolved

Categories: stakeholders

linkedin twitter facebook Request to reuse this  

As this month's theme is project management at the cutting edge, I thought I would share with you this extract from my new book, Customer-Centric Project Management, which gives a new take on the traditional approaches to stakeholder management and post-project reviews.

Putting customers – and by that we mean internal colleagues or third party partners who take a service from another department – at the heart of how we work is a worthy aim. Companies spend a lot of time on focus groups and surveying end customers – consumers who buy products – but not a lot of time looking at how departments within the company serve each other. There might be an annual staff satisfaction survey which is the opportunity to air views on how different teams work together, but this type of conversation is rarely routine. Once you realize that as a team, you have internal customers too, making yourself easy to do business with is the next logical step. Customer centricity is a mindset; a way of working. It is, however, very hard to measure attitudes and behaviours in any unequivocal way.

Exceed was designed to provide an unequivocal way to answer the key question that keeps senior executives in PMOs and other delivery teams awake at night: how good is my organization? To answer that, you need clarity of customer perception, a focus on customer engagement and the deliverables that matter to project customers.

We use a process called Exceed to measure customer satisfaction with the project management process. It was developed to establish the basis of real agreement about the value being provided to stakeholders, and to develop closer engagement with customers using language that everyone could relate to. Here’s how it all began.

A global financial services company successfully implemented a customer-centric approach in its IT department. The IT service delivery function was already highly efficient, having demonstrated continual successes through a number of initiatives. Rationalization, in-sourcing and outsourcing had delivered operational savings of over £1m for three consecutive years. A further project to implement a technical support centre with a 50–strong team in India within nine months of board approval reduced annual spend by a further £1.8m. This project was completed without disruption to service, on time and to budget and proved the ability of IT to successfully deliver complex technical and sensitive projects in a very short timescale.

Shortly after this latest success, the CIO found himself in a frustrating position. The head of the company’s retail division had rung him to complain that the software updates his team desperately needed had not been implemented as promised.

The CIO’s department had a record of regular cost reduction and project delivery. That very week, the retail division had benefited from a further £250,000 cost reduction, delivered directly to this manager’s bottom line as a result of a telecoms contract renegotiation carried out by IT. However, without the software updates, retail branches could not satisfy their customers. The financial results may have been good, but they did nothing to improve customer service or the perception of IT within the retail division.

There are a number of morals to this story. Delivery organizations – and project teams are delivery organizations – need to clearly understand how to fully satisfy all of their customers’ needs at all times and in every situation. There also needs to be an agreed and credible process which proves the quality of the level of service being provided. In this case the IT team was doing a good job. Or were they? Who thought so? In fact, what really defines success for an organization, project or service and how do we measure and quantify it? After all, customers and stakeholders come in all shapes and sizes. They are not only demanding – their requirements are diverse and not always feasible or realistic.

Customer-centric thinking cuts through the confusion by answering a number of key questions:

  • How professional is my operation?
  • How good are we at delivering services or projects?
  • What does good look like for us?

These are the questions that need answering if you are going to truly be customer-centric. Exceed is the process we use to get there.

The Exceed process in his department began with a simple vision: ‘Every customer of IT service delivery will continually rate the services we provide as Good, Very Good or Excellent’. While you might think that this vision could never be achieved, the team achieved rapid results from the first few weeks and they fully achieved this vision in less than six months.

There wasn’t anything special about this particular CIO or his organization. It was just about putting the customer front and centre and working in a customer-centric way.

And that’s how we started to work with project teams and sponsors in a customer-centric way.

This is an edited extract from Customer-Centric Project Managementby Elizabeth Harrin and Phil Peplow (Gower, 2012).

Posted on: September 26, 2012 04:23 PM | Permalink | Comments (0)

When do you really know the cost of a project?

Categories: cost, books

linkedin twitter facebook Request to reuse this  

When do you really know how much a project will cost? At the beginning, when you work out the business case? During the project start up phase, where you prepare your budget and establish the processes to track spending? While you are using Earned Value Management and can forecast forward predicted spend? After you have spent your contingency budget? When you do the close out report?

There are so many moments where you can calculate your project’s cost. Michael Cavanagh, in his book Second Order Project Management (Gower, 2012), argues that none of the points I have mentioned are right.

He believes that you don’t find out how much your project is going to cost until after the project is complete – a long time after.

“Although it has been said often that the only time you know the cost and duration of a project is when it has been delivered, in truth, you don’t,” he writes. “Post-delivery costs including fault correction, maintenance, support and disposal are all subject to the vagaries of implementation in the real world and should be addressed and included in the estimation process.”

In other words, you’ll never know during the project implementation what the overall cost of your project will be. This is perhaps less of a problem for the project manager. I think you can justifiably say that we are only responsible for managing the budget up until the point the project is closed. That’s what we plan for and budget for, and manage towards. Any costs that are incurred after this are not part of the project and therefore Not Our Problem. Project managers manage project costs, and as soon as it stops being a project cost it is hard to consider it our responsibility.

However, this is a problem for the contracting process. You can’t have a project that enters into a contract where the contract is only fit for the project stage. Unless your contract is with a vendor who will only be around during the project implementation, like a hired-help contractor. If you are buying software or a service, or equipment, you want the contract to include maintenance and support. Those are after-the-project costs.

So while you might not know how much your project will cost overall, you can do something about helping the operational team who come after you to manage their costs. Get them involved in the contracting. Ask them how they manage ongoing costs and how you should be factoring this in. What is the lifespan of the product or equipment you are buying? What decommissioning costs should you factor in? Ideally get the project sponsor or the operational team representative to represent themselves during the contract discussions. You’ll get a better result, even if it does mean sitting in the room with lawyers for several days.

Do operational teams get involved with preparing the cost predictions for projects in your company? And when do you think the responsibility of the project manager ends when it comes to managing the budget?

Posted on: September 13, 2012 04:17 PM | Permalink | Comments (0)

How Accounts Payable can help you

Categories: video, accounting

linkedin twitter facebook Request to reuse this  

Transcript

 

As a project manager you are not the only person in your company who is interested in tracking where the organisation’s money goes. As well as the project expenses the Finance team will also track all company expenditure but they can be a great ally when you are looking at project costs.

If your project costs include more than just staff time you could potentially be buying goods and services as part of your project. Your role will include authorising purchase orders, raising them and checking when the invoices come in and processing the invoices. Your role could also include working with suppliers when they don’t get paid on time to try to resolve any payment queries. Now the team in your company’s Finance department who will be the most help to you with all that is the Accounts Payable team.

In a large company you may have an Accounts Payable team made up of a number of different people but you could also have a multi-functional Finance person who provides Accounts Payable services, if you like, as part of their role. So the first step is to find out who deals with Accounts Payable.

An account payable is something where you have received an invoice and the company needs to pay it. As a project manager the things that you are most likely to be buying are goods and services. There is normally – well, there should be – a wall between people who can approve invoices and people who can actually press the button to pay the money that goes out the door of the company. That’s so that people can’t raise invoices to themselves and then process the invoice and pay themselves. So it’s a security feature and it’s quite an important thing.

So you may well be able to submit the invoice for payment but you won’t ever see anything to do with the bank accounts. That’s what the Accounts Payable team will do on your behalf. The most useful thing that they can do apart from that general administration and processing of invoices is helping you resolve queries with suppliers. If suppliers come back to you and say that they haven’t been paid on time, it is that person that you will need to ring to find out how you need to get the invoice processed, if there is a problem with the invoice, why it’s got stuck, maybe they didn’t receive it, maybe the money has been paid but it’s gone to potentially a different account, and they can deal with all those things for you.

That’s a really good relationship to have as a project manager as it can smooth out queries with suppliers. So if you know who to talk to in Finance for invoicing queries you can build better relationships with the people who are working with you on your project.

Posted on: September 08, 2012 09:22 AM | Permalink | Comments (1)

Management reserves and contingency reserves: what’s the difference?

Categories: accounting, contingency

linkedin twitter facebook Request to reuse this  

Picture of cashDo you have contingency on your project? In Eliyahu Goldratt’s book Critical Chain he calls it safety, but whatever name for it you use, most projects have an element of budget provision put aside in case of emergency.

Let’s start with a definition of what management reserves and contingency reserves are, taken from Michel Thiry’s book, Program Management.

Contingency reserve: “a planned amount of money or time which is added to an estimate to address a specific risk.”

Management reserve: “a planned amount of money or time which is added to an estimate to address unforeseeable situations.”

Can you see the difference?

Contingency reserves

When you work out the contingency reserve for a task or project estimate, you do so based on project risk. How do you want to respond to that risk? Most times risk responses require cash or extra time to put a plan in action. The amount of contingency allocated depends on the risk and also on the risk response.

As contingencies are linked to particular risks, if the risk passes and is not realised, the need for the contingency goes away. That means returning the cash, or taking any extra time out of the task schedule. You don’t get to keep the contingency ‘in the bank’. If you feel that you need to, it’s probably because another risk is looming on the horizon. If that is the case, you should increase the contingency related to that risk and make your plans accordingly. It is OK to change your contingency strategies as you go forward with the project – after all, as you get nearer to a particular risk event you find out more about it and have more knowledge about how you would deal with it and that is quite likely to change your response.

Management reserves

Every project could do with one of these! However, in my experience few projects have them. A management reserve is a pot of money of a size that is based on the overall uncertainty of the project. For example, if you are doing an innovative project that your company has little experience of, you would want a big pot of money (or time) as your reserve. If you are working on something relatively straightforward, perhaps something that your company has run several times before, you wouldn’t need such a large amount or in some cases any amount of management reserve at all.

Management reserves are generally calculated using that well-known finger-in-the-air method, although it would be good to think that they are scientifically worked out based on the experience of the company and historical data extrapolated from previous relevant projects both at your company and across your industry. However, it is more likely that you just guess.

Management reserves are only used in emergencies, and that is the reason (in my opinion) that many projects don’t have them. The default for projects without management reserves is to go back to the project sponsor, explain the situation and ask for more cash, or more time. If you can do that anyway, what’s the point in having a management reserve? You still have to ask permission before you dip into the reserve, so the actual process for getting your hands on the money or authority to change the delivery date is the same.

A management reserve means that at least the money is put aside for you, and you avoid the situation where the project sponsor says that there is no additional budget available for your project – in which case you’d be stuck finding a way to deliver what you needed with the available money, which would probably involve changing the timescale or compromising on quality (the classic iron triangle constraint).

You don’t give back what is left of your management reserve when the crisis has passed. The pot stays active until the end of the project, although you may find that towards the end of the project when you have more certainty about how things will unfold, you can give back some of the money or use it for something else.

Now that you know more about management and contingency reserves, do you have these on your projects?

Posted on: August 26, 2012 12:11 PM | Permalink | Comments (14)
ADVERTISEMENTS

"Very deep. You should send that into Reader's Digest, they've got a page for people like you."

- Douglas Adams

ADVERTISEMENT

Sponsors