Skip to main content

The "True Cost" Phantom in Project Cost Tracking

I want to know if I should wear a coat when I go out the door on an unpredictable spring morning. The temperature from the weather app on my phone isn't going to match exactly the temperature just outside my front door, but it will be close enough to make the decision. If the question at hand is whether or not I should wear a coat, it would be a costly mistake to set up an elaborate system of thermometers around my property to try increase the precision of my measurement of the temperature. The added expense wouldn't yield any better decisions about whether to wear a coat, so why bother?

We are interested in tracking the relative costs of the various projects we undertake in our organization. We must admit up front that we will never be able to measure the precise cost of each of our projects. Consider the following things you could include in the "true cost" measurement of a project. Where will you draw the line?

  • An engineer reads an article on the bus that gives her a great idea for the project. Bill the time of the bus ride to the project?
  • A secretary (not formally part of the project) orders pizza for a project team for a lunch meeting. Is her time free for the project or should she bill it?
  • A developer stays late to patch a critical error in a system and misses the beginning of a child's soccer game. Is missed family time--and the potential decrease in employee satisfaction--a cost of the project?
  • A developer runs some code that inadvertently maxes out the processor on a server in the data center for a few hours. Do we count the cost of the increased electricity and cooling costs in the data center?
The "true cost" of a project is a pointless fiction since "true cost" is a phantom we can't possible hope to perfectly quantify. It will always have a subjective element to it.

Measuring the cost of a project is a backward-looking metric. We only care about the cost insofar as it helps us make future decisions. When we are trying to give the university administration information about whether to add a new module to PeopleSoft, will it matter whether the cost of implementing the SharePoint upgrade last year was $30,000 or $50,000? Of course not. No project is exactly like the last one. Even if we could measure precisely the last project (which we can't) it wouldn't help us know exactly the cost of future projects. 

We don't pay the football coach based on the number of hours he spends drilling the team. We pay him based on the winning record he can produce. We don't really care about the inputs. We care about outputs. 

Does the the trustees of the university care about how many hours it takes us to complete a project? I doubt it. They won't think we're being dishonest with them if we can't provide a precise tally of hours we spent on a project. They care about the value we are producing for BYU and the value that BYU can in turn produce for the world.

Let's step from from our goal to track the "true cost" of a project. And let's go even further. Let's stop tracking our inputs and instead experiment with ways we can track our outputs. 


Popular posts from this blog

Deceptive Per Captia Rankings for Brain Cancer

We're working on a project to produce a report on the ratings that students give to their professors at the end of the semester. There is a big concern by the math people on the committee that we will give some professors an unfair bad (or good) rap because of the variability in these rankings. They don't want to report the ratings as a mean (average). Instead, they want to plot an uncertainty range. 
I was reading a book this week (How Not to Be Wrong by Jordan Ellenberg) that provided a great example of the risk of ranking things when there is uncertainty. It can lead to erroneous conclusions. Here is a summary of his argument that appeared in an NPR interview. Perhaps this sort of example will be helpful for the committee to share when teaching the general faculty about the new instrument.
If you take a rare disease like brain cancer and you look at its rate of incidents in different states, there are very big differences. And so you might say, "Well, I should go wher…

Beyond Scrum?

[Adapted from a post to our internal Slack team.]

My manager has been working to get an agile consultancy into our university's central IT department to help us progress in our journey toward being more agile. I hope that the training and coaching we receive will focus more on the root principles of value in agile processes rather than on a single process like Scrum.

Are there any root agile principles that you think we need to be better at embracing? Here are some that come to mind for me.
Develop functionality vertically instead of horizontally. You don't create the database layer all the way, and then the web services layer all the way, and finally--after 9 months--start to create the web user interface. Instead, you find a way to introduce a complete feature that touches all those technology layers so that you can get real feedback about the usage and value of the system or feature.Be willing to throw things away. If we're going to experiment, we have to be okay buildin…

Strategy: Efficient or Innovative

We haven't had a refresh on our strategy direction in my office for a few years. It seems like we are frequently torn between being efficient and being innovative.


Lower costspeed to productionminimal failuresmaximum uptime Innovative Higher costlots of failuresfreedom to pursue non-"approved" activitiesshorter attention span I'm part of an IT shop with nearly 200 services that we offer to campus and internally. I love the feeling of being innovative, but I'm concerned that our current push is to be innovative at the expense of being efficient. The result is that we can't accomplish as much near-term good for the campus because our focus is on the longer term.