The Exceeding Banality of Burning Projects

Listening to a podcast recently I heard a project manager say of himself that he is often given the project that are "already on fire." I cringed, because I have made that comment myself quite a few times. Too often it was in interviews that I made the boast. It's not really that remarkable for a project manager to be handed a project on fire and asked to make something of it. 

There are many reasons for a project to be "going south," and it's going to show time, cost, scope, and possibly, ultimately, quality.

One such project for me was a cloud migration. A major data center was being shut down and all the services hosted there had to be migrated to the cloud. When I got involved it was already badly behind schedule, and extra cost had been incurred in renewing the lease on a data center's space while also paying for cloud services. What had happened was a project manager had laid out a very solid plan for doing the migration in waves. It was going to involve a great deal of coordination with multiple stakeholders, but all in a day's work for a dedicated project manager. However, she didn't get the chance, as there was a reorg and she was laid off. 

The engineering team was left without a project manager for about a year and a half, when I came along. The team lead quit to take a job elsewhere right around the same time, so sorting out status was tricky. After a couple of weeks of review the new lead and I determined that some services had been incorrectly checked off as migrated when in fact the migrations had only begun. Meanwhile, the engineers had been left to their own devices with the stakeholders, so they emailed everyone they could think of and worked with those who responded.

The result of this spotty lack of stakeholder management was that the neatly organized waves existed on in the project plan. Applications and services were being migrated from all of them at the same time, based as I said already on who responded to an engineer's email asking to work together to migrate.

There was nothing particularly heroic in my involvement. I worked with the team from an Agile perspective, helping them organize in a Scrumban fashion, and helped set some order in their approach to the migration. After a time I rolled off the project for other duties, and another project manager picked up the torch and carried it home. The data center was successfully shut down without a loss of any major services under her watch. 

This story has repeated a number of times in my career, and it's just part of the job. Shifting priorities and resources, poor initial planning or a lack of guidance altogether can run projects off the rails or straight into the ground. Time stretches on, costs balloon, and focused scope is lost. Sometimes someone with some pull notices, makes noise about it, and a project manager is assigned. It could be any of us. Perhaps there are specialists, but for the most part I really think it could be any available project manager. 

Work in this profession long enough and it will seem a regular occurrence to you as well. Projects are always on fire. Just try to be really good at keeping your cool while trying to get them under control. You don't have to be special to be the right person for the job. 

Popular posts from this blog

Essential Scrum Metrics

Essential Kanban Metrics

No Projects Are Agile