Playing with Time to Save Money: Reactive vs Predictive Decision Making
For only $5,000 buy our “Make Life Easy Tool Kit” and we will give you a bonus Software Developer!*
*Mean annual salary for Software Developer valued at $99,453
The following is an attempt to understand why it can be so difficult, despite the prospect of great financial savings, to get a tool on a project in a reasonable amount of time. I would argue that it comes down to the tendency to be overly reliant on predictive processes when we could sometimes benefit from reactive decision making.
Every established company has a set of generally well-developed rules and regulations on spending money. These policies may be pragmatic, such as service contracts, spending limits, employee policies, contractor policies, double signatures and whatever else the top brass or the attorneys deem necessary.
These policies are of course good predictive management practices. Policies created with the logical intention to save money, but do they always really achieve this goal? Certainly negotiating a service contract with Xerox or predicting common employee pitfalls makes sense, but how do we measure other seemingly intangible metrics, such as spending policies on third-party tools and associated project budgets?
The Mini Bar
Let’s start with a little anecdote about minibars: those sometimes enticing, but more often than not, annoying little not-a-real-fridge boxes found in business traveler hotel rooms. Some hotels have been kind enough to phase them out, but apparently, they still create expensive headaches in the corporate world.
I was one of two technical representatives sitting in on contract negations for a new product for which the total cost over the first two years was expected to be less than $5,000 USD. Negotiations quickly digressed into the creation of a clause related to the mini-bar for any possible future consultancy services. On this conference call were ten staff from two separate billion-dollar companies, including two technical resources (yours truly plus one); four attorneys; and several management and sales staff.
The topic ate-up a good hour of time during our call. If we were to estimate a generous minimum of $100/hr per person billable time, plus the time required for preparation and follow-up, this little clause most likely never paid for itself, while costing at least one-fifth the price of the actual product. Like me, you are probably left wondering why one of the trusted sales managers or one of the contract attorneys on the call didn’t simply pop in the phrase “no mini bar charges” and leave it at that? Boom. We’re done.
Why did this happen the way it did?? Because for whatever reason, the policies in place at one or both of the companies were not created to consider actual processes. And or the individuals involved were not given appropriate authority to make situation-specific, time and money saving, decisions. Inefficiencies like this exist, because companies don’t have a metric to measure the cost of implementing their policies. They don’t trust their employees to make good decisions. Nor do they have a way to measure if this really saves money in the long-term.
This may seem like an idiosyncratic example, but if you pause to think about it, you will be surprised by how many similar experiences that you start to recall. Why is it that accepting or declining an expense so complicated? Perhaps you are in the middle of something similar at the moment. Unfortunately for project managers, when it comes to decision making and buying third party software — software created specifically to time, money and labor — the utility of the software is too often overshadowed by the hurdles management must jump simply to get an expense approved. Predictive management too often assumes that employees will make bad financial decisions. How many of us have been subject to (or responsible for!) long meandering meetings and delayed projects that have been derailed by the decision to recreate an inexpensive third-party product, simply because the effort and the cost of trying to buy the product is a known metric, whereas the time/money/labor spent in recreating it is unknown?
Where is the logic?
The reason that managers and their teams fall into time sucks is indeed the lack of access to reasonable metrics. Rarely have we defined ways to measure non-monetary resources, which means that we can’t place a precise value on the time and resources spent. We don’t have a metric to show that paying a developer $99,453 a year to recreate a $5,000 product is just plain foolish. We do have rules that make it difficult for managers to approve purchasing third party products. The consequences is that project managers take the semi-rational approach of not buying off the shelf products and instead spend more time and money to recreate the wheel.
Trying to add measurements to this process so that the costs are tied to time is likely to be extremely laborious and requires relatively large changes in standard business models. As a result, this approach will not functionally solve the problem, given that time is money. Unfortunately, despite the desire to increase profit margin we still consistently lack the processes and the authority (ability?) to designate metrics or assign a value to “negotiating contracts” outside of the knowledge that skipping out on contracts can be very costly.
So how can we minimize the costs of decision making? Although there are many many processes to speed up decisions, there is one that is not often mentioned or even considered to be plausible: the act of making decisions in hindsight. Hindsight you say? This seems impossible. Or at the least unwise.
Hindsight is 20/20
Let me explain. Most purchasing decisions follow a predictive process. Predictions are often inaccurate and increasing accuracy requires a lot of analysis. The hindsight scenario is a reactive process, where information is cheap and easy to acquire, but unfortunately, the data arrives too late to prevent any negative outcomes.
For some decisions, the predictive process is worth the expense and the time spent on data analysis. Big capital expenses, such as data centers or other high-risk expenses, such as people generally require predictive decision-making processes. However, less expensive and less risky processes, such as the purchase of 3 licenses for a $100 piece of software are significantly less risky and thus merit a reactive approach. Clearly, institutionalizing a reactive approach needs to have set limits, but these can be set and managed fairly easily.
Empowered and Efficient
A simplistic model of a reactive approach might be to offer project managers or development leads a set budget per developer, per year to improve efficiency. Teams or individuals who can show their expenses to be positive investments can then earn augmentations to their original allotted budget. In effect, a developer or a group of developers can then use their experience and expertise to decide to buy a license on an afternoon and without jumping through 3 weeks of approval hoops. If after implementing the licenses they can show the results were worth the investment, they can request their allotment be reimbursed.
Let’s say we have a development team with a budget of $1000 per year to invest in project efficiencies. After purchasing a piece of third party software to solve a development inefficiency they report back:
“On January 5th we spent $580 to buy Product ABC. This product has been implemented to solve task Y and thus reduced developer workload by 40 hours per week. We estimate this has saved us $12,000 in staff hours. Please augment/reimburse our initial budget of $1000 by $580 to account for this worthwhile investment in efficiency.”
Or, perhaps the software turned out to take too much time to implement and thus negated any benefit, so the developers are not eligible to ask for a reimbursement. There is little risk involved and getting an accurate decision is still relatively cheap. People who make good decisions are rewarded with augmented budgets, people who make bad decisions run out of money.
In the long run, streamlining the decision process for acquiring third-party tools will make the effective tools more accessible and attractive. And, I predict that overall efficiency will be increased as people will spend less time re-inventing the wheel.
How have you solved the problem of budgeting, expenses and third-party product acquisition? Do you use reactive decision making? What other successful ways do you manage your budget and achieve increases in management efficiencies?