I recently had a conversation with a colleague about the importance and differences of repeatability and flexibility within a SHOULD COST software solution. I’d like to provide my position and get feedback from the readers as to their thoughts.
Before we get too deep into the discussion, we need to define a few terms. The first term is SHOUL D COST. A SHOULD COST is a benchmark cost. It is sometimes defined as obtainable with effort, or ideal or cherry picking the best of the best. The intent is to challenge a supplier to improve their process, but more importantly, it is designed to drive a discussion with a supplier where they justify their pricing. It is to think you could guess or research every cost any particular supplier could be using in the business decisions. One quick example that comes to mind is something as simple as interest payments on the capital. All solutions include a calculation for this expense. They take the initial capital cost and apply an interest rate associated with that region. I haven’t seen many, if any, that ask how much down payment was applied or the length of the loan. It is usually assumed to be 100% of the cost and for the life of the equipment. Just imagine if the supplier actually put down 20% of the cost, then your interest calculation is now 20% wrong. That’s just one easy example.
The second definition is repeatability. For this discussion, repeatability not only refers to the ability of an individual to get the same answer regardless of how many times they run the model, but also the ability for various Cost Engineers to get the same answer for the same product referring to the same documentation, i.e., prints and specs. Within any organization, the goal should be that any Cost Engineer should be able to pick up a SHOULD COST MODEL completed by a co-worker and agree with the inputs and results. In other words, 1+1 always equals 2, not 1+1 = 4 because a different engineer ran the estimate. The second engineer decided to use 1.9 + 1.9 using their logic and experience, bringing the calculation closer to 4. Yes, both are correct, but if you are starting a negotiation would it be better to start at the 2 or the 4 and have the supplier explain the 1 is actually 1.9? This may not be the best example, but I hope you see the point. Why is this important? Over time, the estimating engineer may change. When a different engineer takes over and reviews the model and determines it could have been done differently and therefore changes the results, it casts doubt on the accuracy of this, and every model ever created. This doubt will undermine the entire groups’ credibility both within the enterprise and with external partners.
The last definition would be flexibility. In this case, flexibility is defined as the ability to change standard benchmark assumptions with little to no defined OBJECTIVE or SCIENTIFICALLY supported tracible logic. If there is defined logic, then we could assume one to ascertain the correct inputs from the documentation, prints and specs. If it’s not clearly defined, it becomes subjective and at the discretion (whim) of the estimator. In various solutions I’ve seen “sliders” or “knobs” where the estimator can “tweak” the results. In others, I’ve seen ambiguous questions like “Part is easy, average or difficult to produce” or “surface is smooth or rough?”. The result of these tweaks is a multiplication factor usually applied to the cycle time, thereby increasing the price.
I contend that these modifications should be conducted under the premise of sensitivity analysis. The cost engineer can and should run various scenarios changing the inputs to gage the impact on the end results. By no means should the baseline be altered solely at the discretion of an individual. The engineer should adjust the input at various levels to ascertain the actual impact they contribute. For example, add and subtract 10, 20 and 50% to the cycle time. This will not contribute 10, 20 or 50% to the price. Independently add and subtract 10, 20 and 50 % to the labor cost or time. This will not contribute 10, 20 or 50% to the price. Continue this process with all major cast categories. The concept is to be prepared for the negotiations with the supplier. If the supplier demonstrates a different input than you used, which will be the case, you should understand the impact it could contribute before you start the discussions.
Along with this definition of flexibility, I would also contend that the inputs should be limited to only those that SIGNIFICANTLY impact the actual estimate and/or are within the tolerance of “accuracy” of the model. For example, I’ve seen solutions ask for inputs that could add less than a second to a process that has a cycle time of 30 seconds to a minute. I agree that enough of these inputs may sway the total but when running a true should cost for a potential supplier we often do not know the correct answers. It is not unrealistic to think that if you pick these inputs incorrectly you could easily create a very inaccurate model. In most cases, it is best to err on the LOW side of an estimate and have the supplier explain why it takes a bit longer to produce a given part.
The question I pose to the readers is, given the above definitions, do you prefer a solution that has repeatability or flexibility? Is it more important to you to have the same answer regardless of who conducted the estimate or to give each estimator the ability to tweak each model to their own liking?
Please provide your feedback and comments on the webpage.
Thanks
Gerald Collins
Owner and CEO
Center for Strategic Cost Management