The Lovelace Lecture
“This lecture pays due tribute to a lot of our computing heritage,” says Alan Pollard, BCS President in full regalia with a presidential medal around his neck.
I take my seat in the conference room of The Wellcome Trust. It’s a beautiful space. One of the best things about attending events is getting to nose around other people’s offices.
Each year the Lovelace Medal is awarded to someone who has made an outstanding contribution to IT. In exchange for the medal, the winner has to give a lecture and it’s one of the most prestigious events on the IT calendar. We are gathered to listen to Dr Tony Storey from IBM, but unfortunately he isn’t here.
Ian Nussey takes the podium and explains that Tony isn’t well. He gives us a pencil sketch of the man we won’t be meeting. Tony prototyped the world’s first relational database. He has spent two decades working at IBM. He’s won lots of awards and done a ton of technical stuff with Java and MQSeries. He’s a self-taught guitarist. He breeds tortoises. He started his treatment this afternoon.
Standing in for Tony is Maurice Perks, who was made an IBM Fellow at the same time as Tony. He has a presence at the podium, as if he’s used to people listening to him. And we are listening.
“The sins of IT projects and why they can fail.” Maurice’s voice would carry without the mike.
He defines failure as not delivering the functionality on time and to budget: OTOBOS. He defines a large project as one that takes over a year, and then explains what the top issues are with IT projects:
- They are big because they have lots of users
- The technology changes fast
- IT requires a diversity of skills from business analysis to chip manufacturing
- They are very expensive and that makes them visible.
The rest of the lecture is Maurice’s top trouble spots, but not a lot about how to fix them. He’s entertaining and interesting, but I can’t help feeling like I know all this already, all these soundbites strung together.
- Don’t assume testing is a mere formality.
- Integration is about breaking it down but then building it back together again.
- Some bits of projects are not under our control, like an interface to a third party.
- Don’t manage the method.
- And Perks’ First Law: “Components that are not designed to fit together and form a working system only do fit together by chance.”
Maurice’s advice to tackle poor project performance is to break things down into smaller pieces, and understand the risks and changes involved. He’s an IBM Fellow, with more years on the job than I’ve been alive. He’s confident and self-assured. And right. We all know he’s said sensible stuff. But talking to people afterwards one thing is clear: if we knew it all before, why are IT projects still failing?
“Maurice’s advice to tackle poor project performance is to break things down into smaller pieces, and understand the risks and changes involved.”
Lol sounds like Maurice was talking about PoP Project! I absolutely agree that a lot of advice available for PM (and in many other areas as well) is rehashed and reused. I think there are 2 reasons (I won’t count being lazy).
1. The person comes across the lessons on their own and so the weight of the words is more for that speaker because of some prior experience.
2. Half of projects are still managed without adequate tools (I am saying adequate because there are some projects that can run on Excel just fine, but there are many that do that definitely can’t). This just means there are a lot of people who may not know of these basic lessons.
So I expect we will keep hearing about TDD, iterations, and the like until all projects run OTOBOS.
There’s a big difference between the simple solution and the easy solution. The problem with breaking a big problem down into management chunks is that it’s so tempting to manage those chunks. So knowing the method is easier than knowing how to implement it.
That said, frightfully generic lecture. I suppose it’s good news that someone so experienced is saying things less experienced people already agree with, though. It does mean we’re on the same page, at least.