The Behavioral Science and All of Those “A” Words

We are going to start defining your requirements. Since we are now convinced through demos – even if you haven’t even seen one yet – and with expectations that everything is in scope, we just have to ensure we communicate it in this phase so that we, as consultants, know what, where, when and how to deliver it to you.

Since everything is standard in trading too, a quick one-liner for each requirement will suffice. That’s the mental model, for many. I have walked into, or rather inherited, project requirement phases to discuss, assemble and communicate the requirements.

AAA

This is not a credit rating or a minor-league baseball league. Now that we are still traveling in the anticipative state of expectations, a wish list is still embedded into everyone’s mind. Let me help you get that onto paper.

The first three words out of a user’s mouth is give me this with “Any”, “All” and “Automatic”. The triple-A request is the easiest to communicate.

Oftentimes clients communicate, in this phase, that until you do have the triple-AAA functionality, let’s hold off – from the perspective of entertaining any system, down to specific components and modules – until the system does provide 100% of their expectations.

One of two things will happen for those who have these expectations: you won’t be around, one way or the other, or you will finally realize you must move forward by phasing-in or accepting you can’t have everything.

I do not specialize in triple-A projects. I do know of consultants who do, and I will gladly send anyone who thinks they require AAA to my competition. I hope those consultants accept those projects; it will keep them busy and away from clients who understand compromise and that they can get the benefits and value they need from a phased-in, focused approach.

Yes, this expectation occurs, even in markets new to trading like renewables, that the software vendor will just crank out the code for any, all and do it automatically so you don’t have to.

If I said to you, “You can’t have any, all or automatic,” you would throw me out and hire another consultant. After about the 3^rd, 4^th, or as Dave Chappelle says “Fizzafth” consultant, you will discover that any, all or automatic didn’t just apply to renewables but the rest of the project too, you will finally hear me and the other pros who have written the same thing. Wisdom will come, one way or another.

Since you are reading this book you clearly have humility or you wouldn’t have paid for it. You know there are limitations and that you need others to support you to achieve any, all and automatically to reach your business objectives and goals over the goal line.

Therefore, as most consultants would do, I keep billing, I mean I keep my rinsed and re-used requirement templates together. You know, the ones that seem to show up at every project, by putting down any and all things, automatically, without fail. Cha-ching…

What is this accomplishing?

When I was, 31 and leading a large group of 25 or so, my boss said to me, “You can’t fax your experiences to people.” As if at 31, I had any to fax. At 51, I have a few, and I know more and more about less and less. But I have lots of grey hair which equals some wisdom.

As we continue moving through your project, you cannot communicate all of your experiences and wisdom, from the entire leadership team down to the front-line supervisors and staff.

What to do? Most keep on going.

What usually happens is that most every project goes through a phase of defining requirements to achieve the perceived company objectives. Directionally, they are.

They just do not know they are creating unrealistic expectations that, in turn, create a tremendous amount of frustration for staff and supervisors, including executives.

I was on a project, once, and when we were in this stage, the CEO had met with several internal key project owners. She said, “You know, 50% of projects fail.” They heard her but were convinced they were different. Of course, by now they could write a few chapters here themselves. The point is, it is ok to make mistakes and sometimes play the fool, but when it turns to mockery, I walk into an executive’s office and have a conversation. It’s not our first either, since I don’t sell projects to line supervisors.

Why? Executives have to clearly support a project. Approving and supporting are two different things. Executives and I need to have an understanding, and I have fiduciary responsibility, that I have your best interest at heart. And I do.

If the software vendor, who is trying to win your business, can’t show in a demo that something is possible, someone else’s demo guru will, and they will win your frustration – I mean your business – and get to collect those precious checks.

I had a leader once say to me, “I don’t mind walking backward to collect that check.” Well, for me, I do mind.

My point is that the feedback time between scoping and requirements and the project kick-off is so long, that by default of human nature, you start to have high expectations. Since nobody has said anything earlier – like that you can expect to get up to 85% of what you are asking for at best, with one system – each and every person is trying to figure out who misunderstood or who lied to whom.

I think it will be hard to rid human nature of stretching the truth. The key to knowing when something is unusual is when you ask a question, and instead of a demonstration, the response is simply, “We can do that.” If that happens, be curious and follow-up. Although they aren’t lying, I assure you many of them will require many millions to complete. Some problems will never be solved as they will need to change the software code.

To solve this expectation dilemma, we need a game-changing approach to product scoping and requirements to help you save many millions of dollars and opportunity cost. And disappointment at not receiving the project benefits you expected.

Does this mean we should document all of our processes with diagrams and connect the dots from them to the software before we buy it?

That would basically mean you were testing the system before you even bought the product. There will be plenty of attempts after you buy it for your staff and line managers “to get it done before they start,” which doesn’t work well either.

But do you need the process diagrams to really validate that your processes will fit into the new system? No, you don’t. I reiterate this point for clarity.

Here is a compromise: you go through the requirements and label each as a “must-have” (MH), “nice-to-have” (NTH), or “not required” (NR).

