Category Archives: Project Management

Standing still

Online Marketing, Processes, Project Management, Technology

Update: Since this post was published I have written up these notes in more detail on the White.net website.

I overheard a conversation between two web people a while ago.

One (a web developer) was explaining a tricky situation.

A client had called with news that a button on their website had broken.

The client wanted it fixed.

Elaborating further, the client explained that they had not ‘touched’ the website in the entire time (1 year) that it had been live.

Therefore it was not their fault it had broken.

The developer then explained that they too had not touched the website in that time period – and neither had anybody else.

This leaves two questions:

  1. Why was the button on the website broken?
  2. Whose fault was it that it had broken?

The answer would prove important because it would be the difference between the developer fixing it for free or the client having to pay to have the work carried out.

So how does something change on a website that hasn’t been touched?

It doesn’t.

The website hasn’t changed at all.

The code has stayed exactly the same as the day it went live.

It has remained in a constant state.

But the rest of the world hasn’t.

In the space of a year a lot has changed.

Including web browsers.

Since January 2012 Google has launched somewhere in the region of 12 new versions of Chrome.

Mozilla’s Firefox was on version 10 in 2012, it is now on version 24.

Even Internet Explorer has had a Windows 8 flavoured overhaul.

So the website hasn’t changed at all.

But everything else has.

The website that worked on Chrome 17, or Firefox 10 or Internet Explorer 9 doesn’t necessarily work on their modern day equivalents.

A website can only be built to the standards of the day it goes live.

So who’s fault is it that the button broke?

The answer is no-one.

The website just stood still for too long.

When everything around you is moving forwards, standing still is as good as moving backwards.

Lock-in and processes

ISO:9001, Project Management

The best processes should be adaptive to changing requirements and encourage the learn and improve cycle.

For that reason, implementing a process documentation system that requires a time or financial cost to update encourages lock-in and ultimately makes the process less able to change.

Lock-in is something that becomes common amongst medium to large businesses.

Perhaps the most common form of lock-in I come across is to do with the web browsers that my clients use.

If my client works for a large company, chances are that they have an IT department.

IT departments who have a remit to maintain hundreds / thousands of machines can become prone to lock-in.

This is the reason why IE6 has survived for so long. Not because people like using it but because the admin nightmare it would cause an IT team to update outweighs the perceived value of doing so: lock-in.

Of course lock-in is a negative thing. It is restrictive and forces decisions to go the way of the lock-in.

This is why processes must exist outside of the realms of lock-in.

If a process becomes locked-in then it cannot be improved and the process will begin to exist for existence’s sake.

This is why, in a recent conversation I had with someone who is implementing a quality management system I was shocked when they explained their plan to have their entire company process produced on a wall chart.

The wall chart would require a level of pre-planning, design and a relationship with a company to produce it.

The idea of the wall chart was great.

It would allow the company to monitor clients as they move through the company process.

The actual chart however would be the opposite of agile.

Imagine this scenario;

You review your process and find a small area that needs a minor change to improve things.

You remember that although you can change the process, it won’t be reflected on the wall chart.

The wall chart is too expensive to bother with changing for such a small tweak.

With the wall-chart as the go-to for members of the team there is a risk that they may continue working from the existing process and not the new and improved process.

You decide that it is safer to keep the process as it is so that everyone is working from the same plan.

Lock-in.

Ideas and Delivery

Online Marketing, Processes, Project Management

I was recently talking to someone who asked me, “what do you mean when you say that ‘ideas are more important than delivery?'”.

It was in reference to a line on the about page of this website and was a good question.

Finding myself in a tricky spot where the only exit was the exact shape and size of a well considered answer I had to engage my brain.

After a brief delve into my memory I answered:

It was based on my time spent studying and subsequently working at the University of Winchester with Chris Horrie who is always full of good ideas.

Not only is Horrie always full of good ideas but he has an uncanny ability to side-step the awkward politics and difficulties that crop up with delivery.

The result of this was that ideas were cherished and encouraged and delivery was believed to be a thing that would follow, one way or another. A solid idea craves delivery.

Although my answer goes some way to describing why I used the ‘ideas are more important’ line on my about page, I don’t feel that it fully captures the essence of what I was getting at. It also risks writing off ‘delivery’ as not-so-important, but this is not the case.

So, a more concise answer would be this:

Good, solid delivery of a project will never be able to save a bad idea from failure.

A good idea can survive shoddy delivery.

That is why ideas are more important than delivery.

Delivery can happen, there is always a way.

Good ideas cannot be faked. You must work hard to own a good idea.

A good example would be a client who I worked with some time ago.

The client had an idea, it was to create a website that would provide a place for amateur creatives to publish their work, sell it, share it on other websites and the like.

Not a bad idea but it was missing a couple of key things.

1. The client had no solid proof that there was an audience for this product.

2. The client had no pre-planned method of gathering a significant audience, instead opting for a ‘build it and they will come’ attitude.

Fast forward a few months to the delivery of the project, a fine delivery at that.

The website was delivered in the form of a technical masterpiece. Chock full of features, bells, whistles and empty database rows ready and waiting for creative work.

Despite the great delivery and subsequent addition of new features, up-take on the site has been slow to say the least.

The delivery followed the brief perfectly but the idea within the brief needed more time to brew.

I am confident that the site in question will come good, all it needs is some good promotion, but that requires going back to the ideas stage.

You can’t fake hard work at ideas stage. Delivery will always happen.