Intro to Basel II (Credit Risk)

Found this article as a starting point on understanding Basel II, courtesy of wikipedia.

Agile 2005 Conference

Two of my colleagues, DLG and DC, are attending the Agile 2005 conference in Denver. Check out their notes and thoughts on the sessions.

How to Fail with RUP

Check this out - decent explanation of what people do wrong with RUP.

Flashback: Rolls-Royce Aerospace

I was really glad to see that Rolls-Royce Aerospace recently announced plans to build a new overhaul plant in Scotland. I used to work at this specialist plant while studying Aerospace Engineering at university. At that time, post cold-war, the defence industry was weakening and many RR jobs were being threatened (RR builds a lot of defence engines, like the one used in the Harrier "jump-jet"). This was when I decided to get into IT and the Financial Services industry, and specifically to join JPMC in London, so RR really was the first step to where I am today.

Personally, this is/was a cool plant to work in -- you got to see all the leading civil and defence engines, hands-on, and got to see how they test them (yes, the old throw frozen chicken at it story - no-one seemed to point out the fact that a frozen chicken, dead or alive, cannot fly at 37,000 ft, or sea level for that metter!). Btw -- this is the engine I was most inolved in - a joint venture with Pratt & Whitney, and we had to redesign the fuel system to make it more environmentally friendly.

From a business perspective, this is an interesting move on RR's part. In the early 90s everything was being moved south and consolidated as RR tried to save money, improve efficiencies, etc. That fact that this plant is going to be replaced/upgraded to a new plant, is fantastic news and a true testament to what they do there. At the time, it was all doom and gloom and the risks associated with being able to have a career there influenced my decisions then, and where I am now, personally and professionally. Brilliant news for RR and the local economy - I wish them all the best.

Addictive clients

Our clients have addictive personalities. The number of times we have put people into clients on projects and can't get them moved on to other project is crazy.

The problem is as follows: a) plain and simple: our people are the best at what they do, and have a habit of blowing their clients away from a domain and technical perspective, b) SOWs come and go, and we all know that scope changes, schedules change, etc etc, so keeping SOWs in sync with reality is a tough job, and obtaining and keeping good people is a tough thing to do (once they have them, that's it in their minds).

It is the nature and culture of our people that they want to work on new and interesting projects (and so do we!), plus we want them to lead up new client and project opportunties.

So, how do you not upset your client when either the SOW expiry has come and gone and you have had other plans for your people, or you want to rotate them in a pro-active manner ?

Balancing your supply (sales pipeline) and demand (current staff allocation, bench and people you need to recruit) is the obvious thing, but reality is not that simple. I have always said look after your current clients before your future clients, and there are things you can do to actively plan and work with your clients. However, my biggest risk is always that clients DO get addicted to our people and sometimes you have to adopt the band-aid approach -- rip it off, let it sting, then get on with life.

Technology Marketing

As we were preparing some new marketing messages and ideas for our sales team, we ran into an interesting issue -- we actually did not have the exact same view on what we did in life as a company. We have been very successful at executing our projects for clients over the last ten years, are pretty unique in what we do (building specialist business and technical solutions for capital markets clients), and we all have a general idea of what that has been. The problem is really how we actually articulate that at a formal but granular level ?

I ran an emperical excercise (basic marketing 101 stuff). I asked the mgt to answer the following questions:

• Who are we ?
• What do we do ?
• How do we do it ?
• Who do we do it for ?
• What is our value-add to clients ?

The results were very interesting -- we did all agree on the general type of work we perform, but the way we communicated it was inconsistent, yet enlightening, but not surprising. This exercise validated the fact that we have never formally sat down and answered these questions as part of a formal communication plan (mainly because we have never formally done marketing since most of our worok has come through relationships and reputation - imagine we we actually actively market ourselves ?!!). It is clear that we all represent the company differently depending on the situation (not a bad thing), but we don't have the "elevator pitch" nailed. What was interesting was some people came up with some creative (and true!) ways of telling the story which we were then able to use in new ways of communicating our service offering(s).

One other issue it raised was: as a professional services company, how do you formally structure your service offerings ? We have a particular challenge in that we provide a range of specialist skills and services to clients through a project-based approach. However, the reality is that the makeup of the project varies by client and domain. Sometimes the client wants us for our Capital Markets domain experience, sometimes for our technical expertise, and sometime because of our approach/philosophy to projects, sometimes for any or all of the above. The challenge is to stay focused and differentiated from the competition, while also providing a relatively broad level of appeal to prospective buyers on paper. The good news is that once in front of a client we have a really high success rate because we fundamentally understand our clients and know how to "situationally sell"

I guess the acid test will be if we can't tell our own sales guys what our message is, they have no chance of telling our prospective clients ... stay tuned as we sort it all out..

Selling Agile -- A Risk Mgt Sell

I always get asked questions about selling agile projects to clients, and in particular how do we deal with large programs (with all their artificial due dates, and door-stops of func spec), vendor mgt negotiations/objections, and the old CFO question: "how much will it cost for the final product".

The problem in actually dealing with these folks is that they fundamentally don't recognise their own issues/problems/weaknesses, and don't understand the alternatives. Specific issues include:

• Their own time to delivery is very long
• They only have one shot at getting it right
• The users WILL change their minds, and/or there WILL be ambiguities in specs
• The period for ROI analysis is too long as the sheer number of resources, dependencies, risks, issues, etc on the investment side becomes complex to measure, against a highly uncertain measurement of results and thus return.
• They currently don't have a good way of measuring product quality.

Throw into this boiling pot, their desire to fixed price the project and/or require payment on deliverables, and already we get into a never-ending cycle of negotiation. For some other details check out this guy's blog post.

So, let's try to put some simple meaningful and business-savvy ideas forward to the person on the other side of the table:

• What if the user provides the direction in what we build in any given 'timeboxed' period (oh let's say, 30 days?) , and we agree to a set of deliverables in that period?
• And, what if we get paid for the work we did on each 30-day period, providing we did what we said we would?
• And, what if this results in a series of fixed cost schedules ?
• And, what if everytime we deliver what we say, it works in production ?

Then,

• Wouldn't that ensure the users actually gets what they want ?
• Wouldn't that mean that the worst downside risk, is what happens in any 30-day period, resulting in the ability to calculate a series and aggregate ROI numbers ?
• Wouldn't that mean that the product quality is controlled throughout the project ?
• Wouldn't that give vendor mgt and a CFO what they want in terms of risk mgt, controlled costs ?