.png)
What Makes a Great E/CTRM? Part 11 – Bob’s Big Moment
If you have not been following Bob on his software selection adventure, please click this link to read his story prior to this point.
What would it be like to enter in the office of the President of the United States or shake hands with a very powerful world figure? How about meeting a respected religious figure, such as the Pope of the Roman Orthodox Church, the Catholic church? Meeting a legendary athletic figure or one’s own personal hero would be life changing, too. And crossing paths with very wealthy entrepreneurs would be very memorable. Wonderful memories like these last a lifetime.
And so do the other kind of memories. None of the above experiences resembled in any way Bob’s feelings as he entered his company’s largest conference room, the board room, for a meeting of the board of directors. His mouth was dry. He could not swallow. His hands trembled a bit as he shook hands with various directors. And Bob’s voice almost squeaked several times. On top of that, there was a general sense of discomfort somewhere in Bob’s lower GI (gastro-intestinal) tract. No, this experience would not be anything like catching a foul ball at a baseball game. He could not wait to see the other side of this meeting.
At the top of the agenda for this quarter’s Board of Directors meeting was the approval of his company’s budget allocation for funds to spend on a new C/ETRM application system. And Bob sat center stage in the limelight to answer questions from some very serious-looking people. They naturally wanted to know why they should approve the largest capital budget expenditure his company had ever funded. Bob imagined what the eyes of lions looked like from a gazelle’s point of view. Not much imagination was needed as his eyes met others surrounding the boardroom table.
Bob had been preparing for this moment for many weeks, even several months. He had
interviewed dozens of people throughout his company’s organization. He even sought advice and counsel from acquaintances outside his company. Bob knew this day would soon come. So, he wanted to be very prepared, even overly prepared. He wanted to give good answers, hopefully the “right” answers, if there is such a thing as right answers.
Bob had never spent time mingling much in the upper echelons of his company. When he did, he listened. He rarely said two words together. He nodded his head in agreement many times. He kept his face placid when he misunderstood or disagreed privately. The very last thing Bob would ever do is to draw attention in his direction. Bob liked his job and wanted to simply continue doing his job. Rule number one for Bob is to never stick one’s neck out far. Or scooch too far down a very skinny limb.
But now, Bob had no choice in the matter. He could not hide in a dark corner. He was the main event. Bob noticed his forehead was slightly moist from perspiration. His shirt collar was uncomfortably tight. Almost as if he were sitting under an actual limelight, Bob felt some heat.
Laid out in front of each director was a copy of Bob’s proposal. Several directors leafed slowly through their copy, turning pages, and scanning contents, almost as if they were seeing it for the first time, quietly pondering the question before them. Bob knew today was not their first look at the proposal. They had studied it previously. Their minds were likely already fixed on a decision, which Bob could not know.
The contents of the proposal were organized in a very common format of a standard cost-benefit analysis: How much money would the investment require? What is the expected return on investment? How long would the project take? Who would be impacted?
When can the return on investment be expected? The document was produced with help from a team of analysts from the finance department in corporate affairs. They knew the drill. This wasn’t their first rodeo. The proposal was nicely drafted. The numbers all looked very good.
Bob knew that the proposal was produced based on many assumptions, though. Non-tangible benefits were somehow cast into financial values. How does one evaluate increased efficiency of an organization? How does one count the cost of worker attrition due to the taxing nature of work life on personal life? How much does a new employee cost to train to perform certain operational functions? What is the benefit of pooling data centrally and having control over access? What is the cost burden of the present situation: having data scattered helter-skelter in many files across who-knows-how-many company PCs and laptops? But that is what the analysts do. And they did their job well.
Bob stood up on cue and stepped to the center of the conference room next to a TV monitor whereon his presentation was cast. With his kneecaps shaking a bit, he began his presentation by reviewing his decision-making processes. Afterall, the process used to arrive at a decision is probably as important as, and arguably more important than, the decision itself. If the process is flawed in some way, if corners were cut, if all alternatives were not evaluated, then a decision itself could be, and often was, equally flawed.
Bob shared his journey to the conclusions he listed in his proposal. He had looked at the company’s business processes to understand whether a case for improvement could be made. What was the big deal? Bob often asked to uncover core issues. In this case, Bob had been able to distill the issues into a couple of key points:
1. Business Scalability. There were many, many issues and complaints made by those in “the trenches”, which fell into this category: Efficiency, or doing more with less and maximizing revenue growth while minimizing corresponding cost increases; Sensitivity, increasing the volume business transactions without overloading business processes; Opportunity, or expanding into new markets supported by existing, efficient, well-established workflow processes.
2. Cost Reduction. Data loss, or reducing the potential for losing, or misplacing, essential data used in performing job functions in a timely manner; Business Process Automation, or the formalization of business processes and procedures supported by electronic computer systems; Retention, or making employee work-life as pleasant as possible to reduce costly human resource turnover; Training, or the cost of training new employees with known, well-defined business processes.
Bob looked around the board room table and saw he held a captive audience. Apparently, Bob had touched on topics important to all directors.
Bob then explained the alternatives he had considered in his analysis of alternative improvement options. Among the options were:
1. Do nothing. This option is rarely considered. Doctors call this the “Do no harm” philosophy. One should consider whether doing anything will make the situation worse.
Finding: Present situation is not sustainable. Business departments demand a change.
2. Make minor adjustments to the present processes. If a change must be made, and one doesn’t know exactly what must be changed, looking for the “diamonds in the rough” opportunities, or making small adjustments, can make a huge difference. But finding this sort of “diamond” may not be so obvious, or it likely has already been found and tried.
Finding: Business departments do not see much opportunity for overall improvement potential in doing minor adjustments to existing business processes.
3. Make piecemeal improvements to critical business processes gradually over a long time. In other words, make improvements for one area of the business without overhauling all business processes for all areas.
Finding: All the business processes are inter-related. Data processed by one area must be shared with other areas. And business departments do not have the patience to endure their present circumstances for an indefinite period until all business areas have been improved.
4. Automate Business Processes by developing an application internally using company resources.
Finding: Company does not employ resources with all the skillsets required to build large-scale, enterprise-wide systems. And development of a comprehensive system would likely require a minimum of many, many months, possibly years, when considering many risk factors, such as development resource turn-over, skillsets in many different technical disciplines, and changes to requirements over time. The biggest risk factor is probably that requirements may have changed by the time development is completed and deployed.
5. Automate Business Processes with off-the-shelf software applications.
Finding: Business users prefer this option as the product has been developed already and successfully implemented for other vendor clients. It is available today to implement immediately. Several vendor products were evaluated. The business users have selected one that appears to have most of the bells and whistles they need.
Bob then shared a summary of the expected cost and implementation timeline. A high-level project plan had been drafted for the board’s consideration. Bob pointed to key milestones and checkpoints. He then opened the presentation for Q&A.
Bob scanned the room for comments. He noticed movement on the left side of the conference table and directed his face in that direction. Tell me, Bob, what happens when delivery dates for milestones slip? Will the board be asked to allocate additional funds? Bob swallowed hard. It was a difficult question to answer. There was a hint of suggestion that someone’s head might roll.
The answer, sir, is Yes and No. Your question is a very good one. And appropriate. I don’t think it will come to that. Let me tell you why. First point, our contract with any vendor will stipulate some cost recovery terms if key milestones are missed. We hope this disincentive will keep our vendor’s attention focused on completing the project on time and on budget.
Second, the key to successful project delivery is to manage scope. Project scope always tends to creep a bit here and there. Most scope creep can be managed by simply shifting project priorities and making trade-offs. Now and then, though, something unforeseen occurs, which may have a significant impact on delivery time and budget. For these items, the board will have direct control to reject additions to project scope or accept the additions and allocate additional funds. So, to answer your question, you may be asked to allocate additional budget. But you do not have to agree to additional budget allocation.
Another director motioned to speak. All faces turned in that direction. Bob, why was this particular vendor selected? What pros and cons were weighed in the decision?
Thank you, director. We began with a list of 10 possible vendors. We started by asking independent consultants to tell us their perspective of the pros and cons of each vendor. Then, we sent RFIs (Requests for Information) to many of them. We discovered some vendors were mature, having 50 or more customers, while others were earlier in their development, with just a handful of customers. Some vendors were self-funded while others had financial backing from private and growth equity firms. Some vendors specialized in certain markets primarily while others marketed their application as crossing all commodity markets.
We were able to whittle down the list to just 4 vendors, which seemed best suited to our company’s needs. Our selection criteria were a reputation for a quality product related to our company’s business focus; a history of great customer service and continued product development; and, of course, cost. Each of these 4 received, and responded to, our RFI.
Each provided 3 references.
We followed up by calling all the references and recording what they said. After sharing our findings with our business users, they asked to see all 4 products. They committed to spend one day with each vendor.
Each business area selected a representative to attend each product demonstration. We provided a scoring sheet for each attendee to record impressions. After a week of attending product demonstrations, we scored each product to determine how closely each fit our company’s needs. Each product had its strengths and its shortcomings.
Ultimately, 2 vendors were selected. We sent each an RFP, to which they responded. After evaluating each vendor proposal on the merits of cost and benefit, we, the business groups, and corporate IT, chose a finalist and a runner up. The proposal you see in front of you reflects the cost and benefits of the finalist. The finalist was chosen on the strength of its product, its reputation for great service and customer care, and lastly, but not less significantly, because of its affordability.
I realize my answer went a little long, sir. My answer may have been more than you may have requested. But I believe you should have some context of this journey to better appreciate our product selection.
A third director motioned to speak. On the topic of affordability, what is your impression of this budget you are proposing for us to allocate? Is this typical?
Bob took a moment to collect his thoughts before he responded. Well, sir, the number there is quite a sum of money. I think we can all agree that committing these funds is a big deal. To put this number into some perspective, let me compute for you the rough cost of an alternative course of action, which is to develop software internally, assuming we had the kind of development resources and project management required for such an undertaking.
First, we would need a small team of developers. Let’s say three, which is a low-ball assumption, each having an average annual salary of $120K. We would need a couple of business analysts, too, to work with the business users to draft detailed requirements and help with the product roll out. Let’s say $100K each annually. And we would need a project manager to keep the project on the rails. Let’s say the PM’s salary is $150K, for an experienced PM. Let’s assume the product takes 18 months to develop and 6 months to roll out. After adding up the costs, the total would come out to be something like $1.5 million in human resource cost.
So, when internal development of software is compared with the option of purchasing vendor licenses for a system already built and deployable immediately, off-the-shelf-ready software does have real advantages. And we haven’t factored into the equation any notion of project risks involved in custom-developed software. The cost of custom software I mentioned just now is only salary costs. This cost does not include the possible cost of loss of business growth, or the increased business cost due to business growth, while a system is in development for perhaps as long as 2 years. The business community also mentioned their concern for growth in operational costs due to worker exhaustion and fatigue, which may also result in some potential workforce attrition.
Generally speaking, I’ve been told that licenses to use off-the-shelf software can be purchased for perhaps one-tenth the cost of custom development of equal or similar quality. So, there is real value here.
Off-the-shelf software does have a couple of risks, which we should consider, and have considered. We want to be careful to make sure the selected product actually does what we have been told and shown in product demonstrations. The second thing is to make certain how quickly a product can be deployed successfully. Vendors can be overly optimistic, from what I’ve learned.
For this reason, we have built into the project plan a “fudge” factor anticipating some “drift” in the project plan due to a vendor’s less than perfect understanding of our business needs.
Bob concluded his answer to this question by asking if he had answered the question he was asked. The director nodded. Bob waited for the next question. He didn’t have to wait long. Bob, what sort of annual cost reduction can we anticipate by purchasing and deploying this new system?
Bob had hoped he wouldn’t be asked this question, although he had anticipated it. Identifying costs was one thing. Calculating cost reductions was quite another. How does one put pencil to paper to work out what costs the company won’t incur? Normally, a board considers this sort of cost represented in a headcount they no longer need to employ, or a headcount of employees they won’t need to hire at a future time of business growth.
Many benefits of electronic automation of business processes are intangible. How does a person explain to a board the balance sheet benefit of employee work-life improvement?
How does one rationalize profit gained when important operational data does not fall through proverbial cracks in the floor? Intangible benefits must be seen, in a certain sense, using eyes of faith, knowing benefits exist even if they can’t be easily seen or understood in dollars and cents. Somehow, they will affect a balance sheet in positive ways. Given time.
Bob cleared his throat with a quick ah-hem. Your question, sir, is very difficult to answer.
The best answer I can give you is that the business community feels that they will be able to grow business without incurring a corresponding increase in the cost of doing business. For instance, operational administrators will be able to process more business transactions with the same, or minimally more, number of workers. Another way of looking at this opportunity is that human resources may be redeployed in even more profitable ways, which are not possible today because of attention being paid to manage a deluge of data. What those ways of redeployment exactly are, I can’t really say for certain.
Time allocated to Bob’s portion of the board meeting had expired. Bob was dismissed from the boardroom so that other important matters could be discussed privately. Bob hurried out of the conference room back to his small office on another floor of the office building. Bob sat down in his chair and breathed a sigh of relief that the meeting was over and done. The whole matter was no longer in his hands.
Bob was very excited to move onto other assignments. He had no idea just how misplaced his excitement really was. Doing a great job has its own rewards, …, and punishment. Bob thought he had finished the book. He did not realize that it was only one chapter, the first chapter. His adventure had only just begun. After seeing what a wonderful job Bob had performed, his management thought to reward him with a new project—the implementation.
Good job, Bob! And good luck.
ABOUT ENTRADE FOR ETRM / CTRM
COMMODITIES COVERED
SERVICES AND SUPPORT