The problem is that some (or perhaps many) people think that IT projects are just like non-IT projects, and they run IT projects just like non-IT project. IT projects are different, and you need to manage them differently. Sure, there are some principles of project management that apply the same way, but it is a fatal mistake to treat an IT project the same as a non-IT project. Perhaps that’s why IT projects sometimes fail.
Non-IT projects like, say, construction, renovation, or relocation, are what I consider “traditional” projects. These projects are “easy”. Alright, I know the people who do these sort of projects are not going to be pleased that I make their work sound simple. But here’s what I mean. The projects are straight-forward because there are results that can be seen, results that can be measured objectively, man-effort that can be estimated, timelines that are deterministic.
IT projects don’t quite work the same way. You could have consumed 90% of the time, but have little measurable results. It’s right at the end, perhaps that last 10% of the time, when things come together, something we call “integration”, that present the biggest challenges. That’s where things fall apart. You have to manage risks. You have to foresee problems. You have to make backup plans. It’s like playing a game of chess where you have to map out strategies way ahead of time. There may be standard patterns to follow, but there certainly aren’t standard solutions.
I talk about risk management because, really, IT project management is about reducing risks. The goal is to reduce risk level to 0%, at which point, it means the project is “deterministically completed” and you can speak about committed delivery.
The traditional non-IT projects don’t quite work the same way. So in a complicated IT/non-IT project mix, the interaction becomes a little problematic.
What is the point of asking me for a best-case scenario expedited completion time? An estimate that removes all my rubber time, and assumes everything happens on-time and works perfectly right-away? Maybe it’s nice to know, from high-level planning, what kind of best case scenario we’re talking about. But you cannot do this for committed timelines!
Say you are upgrading the computers at the Singapore Stock Exchange over the weekend. Let’s say trading hours begin at 8:30am on Monday. Do you want your project to complete by 8:30am in the best-case scenario? Or do you want a firm commitment that it will complete by 8:30am? Actually, better yet, do you want a firm commitment that it will complete sufficient early, so that if it screws up, you can activate a well-tested backup plan to restore full operations by 8:30am?
This is so simple and such a no-brainer. But I am just so shocked to have to argue over these nonsense about fixing a timeline. How can you plan an IT project based on best-case scenarios?
When I was “new”, I used to grossly overrun my operational maintenance schedules. Then someone told me this: Estimate the time taken, multiply by two, increase one order of magnitude. So if you think it takes 2 minutes to implement a change in a network device, multiple by two to get 4 minutes, then one order of magnitude to make it 4 hours. Alright, maybe this is an exaggeration. But really, you will grossly overrun the time that you think is only actually needed. With experience, we learn how to make realistic estimates of task times. Even with experience, I am still overrunning my estimates from time to time.
IT is the lifeline for many services and applications. Even more so for network. The phone, for example, already runs on the data network in many companies. Do you want to come to work knowing that the phone will work, or merely wondering if the phone will be working that day? You probably don’t even actually think about it, because you assume that, obviously, the phone will work. Whoever actually thinks it is acceptable for the phone to not work?