Project Management in Practice

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

Category Archives: Project Status

What can accounting and finance teach project and program management?


what-can-accounting-and-finance-teach-us-about-project-program-managementNearly two decades ago I took one accounting paper and did just enough studying to pass it. I was studying for an IT degree at the time and only did the paper as it was a compulsory one. Wheels have now turned enough for me to come back to doing an MBA and by coincidence, starting back with accounting as my first paper. Today though my attitude is different. I can see use of quite a few accounting principles in managing projects, programs and portfolios – be it the IT domain or any other.

What is a project?

Neither of the two main project management bodies have very similar definitions of project.

… a temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case – PRINCE2

… temporary in that it has defined beginning and end in time, defined scope and resources … unique that it is not a routine operation – PMI

What is the shortcoming in both definitions? Both are approaching the project from the point of view of those that are charged to deliver the outputs. Project teams do not undertake projects because they think it is a good idea. Where is the customer in all of this? It can be argued that the mention of the business case in the PRINCE2 definition means it now represents what the customer gets out of it. None of these are as clear as the accounting definition of project

an investment that increases the wealth of the owners.

You can define the terms owner and wealth to what is appropriate in your context. But this definition is the most focused one that I have found anywhere. If anyone was unclear as to the outcome they should be delivering, this leaves no room for doubt.

Is this project/program worth investing in?

Business cases for projects contain all manner of justifications. Accounting and finance provide the mechanisms for relative comparison. Whether justification is based on additional cashflows, reduced expenditure, or increased efficiency accounting provides mechanisms to objectively compare them. Key strength of accounting is it takes into account the time value of money too. A dollar earned today is much more valuable than a dollar earned sometime in future. The concept of Net Present Value (NPV) provides a way to compare cashflows that are invaluable tools for such comparison. Accounting also has very clear formulas to calculate break even points given different amounts of fixed and variable costs. Many business cases fail to address these fundamentals. It should be mandatory for those involved in preparing and evaluating business cases to have understanding of these concepts.

How is it going?

Accounting is full of metrics. Whether you are measuring efficiency, turnover, income, cash conversion cycle (how long before you lay money out for raw materials to when you get paid for it), what a share or bond should be worth etc. The closest project management comes in a traditional sense is earned value management (EVM) and more recently the burn down charts in some of the agile practices. Some service management organizations are better at it. They do measure mean time to failure and restore among other operational metrics. Singular focus on analysis and improvement on these is something project management can learn from.

How do I report?

I have seen and prepared all manner of project reports. If I don’t see another Red Amber Green report, I don’t think my life will miss much. While these reports are useful in getting our eyes focus on likely areas of problems they are pretty useless in contextualizing what the problem is. This is where accounting leads just about any profession. Generally accepted accounting principles (GAAP) mandates interpretations of exactly how reporting is undertaken. I am somewhat generalizing to make a point about standardization of reporting.

Does that mean accounting and finance have it all over project management? Not quite. The two are totally different disciplines. You can equally play the accounting system as the likes of Enron, Fanny Mae and Freddy Mac would attest to. The key is to take the strengths of other professions and make ours even stronger. As I go through some other papers I feel there may be a few more posts coming titled what can ” ” teach …

What parallels with other professions can you see?

Image credit: lewisaccountingandtaxservice.com

Enhanced by Zemanta

5 things to do when projects go wrong


5-things-to-do-when-projects-go-wrongAnyone spending a decent amount of time in project management field will sometimes have projects from time to time that experience significant difficulties. For all the planning, it is never possible to predict all the eventualities and therefore foreseeing all risks. Projects are by nature more risky than other business activities. It is always useful to apply a few techniques to aid in such situations.

1. Show leadership

An oft repeated cliché this is something that is hard to explain in terms of action. When things go wrong there is plenty of nerves in the project team and management. Project team members often struggle to think beyond their immediate problem. You will find internal executives or sponsors worrying about contractual obligations and any fallout with the customer. Showing leadership in this context is to ensure this uncertainty does not spread into panic. The role of the project manager is to steer a clear course and stopping any blame game that may raise its ugly head. Now is not the time for that. Focus on why after the project.

2. Avoid temptation to simply throw more resource

A common reaction to a struggling project is to throw more resources at it. If the project is of high visibility and management is not able to provide subject matter expertise, they will feel they need to contribute somehow to correct it. The commodity at their disposal is resources. Be wary of this. More cooks do not equate to a better dish. You may need to enlist some mentoring for project team members or even yourself if you are managing a project outside of your technical expertise. Always consider how much time it will take before new resources can contribute to the project. If the issue is time, you will virtually ensure a delayed delivery by adding resources. Also take into account the additional communication required to successfully integrate them.

3. Avoid sugar coating

There is a temptation to play things down as things start going wrong to avoid creating panic. I have found it easier to be transparent about progress. Late surprises will compromise integrity of the project like no other. While your stakeholders likely be upset with you, in the long run it will get you more respect. You need to be clear with communication internally. If you need some of your resources to be allowed uninterrupted project time, you need to give that clear sense of urgency. Otherwise, you will not get the outcome you desire. Clear does not mean antagonising your people. You may need the same people later in the project or for a subsequent project. Do not burn bridges.

4. Undertake review

Very often when a troublesome project is completed, people are so pleased to see the back of it, no learning takes place. This is just about the worst thing you can do. You are not making sure same problems are not repeated. Wait for a reasonable period after project closure to undertake review. While things are still raw, people are more likely to be defensive and the value you get from the exercise will be limited. When you review, structure it so everyone has the ability to come forward with what they could have done better. Start yourself to show the way. If people are forthcoming, leave it at that. Your aim should be to avoid repeat, not to be punitive.

5. Follow up

Do not leave the review in a document and expect the next project to pick up on it. Use the information from your review to recommend training plans and process changes for the organisation. Present these to someone with influence within the organisation. After some time follow up on progress of the recommendations. Improvement takes hard work and tenacity.

Do you have any rules for managing troubled projects? I’d be very keen to hear.

Managing Projects Better

%d bloggers like this: