Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Tag Archives: Consulting

How much financial knowledge do Project Managers need?


I attended a training seminar the other day on finance and accounting for non financial managers. It was an interesting training course. If you consider the constraints within which project managers must work to, one is financial. The last time I studied anything remotely close was accounting 101 during the first year of my under graduate degree some 17 years ago.

How much financial knowledge to Project Managers need

The course was run by Victoria University Professional and Executive Development school. Not being a student of accounting and finance, the seminar title seemed like exactly something that I’d be able to use in my project management role. As the course outline was being set out, I realised this was probably the wrong form of accounting for me. The primary focus was on accounting concepts and how to understand company accounts and performance. It appears management accounting is what I should’ve been looking into for making decisions based on numbers.

While I didn’t totally achieve what I wanted to in terms of outcome, it wasn’t a total waste of time either. We focused on importance of cash and return on investment based on various capitalisation models. I had never thought to consider projects, or even business cases along those lines. It is a very useful knowledge to have when considering the straight ROI figures. I will be much wiser to attempts at manipulation along those lines.

This all made me think, how much financial knowledge o you really need to manage projects effectively? Projects are usually incurring expense until such time it is transitioned into the business. Usually project managers will not be responsible for the realisation of he benefits. That means unlike accounting, all the numbers are in one direction. That is why most project managers will be able to get away with limited or no accounting and finance knowledge, as long as te are reasonably good with numbers.

This all changes when the project manger becomes responsible for both generating income and controlling expenses, which is the case in supplier environments. I have a set number of resources that I can utilise for various projects. How I use these resources not only determines success, but also income for my team. In strict sense this is more akin to portfolio management, rather than project management. In this scenario, I found the focus on importance of cashflow and various funding models was very useful.

If you are running a programme that is designed to deliver a financial benefit, I can see a very practical application in terms of analysing if you’re meeting the desired profit targets. Similarly, if your benefits can be quantified in terms of monetary value, then understanding accounting and finance is very useful. However, in general I haven’t found the lack of understanding in this area hasn’t necessarily made life any more difficult, as I am comfortable with numbers in general.

My role involves more than simply managing projects. It also includes forecasting of revenues, participating in the sales process and contributing to strategy among others. I still think understanding management accounting may be very useful. I will probably look to get some more professional development in that area. Again, those in my view are more portfolio management in nature, rather than project management.

What has your experience been? Am I totally off track?

Image Credit: best-financemanager.com

How do I estimate based on risk?


Risk Management - Image from bigthink

Risk Management – Image from bigthink

I have previously contemplated the challenges of keeping to scope and budget and keeping customers happy. If a customer adds new requirements on to a project, it is an easy discussion to have around additional time and cost, or a reduction in scope elsewhere. Grey areas in scope aside, you can show a definite impact on the project because of an omission that needs to be rectified. Where I see challenges are in trying to prevent slow bleeds.

One approach is to state assumptions that all dependencies will be met and manage exceptions by change requests. From experience I find that is a hard way to manage. How long does it take to do a task? The answer is always depends. You may be doing a task very similar to that you have done elsewhere. However, you cannot assume it will take the same amount of effort or elapsed time. The environment where you are deploying, number of other suppliers involved and in-house expertise of your customer all play significant roles. Experience tells us that we must take into account these factors as risks when we estimate project cost and duration.

My area of expertise is in delivery of IT projects. However, I believe the principle is the same in all fields of work. In an IT context, even in simplest projects you will have a customer taking on the task of solving a business problem through a project. The supplier will be engaged to deliver the project to a scope. Usually interactions are required with subject matter experts in the business, the IT service provider for the customer (could be in-house or another supplier), possibly procurement … to note a few. There are risks that we must associate with each of the players and estimate the project accordingly. While it is difficult to create a good risk profile for a new customer, we should be able to build a reasonable picture for customers we deal with regularly.

Think of a scenario where one of the other suppliers delay delivering a component that is a pre-requisite for your delivery. It may only have been delivered a day or two late. However, you have created an optimum resourcing based on something being delivered on the agreed date. In reality, you cannot re-assign those resources unless you have significant notice of the delay. Even if you know well ahead of time, in many occasions it is impractical to re-allocate those resources to another project, due to the short available window. By the time they are up to speed with the other project, it will be time for them to start working on the original assignment. Effectively the supplier through no fault of their own ends up absorbing the cost.

Sometimes the lost time is less than days, maybe a few hours every week due to lax turnarounds to required information or pre-requisite delivery. However, at the end of a project it does end up being a significant impact. You cannot really go back with a change request every time something is delayed by an hour. This will give a new meaning to death by change request. And you can be guaranteed a breakdown in communication with your customer. How so do we then ensure projects do not suffer this fate?

PRINCE2 Risk Probability Impact Grid

PRINCE2 Risk Probability Impact Grid

The only way around this dilemma is to expect some level of these risks materialising. PRINCE2 suggests using a probability impact grid to evaluate risks. While PRINCE2 is predominantly useful for the end customer to run the project, there is no reason the suppliers cannot use similar techniques to analyse risk. It is worth analysing what your particular scale for impact or probability is to get a good feel for impact. When you are constructing your estimates and plans, have these built in.

The key message here is to initiate a change request only when the risk that you have tolerance for in your plan is exceeded. Many IT projects fail to take this into account and bleed. One can legitimately ask why doing a PERT estimate should not take these risks into account for the pessimistic scenario. The key to remember on that is when you get your technical staff to estimate the pessimistic scenario, they are taking into account pessimism from a technical point of view, whether that be an unknown pattern of software development, familiarising with new API etc. They are not taking into account human or communication risks.

In my observation, construction projects are better at taking risk budget into account than IT ones. This is possibly because a half finished construction project is an obvious reminder of a failed project. Failure of an IT project is usually a less visible eye sore. That has probably made those in IT projects lazier than we should be.

%d bloggers like this: