Skip to main content

Author: Donato Piccinno

42, The Douglas Adams IT Project Management Experience

According to Douglas Adams the famous author of The Hitch Hikers Guide to the Galaxy 42 is the answer to everything.

The story goes like this. The most advanced race of beings in the whole universe decide to build a super computer to answer the ultimate question. They wait in anticipation for the greatest technical marvel the universe has ever seen to provide the answer. After the wait is over the answer is 42. The answer is so clever the most advanced beings in the universe cannot understand it. Rendering their creation absolutely useless. The story is a cautionary fable in the faith we place in technology and hyperspecialism to provide the answers to make the way we want to do things easier. Douglas Adams is more than an author. He is adept at conveying the outcomes when the human condition meets technology and process. The unintended consequences when humans do the human thing. Which is to do the completely unpredictable things the technology and process does not expects us to do. How very dare they! The audacity of it all! Douglas Adams quotes and thoughts can all be observed in action at the point IT solutions are conceived in the word of Enterprise Architecture then project managed into use by the real world. It’s the point where technology, human nature and process meet. Anticipating these outcomes well and things go well. A lack of anticipation normally results in unintended consequences. Where IT project delivery is concerned the same old story statistics on IT project performance from Standish and Gartner show a Douglas Adams observation in action.

Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.

We are classically trained to formulate the delivery of IT solutions with our scientific management head on. The ghost of Taylorism permeates every single way of working while delivering an IT project. The consequences are plain to see in the repertoire of Douglas Adams quotes. Missed deadlines, services that don’t meet needs, waste, cyber crime, disillusioned workforce and technology that fails to perform the moment it is exposed to the real world.

A common mistake that people make when trying to design something completely fool proof is to underestimate the ingenuity of complete fools.

I was actually inspired to write this piece following a meeting about rolling out a few laptops and phones. The experience was most humbling and ego destroying. I came away from that meeting kicking myself for falling for the illusion of control scientific management and technology can instil in us. For the meeting we’d come up with this text book rollout process for network, printing, HR, pcs, laptops and phones. Any methodical process type person would not fault it. But it had two fundamental flaws. For the process to work and give the final user the experience they were looking for everyone in the process had to follow the process. The key principle was 20 days prior to the IT solution going live the process needed to know the name of the employee. But in the real world a person could be employed on the day they needed the solution. Without the IT solution that employee would be sitting around for several days as a new starter request made its way through the process. The 2nd fundamental probably caused the team to miss the 1st fundamental flaw. The process was designed by experts who had no idea what it was like to be the user on the day they needed the IT solution. We knew what they needed from a functionality perspective but had no idea what it was like to be the user. So who were the ingenious fools in the Douglas Adams quote? The end user not following the process? Or the team that designed the process. IT project plans consist of activities from many different domains. Our plans are full of specialists i.e. legal, procurement, engineers, Infosec, HR, developers, architects, user managers, finance and the ITIL brigade. All insisting on something done in a certain way. I’m sure their motives are ulterior and it is always for the good of the company. But there is an inconvenient truth my comrades can fail to grasp. Unless experts design solutions or process from the point of view of the end user what is being insisted on is as much use as a chocolate teapot.

He was a dreamer, a thinker, a speculative philosopher… or, as his wife would have it, an idiot.

Again it’s the human condition and nature at work. As IT project delivery experts we like to think we are right even when we have zero experience in what the end user experiences. That makes anyone who thinks like that an idiot. The way around being an idiot during delivery of an IT project is to constantly check for experience shortfall within the team designing the process. A lack of experience in the experience of the end user in their operational environment is the experience shortfall. Secondly, involve people who have done what you are trying to do. Fail fast by rehearsing implementation scenarios early and often. Particularly, where the rollout environment has the following context:

  • Accessing the solution from or connecting to a heterogeneous network
  • Rollout sites are remote
  • Users are not tech savy
  • There is an inter generational gap between the project team and the end users

To give real service you must add something which cannot be bought or measured with money, and that is sincerity and integrity.


Advertisement
[widget id=”custom_html-68″]

Back to our user who has just been employed and walked in on the day of rollout. With my compliance and process adherence hat on I could say, ’Sorry we cannot give you a phone and laptop you need to do the job. Please liaise with your line manager.’ What if a whole organisations existence is about that particular type of user being empowered from day one. The beating heart at the heart of the house so to speak. The process compliance world tends to have a transactional relationship with the real world. As long as the real world behaves in a way that is a valid transaction. Everything is #peachy. If not, the tendency will be to try and get the real world to change. Which is fine until such a stance becomes dogmatic or a non-starter because the real world cannot be changed. An IT project delivered in that kind of culture is unlikely to perform on many fronts. Usability for ease of use and ease of deployment will suffer a dip in a performance. What if we rethink the project plan to rollout an IT solution based on principles or probity, sincerity and integrity? What if we view the user experience of receiving an IT solution as a customer experience? Would we end up with an outcome where on the day we say, ’Sorry we cannot give you a phone and laptop you need to do the job. Please liaise with your line manager to go through the process.’ No, a customer of the project would have their IT solution ready at the point the needed it.

Thinking of a rollout process from a perspective of customer experience management, probity, sincerity and integrity results in handovers of IT solutions where all user personas and real world circumstances get considered. Such thinking challenges the way IT solutions are designed to be accessed. For example, take cached credentials. Great from a security compliance point of view but as much use as a chocolate teapot in the rollout scenario below. With cached credentials the device has to be sent back to base.

  • Heterogeneous network
  • Remote sites
  • User details not known until the day they need the laptop or PC.

A prime example of the technical world not understanding the real world. Leaving the project wide open to the following outcome. Observed by Douglas Adams at the touch point between human nature, the human condition, technology and experts who lack understanding of the real world. The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at and repair.