When we hear about all the methods of managing projects, the PMI Body of Knowledge, PRINCE2, home grown and commercial solutions - always look at them in the light of these 5 Immutable Principles and the 5 Practices then implement the principles.
When we hear about all the methods of managing projects, the PMI Body of Knowledge, PRINCE2, home grown and commercial solutions - always look at them in the light of these 5 Immutable Principles and the 5 Practices then implement the principles.
When I hear the phrase we're exploring I'm reminded that in fact many who explore without a plan, measures of their progress progress against this plan, a risk management Plan-B for getting home when things go wrong, and without insufficient resources to survive the trip - come home empty handed or many time don't come home at all. Exploring without these items is called wandering around in the wilderness looking for something to eat.
Here's a simple tale about an actual explorer, Ernest Shackleton, who experienced failure and near death on their first expedition to the South Pole (ADM Scott), that informed his attempt the reach the Pole a second time, only to experience failure again. In the first example prepartion was weak, management inconsistent, and lacking an actual strategy, no Plan-B. The second attempt, without Scott, was well planned, well provisioned, well staffed. When trouble started, Plan-B and then Plan-C were put in place and executed.
Another definition of economics, closer to software developemnt is the study of how people make decisions in resource-limited situations. This definition matches the classical use of the term and is the basis of software economics. Since software product development always takes place in the presence of limited resoruces. Time, money, capabilities, even knowledge. And since software development always is the exchange of those resources for the production of value, looking at development from an economics point of view is a good start for any discussion around improving the process.
Two other definitions are needed before continuing. Macroeconomics is the study of how people make decisions in a resource-limited situation on a national or global scale. Microeconomics is the study of how people make decisions in a resource-limited situation on an individual or organization scale.
For software development, microeconomics deals more with the type of decision making needed for successful projects. And since much of the discussion these days is about making decisions on projects, let's see how the microeconomics paradigm may improve the communication.
There have been suggestions that the book above is old school and no longer applicable to the modern world of software development - e.g. Agile. Since the book is actually about engineering economics not about software development methods, let's see what the book actually says for those who have not read it, heard Dr. Boehm speak, or in my case worked for the same firm where Dr. Boehm lead our process improvement management effort.
This book was a working text, when I attended USC as a Master's student while working at TRW (Boehm's home) for an Engineering Economics course. The book is still in print and available in used form for low prices. So those wishing to comment on the book, without having first read all 765 pages, can now do so at a low cost.
The preface of the book starts with the usual qualifiers, but contains three important objectives
The major objective of the book is to provide a basis for a software engineering course, intended to be taken at the college senior or first year graduate level
So let's look at chapters to get a feel of the concepts of software engineering economics. My comments on the chapter are in italics.
So What's the Point of All This?
When we hear estimating can't be done for software, we actually know better. It is being done in every software domain. Tools, processes, books, papers, conferences, vendors, professional organizations will show you how.
When we hear this, we now know better.
 "Software Engineering Economics," Barry W. Boehm, IEEE Transactions on Software Engineering, Volume SE-10, Number 1, Januarym 1984, pages 4-21.
 This is the crux of the post, the book and the discussion around the conjecture that we can make decisions about how to spend other peoples money with estimating that spend.
