Southbound
I agree in general terms with what you say, but would say that the processes you describe exist. The problem, as seen by those who actually commit the money, is that the decision making process is not transparent. So, if a decision is technologically impossible (the old BOWMAN chestnut of high quality real-time video via an ancient VHF radio is a good one) or unaffordable (I want 20 systems at £1M each, here’s £3M), then it’s difficult to regress. The Gods have pronounced, so get on with it.
I may be an old dinosaur (it’s official, it’s in an annual report) but the old Long Term Costings system worked for me. First Order Assumptions (We need an Army of this size, to do this………). Second Order Assumptions (In effect, the reply; that being so, you need xx tanks, aircraft, ships, and they need to be placed here, there…. And be able to do this….. And be maintained thus….). Third Order Assumptions (The aircraft must have the following kit, spares, test equipment, trained staff, facilities, pubs ….. and it all must be maintained through-life). And this is how much it’ll cost………..
And then the “basket weaving” started………… Basket 1 – Critical requirement, not tradeable at any cost. Basket 2 – We’ll take the hit if you insist, but here’s the unpalatable impact. Sign if you dare. Basket 3 – We think we need it, but we’ll take the hit. In other words, a strict prioritisation process with an opportunity to state your case. In practice (in my day) anything in Basket 3 was at risk. To set this in the current context, these days Basket 1 is constantly at risk.
The golden rule was – if there’s not a Second, there can be no Third. If the Third is not endorsed and approved, resubmit the Second and take the hit. Or go back to the top and have the First amended. That concentrated the mind of what is now DEC. The system was completely transparent to all involved. Responsibilities and authority was well defined. For example, the Thirds could only be amended by an Engineer, who was permitted to do so using engineering judgement; but he had to explain himself and demonstrate the change was cost neutral. If he needed more money, he had the authority to juggle within his remit (say, avionic systems across the RAF). If this didn’t work, he prepared a Business Case (Submission).
If you ask nowadays who is meant to do this, the Requirements Managers have the nearest Terms of Reference. None have the slightest scoobie what I’m talking about; and few are engineers, so are automatically restricted in their role anyway. The reason I know how to do it is because it used to be a junior CS task (broadly equivalent to an SO3), and a stepping stone to promotion into project management. It follows that, if you’ve done this and understand it, you avoid most of the common pitfalls that one encounters in procurement. As ever, I can only speak from experience.
Sorry, long post, but the perfectly good, and still extant (only because they’ve never been cancelled) permanent LTC (EP) instructions explain all this. Best job I’ve ever had. This may seem strange to most here, but to have good teachers, and to understand and have control over what you do, and see the end result is a fine thing.