“6 most-dreaded IT projects” on CIO, June 27, 2018.
Under scoped and over promised
Whether it’s from excessive optimism, a desire to impress the boss, or a failure to properly scope projects, underestimating the time and effort required to deliver an application can turn a challenging project into a hellish one.
“You see people being very optimistic about what they can deliver in a short period of time, especially in fast-moving companies,” says Alan Zucker, founding principal of Project Management Essentials.
In the late 1990s, Zucker was working as a project manager in the accounting department for a Fortune 100 telecom company. The carrier was billing more than $1 billion a month and using hundreds of interlinked spreadsheets and databases to keep track of it all. The solution was to build a single application to close the books each month, using Sybase on the back end with a Power Builder interface.
After a company re-org, responsibility for the project fell to Zucker’s group.
“The IT group came up with a really elegant idea, which was to load everything into a database and let the accounting people build their own business rules,” he says.
But they’d promised to deliver the app in nine months. When Zucker inherited the project, four months in, not a single line of code had been written. The IT group was still collecting user requirements. And they were discovering that the job was much more complicated than anyone had anticipated.
That’s when the finger pointing started, Zucker says.
“My counterpart in the IT organization started to get very defensive,” he says. “He would write these emails that went on for pages and felt like police investigations. ‘On this date at this time, so and so said this…’ and so on. It became this escalating situation where there were just no constructive conversations to be had.”
It was only after the IT manager was reassigned and Zucker got a new partner and a more forgiving timetable that the project moved forward. The app was ultimately a success, but it took another two years before it was finished.
Lessons learned: Zucker says he realized that, in the future, he needed to step back from confrontation and find a way for both parties to come out with a win. He also learned that it’s OK to ask for more resources and reset the original terms of the project. And finally, it was a lesson in how changing a single resource — or one person — can totally improve the team dynamic.