From the anarchy of gaming coders sitting in the basement of the incubator on 28th and Pearl Street here in Boulder to the full verification and validation of ballistic missile defense system software, 7 miles up the road.
When I hear about how software should be written, how teams should be organized, how budgeting, planning, testing, deployment, maintenance, transiston to business, transistion to production, sustainment, and the myriad of other activities around software development should be done - the first question is always - what's the domain you're speaking about.
Then - have you tested these ideas outside our personal experience. And finally have you tested these ideas in another domain to see if they carry over? If you're just exploring ideas, no problem. But that limits the credibility of the idea to being just and idea with no actionable outcome, other than a conversation. Those paying for the software you are writing for money, usually don't like paying for you to explore using their cash - unless that effort is actually in the plan.
There are of course fundamental - immutable actually - principles for any project based endeavor. These are the Five Immutable Principles of all project success, shown over and again in the root cause analysis of failed projects.
All five of these principles need answers if we're going to have any hope of success. No matter how often it is repeated, insisted upon, or how clever the message is trying to avoid these principles, they're not going away. They are immutable. They need to be answered on day one and on every day until the project is over.
So if we are writing software for money - internal money, external money, maybe even our own money - ask these questions and see if our answers are credible.
More in next post about the economics of writing software for money.
I heard this phrase in a conference call yesterday with a DOD client and thought, how clever I'll write a blog about this. Only to find out there is a Forbes article with same name and several other articles as well.
The Forbes article had a case study about doing it right around a business process. It was the perfect framework (repeated here) for applying Performance-Based Project Management®
In the Forbes article there are five steps:
In the end project success is about knowing what done looks like, knowing how to get there, how to measure progress along the way. And of course knowing impediments to progress and handling them. These concepts are instantiated in two papers from a colleague Pat Barker, What is Your Estimate at Complete and Program Master Scehdule Can Improve Results, on page 20.
In yesterday's post, the notion of Systems Engineering was suggested as one solutuion to project failure. Here's the next step. The Agile notion started with a manifesto that turned into many interpretations and practices. In the standard project management paradigm, there is a set of principles, practices, and processes described in a variety of ways through several organizations. ITIL, PMI, APM, DOD, DOE, and other owners of project management activities.
When we take the Systems Engineering approach, we can put a wrapper around ALL project management, technical development, and deployment processes, that can be use to assess each practice and process to assure it is providing value. Here's a short overview of this paradigm.
The Five principles of risk management, includes the core concept that cost, schedule, and technical performance are inseparable. There are some in the software business that conjecture software is some how immune from that principle.
These risk principles live in a large context of Five Principles, Five Practices, and Five Processes of project management in general. Project management applicable to all project no matter the domain, technology, tools, methods, business strategy, or those applying these.
There was mention on a Twitter conversation that software projects are somehow unique and the statement #3 is not correct. In fact it is, and here's why.
But first let's start with the Principles, Practices and Processes needed for the success for all projects.
So when it is mentioned that software projects are different and most importantly that somehow cost, schedule and technical performance can be separated, let's consider a few of the mechanics of software projects:
So here we are again back at the foundation of all project work. Cost, Schedule, and Technical Performance (Scope included in this along with everything else not cost and schedule) are inseparable. In order to increase the probability of success for the project the coupling between these three project drivers needs to have margin. Otherwise the project will be whipped by a change in one of the variables
Much has been written and spoken about how to develop and deploy projects using people and their ideas. The FAA's National Airspace System, Systems Engineering Manaul has something to say about this as well
Three steps are needed for success, with the last step being the most critical.
It starts with Brainstorming. Getting ideas out on the table so we can discuss them
Then comes Brainwriting, where the ideas are built into testable concepts. This iterative process of peer review, peer criticism, and peer contribution is very powerful. It is NOT a love fest where everyone is supportive of any idea. But a serious consideration of ideas amoung peers, professionals, and everyone acknowldeging the importance of the mission. This next step is not for wall flowers or the hurt puppies we sometimes encounter in meetings or other channels of communication.
Then the most important process of all, actually tesing the ideas to see if they will withstand the rigor of actual use. This is where many in the softer side of project management, or those who really like to just explore come face-to-face with the reality of spending other peoples money, on a planned time line, with a commited set of capabilities.
The notion of an adversarial group review process is missing from most IT shops, sometimes for the right reason, but sometimes for the wrong reason.
At the bar during a recent DOD Program Management Conference, a colleage (former cost director of a major government agency) came to the conclusion there are three sources of project failure do to unforseen events.
Don't be victum of #2 and #3. Go find out all the problems, all the impediments, all the unplanned impacts including cost and schedule that will derail your project.
Performance-Based Project Management(sm) on Amazon
Here's the Table of Contents and Chapter 2. This chapter is the anchor for the Principles, Practices, and Processes of increasing the probability of project success.
Software development ranges from straight forward, with small a team with a continuous improvement effort. Say a web site or warehouse management application were the customer is happy to just keep the improvements coming. Every improvement or new feature can be put to use. Along the way new ideas enter into the mix and since there is no real deadline, the features can be deployed when they are ready.
On the other end of this wide spectrum of projects is the mission critical, business critical project. For example a Mergers and Acquisition strategy of two large firms that need to join their ERP systems before any benefits from the merger for the customers, operations, and cash flow can be realized. Below is an example of the Plan for such a project.
The first thing to put to rest is the naive and misinformed notion that planning is somehow not needed. The Plan above is a strategy for the integration of legacy systems with a new ERP system. The Planned date for this system is tied to business success. Long before this Plan was developed, the business strategy identified the needed capabilities of the integrated system, the planned savings from the integrated system, and a customer facing set of abilities of the result.
This is the fundamental Return on Investment equation. ROI = (Value - Cost)/Cost. We know the value, since the analysis of the value of the integrated system was done before the merger. The cost was estimated at the highest level from experience of integrating ERP in the past. Details come next, usually after the merger.
Each of the boxes provides a needed capability. End box is an incremental deployment of this capability, with feedback that informs the downstream capabilities. No project can have an end-to-end detailed schedule with any hope of that schedule remaining intact. But the Plan above describes the order of delivery of the needed capabilities. These are not arbitrary, these are not random, these are not subject to change. At least not without understanding the impact on the business merger process and the resulting cost savings and cash flow generation.
So What's The Point
If the value at risk is sufficient to call into question business failure, or at least major issues, if the project fails to meet its goals, then we need a Plan, an estimated cost, and an estimated delivery date. To ignore these business needs is to ignore the obligation to provide that needed information.
You project may not be a merger of two multi-billion dollar firms. But the question isn't when to estimate but when do we no need to estimate. The asnswer to that starts with the Value at Risk. The business providing the funding gets to say what the value is.
What is the business willing to Risk on the project without knowing that value before starting?
Software intensive project work is indeterminate. Many times, customers don't know what they really want until they see something working. Development's capacity for work is not well understood early in the project. Technology emerges and impacts the effectiveness of the project. Reducible and irreducible uncertainties abound. These conditions are normal, they can't be wished away.
So what are the options? Let's start with some advice and see what we can do to improve the Probability of Project Success. Wise leaders from the past have words we can use to guide our efforts.
I know one thing: that I know nothing
The trouble with the world is that the stupid are cocksure and the intelligent are full of doubt
— Bertrand Russell
The fool doth think he is wise, but the wise man knows himself to be a fool.
— William Shakespeare, As You Like It
Knowing nothing about the project is not good for increasing the probability of success. Knowing what capabilities are needed to fulfill a mission or business need is a starting point. Capabilities are not requirements, those come next. Capabilities allow the user to do something of value. This is the value spoken about, most times spoken about in the absence of any units of measure. These measures, the measure of capability is the Measure of Effectiveness. (The tool in the previous link is a systems engineering tool, that provides all project participants with clear, concise, and testable assessments of their understanding of what Done looks like. The notion that tools get in the way of success is ill-informed at best, and just plain wrong at worst).
Measures of Effectiveness are operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in an operational environment, under a specific set of conditions.
If we don't know what capabilities we want the project to deliver, it's going to be a low probability that the project is a success. We don't know what done looks like. Now we can get paid to discover these capabilities. Capabilities Based Planning is a process to discover these. Someone has to pay for this of course. It is usually the customer that pays. But someone has to pay.
With the needed capabilities in hand, we can make our first estimate for cost, schedule, and the probability of success. Here's an example. Frank Cepollina was speaking at the BAA (Broad Area Announcement) for the Hubble Robotic Service mission.
He stated his needed capabilities rather than in techncial requirements. Those always come after we know what done looks like. Notice these capabilities are mission capabilities. Get the job done descriptions.
How much does that cost and when can you have it ready to fly?
The three vendors needed to develop an estimate. The details of this process can be found in Assessment of the options for extending the life of the Hubble Space Telescope. This example can be extended to IT and software development projects. What do we want the system to do? Don't know? Go find out. Make that the first step in the project. Read Predictabilty: A Simple Approach to Creating Reliable Project Schedules, Steve Bockman for an example of how to think about this in a software development environment. No matter what our domain, size of project, we're going to need to understand something about what capabilities are needed for project success. We might be able just to start work and let these emerge. But our probability of success is unknown and that's not likely a good thing in the end.
So when we know something about the needed capabilities, we can start to discover the requirements. But first we're going to need some kind of measure for those requirements. These are performance measures.
These are measures that characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions. These are Measures of Performance, and are:
These are measure of how the requirements are going to perform in pursuit of the mission.
Final we have to discover the Technical Performance Measures. These are attributes that determine how well a system or system element is satisfying or expected to satisfy a technical requirement or goal. These:
Here another need for estimating. How fast do we have to process transactions to meet the needed capability? How much can we weigh and still have the capability to fly? How reliable (mean time between failure, mean time to first failure, mean time to recover from failure), and still meet the needed capabilities?
These estimates are focused on technical outcomes. Thing that fly away, things that provide services in support of the customer. Things.
Where are we going here?
We must learn to estimate all kinds of things on a successful project. The credibility of our skills as project managers is always tied up with our ability to estimate. Can't estimate, choose not to estimate, see estimating as some kind of dysfunction, it is doubtful those providing us with money are going to have much confidence in our ability to deliver that mystical value we are told is part of all projects.
Estimating is part of project work. To not estimate, means we won't know what done looks like until we arrive at the end. That's unlikley to be acceptable to those paying us to do work.
The next step is to determine what requirements will be needed to implement the needed capabilities. These are defined as Measures of Performance that characterize physical or functional attributes relating to the system of operation, measured or estimated under specific conditions.
Notice something important here. Software project success always depends on development of working software. But what software, in what order, with what Technical Performance Measures, Measures of Performance, and Measures of Effectiveness all supporting the needed Capabilities.
Success doesn't start with coding. It's about knowing the answers to the CBP, MOE, MOP, TPM attributes. The notion of emergent anything works only when we can state in some unit of measure what DONE looks like. Without that we're just wasting the customer money exploring, challenging everything, and looking for the mystical Unicorn hiding in the bushes.
So Here's the Punch LIne
When we spend other people's money on our project, private money, public money, government money, they have the expectation of knowing something about how much much and when we will be finsihed with the work in exchange for that money. This is pretty much the case for every project I've ever worked for the past 34 years. It's the basis of every successful business - knowing what your costs are for the operations. So when we hear about developing software for money and not having any concern about the cost of that effort it simply doesn't make any sense.
The common picture of requirements elicitation looks like this. Which of course is an example of doing stupid things on purpose. When this picture is used as an example of not doing something because it doesn't turn out right, is a further example of doing stupid things.
Let's see where the gaps appear that results in the outcome in the last panel:
The wheels fall off when there is no description of DONE shared between the customer and the provider. If the customer doesn't know what DONE looks like, who does? The developers? Probably not. Is DONE emerging? Then the customer has to pay for that?
There is no way out of the need to know what DONE looks like in Measures of Effectiveness, Measures of Performance, Key Performance Parameters, and Technical Performance Measures. Without these the success of the project is in doubt from the start.
The notion that requirements emerge is will established. But the capabilities the customer needs to be stable enough to establish an Estimate At Complete and an Estimated Duration to Complete. Without these the customer has no understanding of the all in cost of the project. These change as the requirements change. That's part of the project management process. This can't be ignored if the customer is to have any confidence in the project providing value at the needed time at needed to be put to use.
So a reminder one more time...
You can't assess the value of the project outcome without knowing something about the cost to deliver that value and the time frame for that delivery.
No matter what anyone says, this is an immutable business principle. Anything is simply fooling yourself into believing that the customer doesn't care how you spend her money or when you spend it.
Focus on value, that's what the customer bought. Actually they bought a capability to do something to improve their business or mission. But ignoring the cost of delivering that value is ignoring the balance sheet of the business.
Projects are composed of three fundamental elements. Cost, Schedule, and Technical outcomes. The Technical Outcomes go far beyond the PMI-style scope terms. In this paradigm, the technical outcomes are at the end of a chain. Here's examples of that chain - Capabilities, Measures of Effectiveness, Measures of Performance, Key Performance Parameters (there are 5 in our domain), and Technical Performance Measures. At the TPM level is where things like quality live, traceable to the KPPs.
These three elements are coupled in dynamic ways. Their connections are springy, in that changes in one has an impact on the other two, But rarely is this impact linear and ridgid. The Iron Triangle notion is really a Three Body problem, in which all three element impact each other and at the same time respond to that impact.
All projects have these three elements, coupled in this way. Changes in one impact the other two. Changes in two impact each other and the third. Without knowing the dynamics of cost, schedule, and technical performance, we can't have any credible understanding of these variables.
Three Body Problem
The three body problem determines the possible motions of three point masses m1, m2, and m3, which attract each other according to Newton's law of inverse squares. It started with the perturbative studies of Newton himself on the inequalities of the lunar motion. In the 1740s there was a search for solutions (or at least approximate solutions) of a system of ordinary differential equations by the works of Euler, Clairaut and d'Alembert (with an explanation by Clairaut of the motion of the lunar apogee).
Developed further by Lagrange, Laplace, and their followers, the mathematical theory entered a new era at the end of the 19th century with the works of Poincaré and since the 1950s with the development of computers. While the two-body problem is integrable and its solutions completely understood, solutions of the three-body problem (Java 7 in 64 bit Browser needed) may be of an arbitrary complexity and are very far from being completely understood.
The forces between the bodies can be self attractive or they can be a central force - the restrictive three body problem. Or a combination of the two. This is the basis of complex systems, where multiple forces are applied to objects, which in turn change the forces. As an aside, the double pendulum and the three body problem are used as examples of complex systems. Without acknowledging that the underlying mathematics is deterministic since the Java example above draws the lines from an algorithm.
This is a common mistake by those unable to do the math, or who want to suggest the problems of the day are beyond solution.
Three Body Problem and Three Elements of Project Management
The three body problem uses gravity as the force between the masses. There is a simpler example of three masses connected with three springs. This model is found in chemistry and biology, at the molecular level. Gravity is not in effect of course, but electromagnetic force.
Consider a simplified model for the vibrations of an ozone molecule consisting of three equal oxygen atoms. The atoms are represented by three equal point masses in equilibrium positions at the vertices of an equilateral triangle. They are connected by equal springs of constant k that lie along the arcs of the circle circumscribing the triangle. Mass points and springs are constrained to move on the circle, so that, e.g., the potential energy of a spring is determined by the arc length covered.
Now to Projects
If we assume for the moment that cost, schedule, and technical performance are dynamic variables, with forces between them described by their functional equations. In our functional equations for the force between them ar not constant, but are relationships like this:
The interaction between the three core elements (cost, schedule, technical) is a two way interaction, so the spring analogy is not quite correct, since the spring force doesn't know which end it is pushing or pulling.
It's not the Iron Triangle, it's a springy triangle. The connections are non-linear and most importantly they are probabilistically driven by the underlying statistical processes of the project. Let's start with the picture below.
All project processes are probabilistic. They have behaviours that are not fixed. The notion that you can slice work into same sized chunks and execute these chunks with the same effort would violate the basic aleatory uncertainties of all work processes. With an understanding of the statistical processes, driven by either aleatory or epsitemic uncertainties, is followed by asking probabilistic questions. What's the probability that we'll complete on or before a date or what's the probability we'll compete at or below a cost.
With a probability and statistics foundation, we can now put together a credible plan, driven by the underlying stochastic. All work is connected in dependent ways. The work effort, it's duration, and outcomes is also statistically driven. This picture is typical of such a project.
In The End
So we can:
In a conversation on Twitter with Sridhar, there was mention that product development software projects are different than internal IT projects. And that how they are run is much different as well. This may be the case. It's not been the case in my experience in Enterprise IT for those internal projects. My experience in product development (FileNet, Triconex, Kontron) and software intensive program delivery for government, defense, space, and energy clients is that projects are expected to show up on or before the planned date, at or below the planned cost and with the agreed set of minimal capabilities to accomplish the business goals or fulfill the needed mission.
When internal IT projects lose their ability to show up on time, on budget, with the needed capabilities - all within the probabilistically defined bounds of those measures - then they lose their seat at the table. Internal IT becomes a cost. Sometimes a sunk cost. An expense. A necessary expense, but an expense all the same. And when you're only an expense, those making decisions tend to treat you differently. You have no tangible way to show your worth. In business worth is defined by revenue or cost savings. In both cases worth is defined in units of money. When you have only cash outflow you're likely not to be in the conversation about how to run the business.
There are endless books, articles, and academic papers on the topic of getting a seat at the table. Successfully delivering internal IT in support of the business. Keeping your seat the table on that business requires very specific behaviours, starting with three simple questions:
But the bigger question - the killer question is what are we building and why are we building it? Ignoring for the moment the problem of showing up late and over budget dilutes any value produced by the project, some times to ZERO, we must have a notion of what DONE looks like in units of measure meaningful to the decision makers. Those paying the bills for the project.
Below is a briefing of how to answer these governance questions about what and why. With that in hand the how much, when, and working are straight forward.
There are many books on Balanced Scorecard. Some I find best are:
At The End of the Day
If you can't say, with some degree of confidence, how much you plan to spend, over what period of time, to deliver some tangible value to those paying for your work, you're not in the room when those paying for the work ae deciding what they want you to do. You're considered an expense - possibly a valuable expense.
There are Principles, Practices, and Processes of project success. I have a book coming that describes them. These are independent of any method, any domain, any favorite tool, buzz words, or personal paradigm. Much research on Root Causes of project failure have led to these Principles, Practices, and Processes. The Principles don't change, can't change. The Practices need to be tailored to the needs of the project and its paradigm. The Processes are localized.
But around these are 7 Activities of any project, that if not performed in some way, the probability of success is reduced, sometimes to Zero.
Domain and Context
No matter if your building bridges across rivers, a flying machine to Mars, the next anti-virus drug, or writing software using Scrum for your internal web site, these activities must take place in some way.
Without the last 4 activities, you're managing the project open loop. This might be OK if your customer doesn't care how much it will cost or how long it will take to finish the defined work. But of they do, you'll need a target cost and a target completion date, the feedback that you're making progress to those values. And of course some confidence that those targets are credible, their degree of variance, and how they are changing as the project progresses.
So one final comment
When we hear that we don't need to estimate, there is no way to have a closed loop control system. Without on estimate of the cost, schedule, and technical performance goals, the only management control system is open loop. This is unlikley to lead to success for any non-trivial project.
There are three key elements of every project on the planet - Cost, Schedule, and the performance of the product or service produced by the project. Each of these has drivers. The connections between Cost, Schedule, and Technical Performance are not Iron as suggested in the Iron Triangle of a PMI view of the project. Instead the connections are elastic, springy, flexible. But they are connected.
Cost is driven by:
These costs are themselves variable, as a function of the project phase, external forces for labor, materials, and overhead. But the cost variable starts with these.
Schedule is driven by:
Technical Performance is driven by:
So What Does All This Mean?
But for project success we need to have several things in place. The random behavior has to be knowable. It can't be chaos. If it is chaos, the project will fail, because there is no corrective action.
The three elements need to be known to some degree of confidence.
Do know these to some degree of confidence, you don't know what DONE looks. The only measure of progress becomes the passage of time and consumption of money. It's unlikely any customer is going to be willing to pay you - at least for very long - to spend their money, without some understand of Cost, Schedule, and the resulting Technical Outcomes.
Let's Start With End In Mind
If you work on projects and get paid for that work, someone is paying for you. That can be a direct customer if you're working on a external project. Or it can be the firms customers, buying a product or service which provides the money to pay you. No matter, someone pays for you to do what you do best.
Project Accounting is a subset of Finance Accounting, Both Are Important to the Project Manager
As a person working on a project, you may not care about Project Accounting or Finanical Accounting. But it's important to know where your pay check comes from, and it's not the Bank of America.
Project Accounting, sometimes called job cost accounting, creates data that tracks the financial performance of projects. Project Accounting enables the firm providing project resources (labor and material) to monitor the progress of their projects from a financial point of view. This is separate from standard organizational accounting for departments, divisions or the firm.
There are several data values used in project accounting. The project manager and the business manager(s) funding the project expect a certain level of profitability to be maintained in each function of the organization workiing on the project. The cost associated with delivering the project is Budgeted by the firm - usually before the customer of the project receives an invoice for the work and sends Funds in the form of real money. Budget is not dead presidents. Budget is an authorization to spend dead presidents, but you can't take your budget to Star Bucks and buy a Vente Latte.
For external projects the separation of internal costs - both direct and indirect - is many times done by finance. Usually the project costs are wrapped or grossed up for billing purposes to the customer. For internal projects, the fringe, labor overhead, material overhead, and G&A costs are not usually recorded directly to the project, but recorded in the Project Ledger as the wrap rate for your labor. Fringe, labor overhead, material overhead, G&A and other indirects are paid with actual funds - dead presidents - so those costs can be recorded outside the project, since they are not material to the project's performance if managed properly. We see all the time, when those indirect costs get out of hand the firm itself reduces its profit and they come looking for savings from your project.
An important concept of project cost accounting is the ability to provide visibility to targeted revenue against the actual revenue, and the estimated costs to produce that revenue against actual cost to produce that revenue. Many firms separate these two items - revenue and costs. The Project Manager focuses on the cost side - direct labor, materials, services, etc. And the Financial Accounting department focuses the revenue forecast and actuals. Since those direct labor, materials, and services - whether internal or external - have to be paid in real money, someone in Accounts Payable needs to know how much will be coming due in the next period.
This By The Way is the role of Estimating. How much labor will be needed to produce the planned outcomes of the project next quarter, next release, or the next anything? Fixed labor pool? Simply add up the FTE (Full Time Equivalents), multiply by the Fully Burdened labor rate and send that to accounting. But of course that means with a fixed labor pool, you'll need to know what your capacity for work is. Have a fixed commitment to deliver some value? Then you'll need to know how many FTE's that takes. Either way you'll need an estimate for those outside your project paying the bills.
What Does Project Accounting Do Best?
Project cost accounting records the costs associated with a particular project or job. Project accounting collects all cost - invoices, time cards, other direct project charges - and assures they are recorded in the proper charge account. These charges can be direct billed to the customer, or assigned to a Budget Item in the project cost baseline, or recorded as non-billable. When costs are non-billable, they are also considered non-recoverable and are usually captured in some overhead account. It's the cost of business.
It's a simple matter of balancing the books. Money In minus Money Out = Retained Earnings (money left over). It's of course more complex than this, but this will do for now.
This must balance...
All Income in the form of Accounts Receivable = All Outgo in the form of payments in "real money"
For project accounting to add value, care is needed to record and track every project cost. This by the way is one primary role of the Work Breakdown Structure. The WBS defines the budget and captures the cost of each project element. On the project side expenses are represented by direct labor (this is why time cards are used on many external contracts), invoices submitted properly for non-labor project costs.
One important issue in project accounting is who carries the overhead?
Project managers are usually not aware - at least directly - of the overhead, fringe, and other indirect costs to their projects. In some domains these costs are wrapped in a multiplier to the direct labor and recorded on the Project Balance sheet without any detail. This Wrap Rate value is important to the project manager, since this cost is subtracted from the revenue generated from the external customer. For internal projects, this wrapped cost is part of the ROI calculation for the cost of delivering the value from the project to the internal business customer.
In the end someone has to pay the electric bill, those free lunches for the project team, those Star Buck cards we hand out for hard work, and the spot award checks for other actions of the team. Those really nice 1080P monitors sitting on the engineers desks? Someone has to pay for those. The Aeron chairs? Someone has to pay. In the end someone has to pay.
Our daughter (now grown an gone) came home one day from her High School Economics class and announced, Dad we learned today there is no such thing as free. Yep, dear, welcome to the real world. People need to know what the real cost is. When they say free checking, someone is paying for that, probably you.
On projects, all that infrastructure you enjoy - laptops, lunchroom, parking, etc. is paid for by someone. If not directly, than indirectly. That's accounted for in the Financial Accounting System, the one the CFO is interested in. As a project manager you may or may not know about the wrap rate or even care about the wrap rate. But those who pay you do. And since they do, you may want to have some concern about the wrap rate as well. Fringe benefits, labor overhead, material overhead, G&A, etc. are real costs and impact that ellusive bottom line for your project and your firm.
So In the End
If you work on projects and are not concerned with the wrap rate either directly or indirectly (a pun for all us project planning and controls geeks), then you're probably direct labor. Wonderful direct labor, hired for your irreplaceable skills, but accounted for as labor all the same. Recorded on the books by your direct rate (annual or hourly), the fringe, overhead and other indirects.
So if you don't care for the Overhead discussion, or don't want to perform your role as a project manager using Overhead, just remember, those who pay you do care. And since they care, you may want to care, or at least pretend you care, you're job may depend on it.
The separation of Project Accounting from Financial Accounting is common in many firms. Finanical Acounting is the domain of the CFO or equivalent and the finance and accounting department, where payments of invoices to customers and from suppliers ae processed.
Project Accounting, sometimes called Job Cost Accounting, is usually the domain of the Project Manager. Where budgets are assigned and records of work peformed and cost of that work reported. But actual money doesn't change hands.
In the Financial Accounting domain, all costs and all income are recorded as transactions on the General Ledger. These transctions are rolled out through accounts to produce a Balance Sheet of the cost versus value in some form. Sometimes that value is revenue. Sometimes, it's business value recorded as intangible asset. Managing of the intangible assets of a firm is the primary role of business leaders. Teh tangible assets are usualy managed in the accounting, by the depaertment with the same name.
I'm making this simple, and likely simple minded for the point that is coming. Who owns the overhead costs that are present in every single business? For larger complex projects here's one framework for doing that, but we'll keep it simple for now.
But before going simple here's a quick looks at FASB 86, the guidance for accouting for the development and use of software. But one quick notion that is missed by many in the agile world not working the arcane processes of public accounting ...
The Agile Alliance is working this issue.
So Back To Project Accounting Processes
Projects spend budget. Businesses spend Funds. If you work on a project, rarely does someone on the business side come to you with an envelope full of money - dead presidents - and say go hire some developers to write code for this project. Those authorizing you to hire people, or buy materials, do so with a Purchase Order of some sort (we have PCARDS that skip all the paper work), or some authorization from HR to hire. The employee or contractor then charges to a charge number or Employee Number to capture their expenses (labor or material).
That expense is then wrapped with fringe, overhead, and other indirects and recorded on the books as the Fully Burdened cost to the project.
Someone Has to Pay
No matter where you work in the organization, the all in cost for the project has to be paid. This includes your direct labor. What you get in your pay check, those fringe benefits - health insurance, matching 401(k), AMC movie passes, spot awards. Your firm has to pay. If you're a 1099 supplier, then it's you that has to pay. As a 1099, if you're not billing your customer for all that overhead than those costs are reducing your revenue. Same for a firm.
So if you're not concerned about overhead, don't manage the project knowing the overhead. Not a problem in principle. In practice though someone does, and if they care, you may want to care as well. If not, then you're likley working as labor on the project. That's in NO way a problem. We're all labor in some form to some one. But when it comes to managing projects and managing the business that projects use or produce, these indirect costs can make or break the project and or the business. Knowing about them, managing in their presence is simply the responsible thing to do. You know likey knowing what your project will cost when it's done.
Here's some background that have served me well over time as a Program Planning and Control manager.
Todd Little and Steve McConnell use a charting method that collects data from projects and then plots it in the following way. For Little's data its the initial estimated duration versus the actual duration.
and for McConnell's data it's the estimated completon date versus the actual completion date.
So Where's the Rub?
These charts show that project estimates exceed some ideal estimate on a number of projects - the sampled projects. If we were sitting in the statistics class in an engineering, physics, chemistry, biology course, here's some questions that need answers.
What's missing are several things.
The Core Issue with Using Past Numbers
What To Do Next?
The first thing to do is go out to the book store and get a book on statistical forecasting or statistical estimating that has actual math in the book. Next is to ask some hard questions?
Then read all you can find on reference class forecasting and statistical inference. Data is not information. Cause is not correlation.
There's really no way out of this. Spending other peoples money, at least money they are no willing lose, means having some process of estimating the probability of success.
The Final Thought
Plot cost and schedule for your projects asa Joint Probability. Below is a Monte Carlo Simulation of the Joint Cost and Schedule for a program. A similar chart is needed but using a collection of projects. Take Little's and McConnell's sample projects and plot both cost and schedule. There may be correlations between original cost and actual cost, versus original schedule and actual schedule. Big projects have higher risk - restating the obvious by the way. Higher risk project may have wider variances in performance - also restating the obvious.
But these one dimension - one independent variable - plots of cost overrun versus original cost estimates just show the uncalibrated, un-normalized, non-root-cause data. It's just a chart. Of little value for taking corrective action.