Subject: CommodityLogic.com
From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Fri, 11 Aug 2000 09:10:00 -0700 (PDT)

Mike,
Further to our conversation, here are some of the things I thought of while 
speaking with Tom Gros. There are definitely some challenges we have to 
overcome to make the Hub idea within CommodityLogic.com as successful as 
EnronOnLine rather than have it turn out like Sitara.

I won't repeat thoughts about how we split CL from Enron, but let's put 
ourselves in the shoes of somebody external for whom this was presented as a 
potential solution. Well, that's an easy decision, somebody else is doing the 
hard work, and not charging us very much for it. So sign-up, but don't rely 
on anything until we see everything working.

Handling counterparties not using the system
The challenge here is that the Final Solution World with overybody using the 
Hub is wonderful, but until everybody is using the Hub, we have to keep other 
procedures and systems going, which stretches resources, Development, IT 
Support and user. This was why we decided to delay getting Bolero - the 
concept is wonderful, but the value to any user is very dependent on everyone 
else one trades with using the system. This is classic Chicken and Egg. Tom 
has a vision of CL providing the staff to handle this. This is taking us 
closer to an outsource-to-Andersen-consulting model which is certainly 
achievable, although not quite such an easy sell.

How much resource is left
The latest project always tends to attract the most imaginative people, who 
are therefore not available for keeping everything else going and moving 
onwards. How about if we accept that such resource is dedicated to CL, and 
then review what is left in the remaining environment. Does it mean we hold 
off doing anything? If we do then increasing volume means that we might end 
up incurring costs for massive numbers of people! We should go through 
costing for "What happens if we completely stop development of X project?". 
If that shows one would need 200 clerks for 3 years until something else 
comes along then it may be cheaper than developing, but I hope in most cases 
it is not!

Start small to prove concept
E.g. first application in April 2001 only covers 20 fields
This is excellent, and we needn't shout it too loud to investors in CL, but 
for our internal back office costing we need to acknowledge that it will be 
years before we can switch off many internal systems.
We might limit the payback period on projects not part of this strategy to 3 
years out?

Include European aspects from the beginning
This really isn't very difficult so long as one has some long-on-common-sense 
Europeans (not just Brits) involved in both specification and development 
from the beginning, but an as example of how not to do it, look at EnPower 
which took a year to allow just for currencies etc!

80-20 rule for types of transaction
EOL has shown the benefits of focussing on simpler products first.
Once we have robust warehouses for collecting accounting (DTL) and risk 
(RisktRAC?) numbers then we can think about having vanilla products on STP, 
and yet-to-become-vanilla products on explicitly different, manual 
approaches. Until that time, we have a strong desire to include as many 
different prodcuts as possible for a given commodity in one system, which 
makes separating vanillas from others more complicated and costly (Think of 
certain deals in Power99 which are approximations of the actual deals, and 
manually tweaked every so often)

Testing
Tom's first thought is that we could leverage initial users (who would not 
pay) to do much of the testing.
EOL clearly got its testing done, but other experience shows that in order to 
have anything which saves time one really does need to do all the different 
phases - component, system, integration, end-to-end, and then user-acceptance.
EOL saw confidentiality as an issue and was therefore unable to use many 
external users early in the process. It did have massive 
resource-commandability and so obtained input from many traders. Do the 
Support functions have sufficient slack that they will be able to provide the 
same sort of user attention? Given how often I hear "short people", that 
strikes me as something which in London would require significant additional 
resource, even after MG is absorbed.

What else did you come up with?
Richard