.png)
If you have been following Bob on his journey to find an enterprise solution for his company’s trading and risk management needs, you will find below the next step in Bob’s adventure. It is perhaps his most challenging step yet in his very challenging world. If you have not read about Bob’s adventures, please follow this link to find out how he got to this point.
In many companies, and even militaries, decisions and planning are made at higher organizational levels. Decisions then translate into actions, which are expected to be taken at lower organizational levels. A less known, dirty little secret is how decisions are made. Decisions cannot be made in a vacuum. Decisions are supposed to be made based on information. Preferably, good information.
Where does information come from? A common misunderstanding is that data and information are the same thing. Definitionally, data, or facts, come in a very raw form. Data must be refined before it can be called information. Raw data, such as the temperature by location over a period of one year, has no real value in and of itself. Once data is refined into a useful form, though, as in the shape of curves showing temperature by location over time, it can then be consumed in the form of information.
So, then, the question becomes where data comes from. Normally, data is gathered off the ground at the lowest organizational levels. Data is supposed to be observable fact. And the best place to make observation is usually somewhere near the ground. Perhaps, this is the reason for the expression “decisions grounded in fact”. Then, as data is shared with higher echelons, it is presumably processed and filtered into something a bit more actionable until it eventually percolates to a level having enough organizational authority to act.
Data is little more than facts. What data “tells” or informs is heavily dependent on processing and filtering, which can be heavily influenced by personal perspective and experience.
For this reason, one raw dataset, after refinement, may lead to many completely different conclusions and action plans. This is the dirty little secret often overlooked in companies, or any organization, for that matter. Information is assumed to be facts. But it isn’t.
Bob knew something about decision-making processes from his undergraduate organizational theory business classes at university. At that time, Bob had no practical context then for what his professor was attempting to teach. He did now, after many years in the school of “hard knocks.” Bob wasn’t exactly at ground level in his organization. Nor was he anywhere near its top. Somewhere lost in the middle may be the best way to characterize his situation. That made Bob an influencer in decision-making. How he passed along the data he gathered and processed, and in what form, would have some impact on what decision was made by those above him organizationally.
Bob was determined to avoid the pitfalls of percolating bias up the chain of command. Bob wanted to communicate facts, however difficult that may be. But his management didn’t want the raw data. It wanted actionable intelligence. It wanted proposals. It wanted options and alternatives. It wanted to know which option was the “best”. Obviously, the one most grounded in fact, thought Bob to himself. It’s hard to argue against fact. No sense in getting too far out on that proverbial limb without facts to provide a safety net. Best place is to be ground in fact. If I simply present the “facts”, a decision should present itself naturally, right? Bob may still be a bit naïve about corporate politics. But he had good intentions, and a certain knack for self-preservation.
Bob now had many facts and factors to communicate to his superiors. He had explored all the imaginable options. He had interviewed all the stakeholders. Intertwined with all his facts was a great deal of opinion and preference. How to communicate all this stuff in a form his superiors wanted, troubled his thoughts. He wasn’t exactly the analyst type. And he wasn’t exactly an expert in his company’s business either. He couldn’t even be sure he had collected enough facts and figures, which could be refined into an actionable form.
However, Bob did his best to sort his data into separate lists. It is the scientific way of doing things, he mused. A big part of science is to categorize data into tree-like structures, right? Grouping things having similar attributes? So, Bob created a list for vendors and vendor information. Another list contained all high-level user requirements sorted by business area. In yet another list, Bob managed all the deployment options. He compiled all his findings in the form of a document he would share with his manager. Last of all, Bob maintained a list of consulting companies he could call to provide help, if needed.
One thing Bob did not know was the druthers of his management. How much budget could the company afford to allocate? How quickly did they want a new system deployed? Could the company tolerate some upheaval of business processes during system deployment? Who would lead the deployment project? Would the project leader be given enough company resources to have a chance at success? How should a project of this sort be structured? Bob wanted to give his management some notion about how a project of this sort should be organized. It would have to wait, though.
Such were Bob’s thoughts as he entered his boss’s office to discuss the matter. What have you got for me today, Bob? His boss began. Well, I’ve completed my interviews with stakeholders and explored all possible options, Bob replied. Here is a rough draft of my findings. Bob handed his boss, Sean, a 5-page brief on the topic. Sean leafed slowly through each page, digesting its contents with some interest.
So, Sean concluded, after completing his review of the draft brief, you think we should look for a vendor system to address our company’s needs. Why can’t we build something in-house? We have developers, don’t we? Bob knew this question might be asked. Bob didn’t want to portray himself, or his boss’s staff, as incompetent in software development. Some degree of diplomacy would be needed here.
Well, you see, sir, as you already know, this sort of system is considered an enterprise-level system, having tentacles reaching into many aspects of our company’s business processes. Building a system of this far-reaching magnitude would require a great deal of time. And managing project risks over the project lifecycle would be very challenging. The political risks would be quite significant. Bob knew that mentioning political risks would get his boss’s immediate attention. Bob continued, and we can’t be sure that the requirements won’t have changed by the time we eventually deliver a software application.
His boss nodded acknowledging the truth of Bob’s response. You have here, Sean said, putting a finger on a data table showing list prices for several vendor systems, a rough idea of what license costs would be. Any idea about implementation costs? Bob pointed to another data table lower down in the report. These numbers here, he said, are just estimates based on what vendors are willing to tell me about their other clients of similar size. Bob added, no vendor would get too specific without a better idea of our company’s implementation requirements. We really won’t be able to estimate that cost until we have a chance to let a vendor do some due diligence.
And there is another reoccurring cost, Bob continued, related to hardware and software required to run the applications. Do we deploy an application in-house? Or do we outsource? The cost for each option is estimated on the last page of the brief. I suppose the big financial difference is capital budget expenditure versus operating budget expenditure. And I suppose our user community will have a perspective on the matter, too. They all want remote access anytime anywhere from any device. Phones, tablets, laptops, you name it. It’s the new normal.
So, which vendor application appears to be most promising? Sean asked. Bob looked down at his shoes. His foot shuffled back and forth on the ball like he was squishing a bug. Bob really didn’t know. How could he? He hadn’t seen any of the products yet. And, even if he had, how would he know which would work better for the users? All the vendors expressed confidence that they could do everything Bob’s company needed. And Bob understood only a fraction of his company’s business processes well. A very difficult question to be asked directly. But honesty is supposed to be the best policy, right?
Bob looked up at Sean after a moment and said, I really can’t say. I suggest we get our business experts’ opinion on the matter first. The best thing to do, I think, is to have a competitive bake-off: Meet with each vendor privately and let them show us what they’ve got. Bob could see his boss liked the idea of a competition. But before we can do that, Bob said, seeing some approval in his boss’s body language, we will need to explain our needs to each vendor that we invite to demonstrate a product. And, Bob paused for a brief dramatic moment, before we can do that, we need some formal way to communicate our needs.
Bob pulled a bunch of loose-leaf papers from a file folder sitting on his lap. These, Bob explained, are notes I took from all my interviews with our user community. The notes aren’t very well organized yet. But we have them. Can I suggest that we bring in someone from outside our company who has some experience with this sort of thing? If we invite vendors to demo products, we should have something in a better format to give them so that their demos will be as focused on our company’s needs as possible. I would like to have someone dress up my notes in a format that vendors can use.
Do you have someone in mind, Bob? Sean asked. Several options, Bob responded. He knew his boss like options. What’s the point of having authority to make decisions if there aren’t any options to choose? First, we can see if our company’s financial and systems auditors have anyone experienced in this sort of thing. We already have a business relationship with the auditors. So, I think we can expect some degree of unbiased opinion from them. And I assume that they will want to do their best by us. You know what I mean.
Second, there are many big-name consultancies who could help. They can be a little pricy. I’ve heard that they have a large bench of consultants who implement this sort of system all the time. So, they probably know their “stuff”. And we will probably need some help and guidance implementing whichever system we eventually choose. I assume that they work on the top-tier vendor brands mostly. So, I do have a concern that we may not see the products of the less-well-known vendors because their bench of consultants may not have an experience with those products. Something we should consider in your decision.
And, last of all, I do know of less-well-known boutique consultancies that do this sort of thing all the time. They can help us to pare down the list of vendors to invite. I’ve been told they even have sample formats and pre-built questionnaires. We just need to review and refine them. There is a cost, of course, for this sort of assistance. Standard hourly rates for one or two FTEs (Full-time Equivalents) for a couple of months. I have a list of several I can call. I can give you a list of their standard rates and estimated all-in cost.
Sean nodded his head to indicate he had heard and understood what Bob had suggested. He raised his index finger and said, I’ll have to get some approval for budget to cover an engagement of consultants. Let me run this up the flagpole and get back to you soon. Bob collected his notes, stood up, and left the office.
As Bob headed back to his office, he considered how the next few months would develop. A formal RFI (Request for Information) would be developed, …, with some outside help, Bob hoped. The RFI would be sent to a list of potential vendors. Responses to the RFIs would be thoroughly examined, again with help from the outside. Three or four vendors would be selected to demonstrate their products in front of all the stakeholders of this decision. Each stakeholder would be provided a scoring sheet, which would later be tallied and summarized.
Then, RFPs (Request for Proposals) would be sent out to just two, possibly three, of the vendors selected to demonstrate their product. They would be given time to draft a proposal with final cost estimates and project plans. One of the vendors would be selected as the frontrunner, and another would be selected as a runner-up, in case negotiations with the frontrunner did not pan out well.
Then the final step. Getting approval from the board of directors to move forward with the project. Bob could see that this whole process would take much more time than he had first expected. A lot of effort would go into creating both the RFI and RFP documents. Perhaps a whole week of time would be consumed sitting in day-long product demonstrations. Then, at the very end of the process, a proposal would be drafted for the board of directors. Bob knew he would need help with that proposal.
Bob sat down in his office chair and thought about that one. Who could he ask for help? Who knew how to draft a proposal in a format the board was used to seeing? Certainly, the board must see this sort of thing all the time, didn’t they? I mean, that’s what boards do, right? Approve projects and such? Who did that? A memory surfaced in Bob’s mind: The Finance department. Bob made a note to visit someone over there soon.
In our next installment, Bob presents his case to the board of directors.
ABOUT ENTRADE FOR ETRM / CTRM
COMMODITIES COVERED
SERVICES AND SUPPORT