IT projects are typically full of risks. There can be many human factors, many external factors, and many unknown factors, all of which can interact in unexpected ways. Because of that, it is critical that you actively identify, track and manage those risks. But to do that means that you have to be willing to stick your neck out, be vocal and point out risks that the business side may not want to address.
Some years back, I was consulting for a client that had several IT projects going on in parallel. My primary task on getting a particular project back on track, but I was also asked to oversee the architectural effort for another project that was just starting up. The client was developing this second project for an outside customer and was in negotiations with the customer regarding both schedule and cost. For simplicity sake, I’ll call this second project “KAID”.
In early November of that year, I attended the first major KAID project meeting. The program manager for the project – that is, the client employee working directly with the customer – laid out the schedule which he was going to give to the customer: we’d start coding at the start of December, we would finish coding by the start of March, and we would finish testing and deliver the system to the customer by the start of April.
He asked one by one for a show of hands around the table for those who supported that schedule. To my amazement, hand after hand went up around the table from the IT project manager, the senior technical leads, the subject matter experts, and others.
When the PM got to me, I pointedly kept my hand down and said I wouldn’t sign up for the schedule – both because there was no foundation for it and because I saw a number of major risks with the project. The project manager looked a bit startled at my rather firm refusal to “go along,” but then finished his way around the table.