Using this method moves us to thinking about whether we really need certain functionality and determine if it is just a nice-to-have to make someone’s life easier. An unrealistic example is a request that any, all and automatically the reports I use each day just show up in my email inbox at 7am.

Seriously, I have had that request. I asked, would it be better if I provided all of those reports to pop-up automatically at any time you log on to your computer? Yep!

This is how projects get sold into the millions. The bigger the expectation, the bigger the perceived value, and the bigger the software and consulting bills.

To be politically correct, that is what is perceived as selling value. Then, as the project starts to go off the rails, there are reasons to remove most of these features.

We have to take this even further, though, to get to realistic requirements. We need someone who actually knows the front-, mid- and back-office, who has worked in the industry, not just as consultant. One who can truly connect the dots.

I reiterate, too, that we have to ensure we know two things: the beginning and the end.

We call it customer-to-cash, but do any more than a few consultants really know what that means? It just sounds good, and most of us are still trying to figure out what it really means, much less deliver it.

The closest we can get to the requirements when we don’t know the beginning and the end, is to at least know the end. Knowing the end allows us to create the beginning.

But wait, the project is being sponsored by the front-office, you know all of the people who make the money and believe, especially if they haven’t worked in the middle-office, and they also need to know all of the reports needed, front-2-back and internally and externally.

When I say reports, I mean all of them. And, guess who has the majority of the reporting needs? You guessed it. The back-office has so many reporting needs that clearly the majority of the reporting comes from them. Financial reporting, to start. Regulatory reports going to government agencies, tax reports, payroll, SEC, exchange, FASB formats and rules, IFRS rules, internal rules, and for pro-forma needs. And then you’ve got balance sheets, income statements, cash-flow statements, three years of history compared, compared to budgets, compared to competitors, and, in the format the banks want to see it: the annual report formats. My favorite reports are for Dodd-Frank and Sarbanes-Oxley (SOX).

Ok, so we have all of the reports, the data attributes for each one, and we are 100% good to go. We are now so far ahead of most of any projects on the planet.

This does not address, necessarily, all of the process steps and buttons needed to push to make data move through a process and move into the final reports. To get all of the reporting needs, and the data needed to support the reports, we do have one more trick up our sleeve to further flush out the software capability.

It’s not in this book. When I take you this far, it won’t take long to isolate where the software issues are. Completing the analysis won’t take more than a week, if that. I am hedging here. It should take me no more than 24 hours to tell you how many requirements are not met.

Requirements Examples

A few examples may further help you develop and understand your needs. Where these are not going to provide certainty, they will help you flush out what you need to know. Moving on to the vendor selection process is the goal here.

1. Requirement: Capture assets as options
   Description: Capture, value, report and settle, where appropriate.
   Requirement Level: Must-have
   • Capture all assets and long-term plant agreements as options
     • Capture each unit per plant
       • Insert all fixed and variable cost by unit
     • Value each with the Black-Scholes Strip Spread Option Model
       • Provide Greeks in a drill down by asset, and unit
     • Value each with a simulation analysis
       • Provide Greeks in a drill down by asset and unit
     • Value each using auto-regressive techniques
       • Provide Greeks…
     • Value each trade down to the 15-minute increment for the duration of the trade, asset-life, or contract.
     • Report on all of the above using any method and provide it by the book structure with 7 levels, down to the fixed and variable cost per unit for any time frame.

2. Requirement: Provide all reporting attributes for each trade
   Description: All trade attributes are captured on trader report
   Requirement Level: Nice-to-have
3. Requirement: Physical and financial position report
   Description: Ability to see trader position in one view
   Requirement Level: Must-have
4. Requirement: Daily MTM report for MTD and YTD
   Description: By trade, trade book structure, trader
   Requirement Level: Must-have
5. Requirement: Ability to physically schedule trades by the hour
   Description: Schedule trades for next hour, day-ahead and out 20 years forward.
   Requirement Level: Must-have
6. Requirement: Slice and dice position reports
   Description: Re-arrange report as needed for each user
   Requirement Level: Must-have
7. Requirement: Hedge accounting treatment for each trade
   Description: Capture and report on each trade
   Requirement Level: Must-have

I can sit here all night and type out 1,000 requirements, though the format you will see is usually a specific spreadsheet – one that seems to magically appear at every client. LOL.

I am using a format that does allow for drilling further into the requirements. The reason I used it is to show you on the first one why you will never get more granularity than I’ve included in numbers 2-7. The more info I put forth, the more likely the requirement will take forever to create.

Most importantly, the more info you put forth, the greater the chance the system won’t do it. Number 1 cannot be done by most systems. Although I’ve used this format successfully, I had to keep complete control to ensure it did not turn into a page for every requirement. At that point we would be getting into designing. It is a balancing act will have to manage. And now you can probably internalize further how a list of requirements can turn into a wish lists, and that the requirements are most likely just a way to keep sales processes moving forward. Let it, as I have uses for these when it comes to finalizing software deals and consultants.