A lot of things are built every day in every corner of the globe, from enormous skyscrapers to tiny plastic widgets and they are mostly useful things that are built efficiently with the end customer in mind. Many Information Technology (IT) things are also being built but it seems to be a little harder to quantify how efficiently they are built and how useful they are going to be. There often seems to be a disconnect between what the users want and what is delivered.

Building a thing cover image.jpg

New IT things are exciting. The thought of designing and building them is why a lot of people decide to work in IT. You need clever people to come up with the idea, design a solution, build it and get it out to your customers.

Unfortunately, you also need to do the boring things:

  1. Work out what to do when the thing goes wrong
  2. Document the thing and how it works
  3. Test the thing
  4. Get the thing into the right environments at the right time
  5. Teach others how the thing should work at a really detailed level throughout its life
  6. Support and fix the thing when it starts to cough and develop a rash at 3 am
  7. Plan for how to retire the thing when it gets tired

The problem is that when a team or an organisation decides to build a thing they often forget the boring bits and get excited about bringing a great idea to life. They forget how many teams and processes they need to engage with in order to ensure that the thing is delivered safely, smoothly and effectively. They forget about the other people who need to be consulted and who is best placed to help at the thing’s birth..

The thing delivered is an infant that will grow up, have a career and then age, deteriorate and have to be replaced or radically changed in order to ensure that it is still adding value. Life as an IT thing can be harsh.

There are a number of attributes the thing needs to possess in order to be a worthwhile member of society that lives a long and useful life. Not all of these are important at the exciting stage when a small number of people get together to map out their great idea and build a prototype. They just need a bit of money to build the components, some clever IT builders and a bit of infrastructure. You can get by with the tiniest amounts of stuff in order to build your prototype, and it is quite easy to demonstrate a cool piece of functionality on the thinnest of platforms.

As you move to the pilot stage most IT builders are still really just interested in the functionality – ‘Does it do the cool thing I want?’. There isn’t much focus from Finance, Security or Support yet as it hasn’t tracked across their radar. At rollout, you need a lot more in the way of capacity and environments and people are starting to take notice. This is usually where the arguments start.

‘You didn’t tell us it would be that big!’

‘It has lots of bugs, how am I expected to support that?’

‘It costs how much?’

‘It breaks all our Security rules!’

Building a thing – the capabilities you need

Building a thing.png

At each stage in the thing’s life there will be activities and resources required to deliver the stuff that is needed at that stage.

First Build

When the exciting research project starts all you need is a bit of budget, some space in an environment or on a box under the desk. All the clever people are concentrating on designing a really cool piece of kit that delivers functionality someone will want to use.

Pilot

At the pilot stage, people are starting to take an interest and ask why they haven’t been involved before. They will start raising risks and issues around the project and suggesting you need to rethink the design in order to comply with security requirements or space constraints. The users demand the thing goes live by a not too distant deadline and the pressure starts to mount. They can’t understand why your cool prototype can’t just be made live. ‘Surely you’ve done the hard part by now?’

Rollout

As the rollout approaches a lot more people should be coming out of the woodwork – if not then you may have an easy ride but the environment the thing will live on is likely to be very unstable. It may be more exciting to throw untested and unapproved products into the live environment but it doesn’t give the users a very good experience. Security, infrastructure, Testing, Service Transition, Support and Vendor Management should all be lining up to ask you about the thing’s impact on them and their processes. This is where life gets really tough as you have that user imposed deadline screaming towards you and you need to cut corners in order to get the thing live by the date you promised. At this point, a lot of teams decide that documentation and thorough testing is a nice to have.

Business as Usual (BAU)

Many things limp along in BAU handicapped by long-running issues that no-one has time to fix that were introduced when all those corners were cut. At this stage, the original designers have lost interest and are onto the next exciting thing and no-one is measuring the ongoing cost of having a thing that doesn’t quite work and needs to be massaged through every day by expensive support people. Very few businesses work out whether the total cost of ownership of the thing merited the investment as these support costs are submerged in the overall cost of the department.

Retire

Eventually, the thing will stop being effective and will no longer be a fit for purpose thing that supports the user processes. It is time to retire it. If it was well documented and recorded during the build phase it shouldn’t be too difficult to work out what it did and what it interacted with. If, however, as is usually the case, it wasn’t well documented (remember the decision at Rollout?) then the team tasked with retiring it has a long and lonely road to tread. They have to take it to bits to work out what the impact of switching it off will be. This can be tricky. There are millions of IT things still out there that businesses are too scared to kill and they run on, devouring space and electricity until some brave person hits the red button. Most businesses are not measuring whether the cost of ownership of the thing was worth the initial investment but you know that every day the cost goes up.

Building better things

IT departments that are effective make sure their IT things are upstanding and productive members of the society and environment they inhabit. Nobody wants a difficult child or teenager that hasn’t been fully tested, isn’t safe, isn’t educated and doesn’t have any friends. As this teenager gets older they will continue to be a disruptive presence in your world – and they will cost you a fortune.

If people delivering a thing could spend a bit of time upfront thinking about who they need to involve in the design and build process there would be many fewer things landing in the working world that are not fit for purpose, supportable and well documented.

Building a thing – people involved

Building a thing - people.png

First Build

  • Talk to Finance about how big the thing could be and make sure that someone – usually the business user the thing will be delivered to – has created and signed off a sensible business case that covers the lifetime of the thing.
  • Make sure the Infrastructure team know how much space and processing power you need now and in the future. Make sure someone cares about how much this could eventually cost.
  • Make sure your project team is talking to lots of people outside the team about what they are doing and getting advice and guidance from architects, designers, security, support and other delivery teams on how best to build the thing. Make sure it is on the architecture roadmap and conforms to the architect’s vision for the future.
  • Talk to other projects about whether your thing will conflict with theirs.

Pilot

  • Now is the time to really engage with Security and make sure they are happy with your solutions and that they are safe.
  • Talk to the Support teams about what is about to land in their world and describe how you are designing it to be auditable, monitored and supportable. Discuss the best way to design error handling so it can be flagged on their systems in a meaningful way.
  • Start thinking about how to train the users of the thing in how to use it.

Rollout

  • Everyone you have already spoken to needs to understand your rollout plan and when things will be delivered. Check that they are still happy and that it fits in with the overall plan for the department.
  • Keep the users informed on progress and ensure that they know what to do and how to use the thing.

Business as Usual (BAU)

  • Ensure that someone owns the thing while it is serving a useful purpose. Make sure that person or team understands the value of the thing and spends a bit of time thinking about how to improve it as it runs.

Retire

  • When the time comes to say goodbye to your well-loved and trusted thing it will be so much easier to give it a good send-off if documentation has been kept up to date, costs and benefits have been measured, lessons have been learned about the process it supports and the project replacing the thing is given the objective to turn off the old thing smoothly with no business impact.

So, as with everything else in life the building of an IT thing needs attention to the mundane details as well as the cool stuff. Keeping everyone likely to be impacted informed is key to getting it right and you need to be prepared to let the idea die if it turns out not to be cost effective for the organisation paying for it. Keep the communication lines open and you will still get a kick out of delivering great functionality while enjoying the added excitement of knowing that the thing is really paying its way.