Change Request = Risk Premium

Fixed price work is all the rage with IT finance departments and senior managers, even in this age of moving towards Agile methodologies and incremental delivery.

There’s definitely a big dichotomy between agile and fixed price, with the former based on flexible scope, frequent delivery and frequent business led prioritisation, and the later fixed scope, large delivery milestones and fixed priorities.

What I’ve found in a number of projects that attempted to be fixed price but flexible is that it leads to a large number of change requests. In itself this isn’t necessarily a bad thing – it’s surely better to have a change request than deliver the incorrect or out-of-date functionality. However, I’ve also observed that the cost of the change requests tends to increase, and frequently make the project overall uncompetitive compared to a regular non-fixed delivery.

I believe the reason for this is that the quotes for change requests build in an increasing risk premium. The logic for this is fairly simple:

  1. Project is priced based on assumed perfect knowledge of the requirements, with a contingency.
  2. Change request comes along, so the confidence about the overall requirements falls and a risk premium is added to cover assumed increased contingency requirements.
  3. Another change request comes along, so the confidence falls further and the risk premium increases further.
  4. etc etc

You can’t really blame the delivery team for this – it may be a bit naive to assume the requirements are clear/perfect at the start, but you have to work on some assumptions. Change requests typically mean that either the business are moving the requirements, or worse for existing systems that difficult parts of code/functionality are being uncovered; denying this increases the risk and the cost would be foolish.

I’m not sure there’s a good solution to this, but there are a couple of things I’ve seen.

Have a limit on change requests, either numeric or in percentage of cost terms.

This has a number of implications. For the delivery team, it means they have confidence the scope won’t keep changing, so the risk premium is lower. For the business, it means they have to think very clearly about changes and prioritise them properly.

Encourage a larger contingency, but allow use of it for small changes.

This means that a small amount of change is accepted and accounted for, so giving both sides more flexibility in how to manage it.

Overall I don’t believe fixed price is typically the right approach except for items which can be very clearly packaged (e.g. upgrades, migrations, modules linked by defined API), in most cases Agile will deliver a better solution more reliably. However, if you are using fixed price, perhaps the idea of a risk premium is useful.

Custom Search in IE8

Adding custom search providers to IE7 and IE8 was a bit convoluted, involving going to the Microsoft site to create the required XML based on a template URL. I could never work out why they didn’t build it into the browser, but it did kind-of work.

However, the MS site no longer offers this. A web search gives plenty of blogs telling you how to do it using the Microsoft site, but the option described is no longer there.

Fortunately, Eric Lawrence has put the functionality on his EnhanceIE.com site here:

www.enhanceie.com/ie/SearchBuilder.asp

Thanks Eric!

Resizing an Embedded Visio Canvas

As I work in a big bank, I handle a lot of Powerpoint presentations. Most are cut-and-paste versions of others, slightly modified for whatever senior audience is relevant at the time.

Unfortunately the graphics capabilities of Powerpoint are limited, therefore a lot of presentations have Visio diagrams embedded in them (if I’m lucky, and not just a nasty pixelated bitmap instead).

When I’m “tweaking” a presentation, I’ve often found it necessary to re-organise the layout, including the Visio parts, and find that the size of the Viseo tends to go crazy, either leaving me with big white borders to crop or losing parts of the diagram off the side.

Fortunately I found the very very simple solution here:

Press the Ctrl key and move your mouse over the edge of the canvas; when you see your cursor turn into a double arrow, drag the canvas edge to the required size.

The only issue I’ve found is that Powerpoint can update the zoom level while you are doing this, which stops the operation and can make the canvas resize incorrectly. Just make sure you do it fast enough before Powerpoint can react!

Gravatar

A Gravatar is a Globally Recognized Avatar, used as an identifying image on blog posts, comments and similar. The concept is a simple but clever solution to the problem of how you get an image linked to someone’s email address without exposing that email address to the public. A naive solution could be the following:

<img src="http://provider/avatar?email=john@smith.com">

The trouble is, the email address is there in the HTML ripe for indexing and spamming.

Gravatar uses the simple approach of hashing the email address, so it is not exposed:

<img src="http://www.gravatar.com/avatar/ff938a97ec6097459954962e66c88a43">

This gives the result below for one of my email addresses. Note that the address isn’t exposed, I can happily post it here without inviting a deluge of spam. I’ve also included the gravatar of a commenter, again not exposing their email, and shown the neat “unknown” image returned if the gravatar doesn’t exist.

pseudocode gravatar flashforward gravatar unknown gravatar

The other point of course is that the Gravatar site is a widely known solution for blogs, and part of WordPress, so the most likely avatar source is easy to pinpoint.

Out of curiosity I wrote a quick online tool to show gravatars for a big set of emails, and put in the contents of my address book. Of two hundred people only a handful have gravatars, which compares very poorly with the number who have a Facebook account, suggesting Gravatar is still a fairly niche solution.

K.I.S.S.

Often heard advice in system design – Keep It Simple Stupid. It’s a reasonable idea, a little similar to the Agile principle of no gold plating, that simplicity is efficient and robust.

The trouble I find is that all too often it actually translates to Keep It Simple & Stupid, and the result is a design unnecessarily limited or lacking in flexibility. As is often the case in English, a simple word can have many meanings…

Clear, Clean, Pure, Transparent 🙂 these I want.

Amateur, Foolish, Naive, Stupid 🙁 not in my system thanks.

Is there a point to this? Not really, just a thought – I like the no gold plating rule, but KISS is just too simple for me.