Our fault? Read the project audit and weep

A wise development team brings in the big guns against accusations of mismanagement on a troubled software project

How can tech projects go south? Let us count the ways: Cost overruns, change of staff, a full moon ... And when it happens, you cross your fingers and hope all the precautions and documentation hold up.

There I was in the conference room at the HQ of a major multinational corporation. I was responsible for leading a software project going into its third year with a staff of 60 working on it. The cost had increased by 50 percent, and now I was being grilled by the executive sponsor (a VP whom I had never met before), a major audit firm that the client had hired to look into the situation, and key members of the project team. How could this have happened when we had done so many things right?

[ For more about exasperating IT jobs, check out "10 users IT hates to support" and "9 signs you should jump ship to a new job." | Pick up a $50 American Express Gift Cheque if we publish your tech story: Send it to offtherecord@infoworld.com. | Get your weekly dose of workplace shenanigans by following Off the Record on Twitter and subscribing to the anonymous Off the Record newsletter. ]

Rewind to the start of the project. My company had won the bid, but the client started out by saying the price needed to be cut by a third. We began the project by going through a series of workshops doing a cost-benefit analysis of major functions and trimmed the scope to get down to the target price. Since all key members of the client's project team were a party to this exercise and the right people signed off, it seemed as though we had buy-in and everyone was happy.

Changes and more changes

However, over the next two years, the client's project leader, "Dan," received pressure from his team to add back the functionality that had been cut in order to meet the cost targets. Dan came to us with the requests, and we accommodated them, but also insisted on cost estimates, documented change control, and written approval of the time and cost impact of the change.

As time went on, we grew nervous as the cost of the project ballooned. We brought in our own audit team to assess the project. The results said we ran the project well, but there were concerns about the amount of change control and the fact that we didn't regularly meet with, nor had even met, the client's executive sponsor. In fact, we seldom met with anyone higher up than Dan.

After the audit, we put together a nice presentation for the client explaining the results of the audit and particularly raising alarm at the amount of change control that had been approved. However, we received a serious slap in the face -- but not for what the report said. We were admonished for going around the project leader, and it was pretty uncomfortable for a few weeks. We were told to never do that again -- not just by Dan, but also by the client's senior management team.

A few months later the original funding was nearing an end. We weren't concerned because the additional funding was there, we assumed, as a result of our documented and approved change controls.

Those approved changes weren't actually approved

It was a dark day when Dan and I met about the matter and he explained that he didn't have the money he had signed for in the change controls. In fact, he said he probably didn't have the authority to sign those in the first place. It then became clear that he felt we had made an initial bid two years before, should keep to that number, and needed to help him out of a spot. My management was open to helping, but definitely not covering a 50 percent overrun.

1 2 Page 1
Page 1 of 2
How to choose a low-code development platform