Why is it that the customer in corporate software projects seems to want to pack the scope of every project with capabilities of dubious value, in the same way that our congressional leaders try to pack important bills with “pork”? Why do organizational leaders try to take a well funded project or initiative and use it as a means of funding their personal management agenda? Because like congress, if they can construe their agenda as essential to the completion of some important project – they bring the business value (pork) home to their department. They can use the project as a vehicle to accomplish things that ensure that they get their bonus. These leaders act as though their incentives are more important than the overall health of the corporation – just like congressmen act as if their re-election is more important than the overall health of the nation.
How did this topic come up?
I have been talking to application development managers and software project managers in corporate IT over the last week, and have heard the same story over and over:
And so I ask why? What happened? The answer I hear over and over is that the customer, fearing that once the project were “complete” they would not get any additional funding approved, tried to cram every capability into the product possible. The problem stems from:
How you view projects and software products matters:
The reason that the customer does this is their worldview, related to software projects. This is really a management failure. We need to have a conversation with management (both IT delivery, and customer) around the fact that building software is investing in an ASSET. You buy or build the asset to add value to something. Many organizations have gotten stuck in the mindset that building software is a PROJECT. When you see software as a project, you manage your project portfolio, projects get DONE. When you see your software as an asset, you manage your asset portfolio, assets are HELD.
We all need to see that projects are the investment transactions that alter the value of our assets. Transactions get DONE. When software project transactions are done, value transforms from liquid (money) form to illiquid (software product) form.
An analogy of different project transactions:
Often people will say that the goal of a project is to get done, on schedule, on budget. But this really focuses on the transaction processing aspect. Like I want to build a warehouse for this amount of money, on this date – what is missing? Why am I buying the warehouse? Is it to store my inventory, to rent space in, what? What is the goal of the transaction? Why did I convert liquid money into real estate? Software projects are no different. Like a warehouse that I build or buy to store my inventory, software projects only add value, when they are occupied – or when the capabilities are used. I may build a warehouse that I only use for the 3 months leading up to Christmas, the goal of building it may be to increase my inventory capacity, so that I can capture more holiday sales. If I spend a million dollars to capture five million dollars in additional profit from holiday sales, the value of the warehouse is what? FIVE MILLION DOLLARS. That was the goal – that is why I built it. Could I have rented a warehouse? Perhaps. Are there other possibilities to capture that extra holiday sales? Perhaps. This project. This goal. This outcome. FIVE MILLION DOLLARS in addiotional profit. Did the transaction need to take place before I needed the warehouse? Yes. Did the cost need to be as budgeted? Yes. Those are constraints, not goals. Got it? If I had built a warehouse for a million dollars on schedule, but the warehouse only housed 33% of the space? Would I have met the goal? No. When we remove or change software capabilities so that they add value differently, have we met the goal? Probably not.
Impact of behavior derived from a simplified worldview:
By packing a software product with capabilities that are not clearly, directly, essentially linked to the goals (not constraints) of the project, we are increasing the probability of failing on cost and schedule constraints – or that require us to make tough choices later, to remove capabilities that haven’t been built or completed, we increase the risk of spending time or money on capabiltiies that are not delivered. We also increase the risk of not delivering capabilities that are directly linked to the goals – thereby reducing the potential value that can be realized from the investment.
How to reduce the impact:
The agile product backlog is one simple way to reduce this impact. If we can collect all of the “required” capabilities in a list, and rank them according to their essential relevance to acheiving the goal, and sequence the delivery of those capabilities according to that rank – then we can agree to not deliver capabilities that are more essential before those that are less essential. Any way of making sure that I spend money and time to acheive the stated goal, before I spend on peripheral issues reduces that risk of those less essential capabilities inhibiting our ability to acheive the goal.
How to prevent the behavior in the first place:
This project porking behavior is caused by incentives that are not aligned with organizational goals. If we want to change this, we should:
- reward middle managers for supporting organizational goals when their departments need to sacrifice to acheive them.
- ensure that important projects are initiated in a way such that goals are clearly spelled out, and each project “requirement” is tagged back to one of the goals, and prioritized according to its relationship to achievement of that goal.
No Comments