Project delivery in the IT space is a fun job. You get to do interesting things, usually no two things are exactly the same and in the process get to play with technology. Life couldn’t be better. That is until you run into some oddities. Agile methods have not been everyone’s cup of tea. Ambiguity is the enemy of most bureaucratic environments. Before committing to any spends, they want assurances in triplicate exactly what they would get for the project, when, and in what manner. By definition killing any agility.
Republished from my blog Project Management in Practice.
What is interesting is that some of these organisations appear to be embracing Agile, but not because they want continuous improvement, or are looking to deal with ambiguity differently. They have found the dreaded requirements analysis phase of a waterfall project does not necessarily capture the requirements correctly, and consequently deliveries do not meet the outcome they set out to. Pushing that detail to be worked through in an Agile development method makes perfect sense.
Pushing the resolution of ambiguity later in the development phase means at the project initiation that ambiguity still remains. So any contracting for those services can only give you an estimate to a particular level of detail. What I find in many cases is there is little room for ambiguity when contracting for those services. The bean counters still want to know exactly what you will deliver, when, and how – so when the auditors turn up, they can show a clean bill of health.
As IT practitioners we have done a good job of convincing organisations of the benefits of Agile deliveries. However, we are yet to convince procurement that effort estimation is relative to the ambiguity that has been clarified. Wherever bureaucracy is involved, there appears to be a mismatch of expectations. It is not helped by IT companies willing to do business sometimes ignore their practitioners to take such projects and perpetuate this expectation.
What are you finding out there? Is this the norm or the anomaly?
Image credit: smokejumperstrategy.com
Nearly 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.
Reposted from my blog Project, Program and Portfolio Management in Practice.
What is a project?
Neither of the two main project management bodies have very similar definitions of project.
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
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 …
Image credit: lewisaccountingandtaxservice.com
Couple of years ago I wrote a post on whether managers needed technical background to be successful. That article had a specific focus on project management. I have recently been thinking about the same topic on a slightly different context.
Re-posted from my blog Project Management in Practice.
I recently embarked on an Executive MBA. The first paper I’m taking for the course is Accounting. The aim of the paper is not to turn managers into accountants, but to enable them to make sense of accounts, the information these give and what can be used to make management decisions. My study group contains an executive from local government, a consultant that works with ministers and mayors, a statistical analyst from a government department. I manage part of an IT professional services consultancy. We all seem to have forged successful careers which require interpretation and forecasting of financial information without being accountants. So I wondered important is domain knowledge really?
You can argue that we have taken up MBA precisely because we may have realised there is a gap in our expertise. There is an element of truth to that. Let’s explore this further. Most professional careers will require you to have some sort of qualification. Whoever is the team leader in that setting is one that is appointed on the basis of their experience and/or expertise in that area. It can be helpful in the next step up to managing business units as well. Once you get to group / divisional level usually domain knowledge is less helpful. You require expertise in other areas of business to be successful. Executives in your business may have little or no knowledge of the particular domain area, but they will usually bring significant strategy and business knowledge.
There are different skills required in different areas of management. Can you effectively devise strategy if you had no domain knowledge of the business. The answer is no. This is where senior managers use domain expertise to bounce ideas off, find what is feasible and risks and rewards of various approaches. Senior managers are judged by their ability to understand the totality of a business and impact of choices that get best outcome for the enterprise.
This need to get away from the details at certain levels is why many brilliant technical staff do not necessarily make great managers. Those that wish to move up the chain will at some point have to give up their control of specific areas they look after (be it engineering, software development, teaching) and trust others to provide the expertise and spend the time understanding the business as a whole. This is not an easy thing to let go of.
Photo image credit: elandcables.com