By W. Scott Cameron
I had been in a technical/project management assignment about two years, when one day my boss asked me to come to his office to “discuss an opportunity.” When I arrived in his office, he indicated that the project manager of one of our biggest ($10M+) and most important projects had requested to be removed from the job immediately, and the organization was going to grant the request. He felt I was the most experienced person he had and thought I would be a perfect fit for this job.
This job would, no doubt, pose challenges. Engineering was near completion and most of the equipment was on site — but only 20% of construction had been completed. I would have just six weeks to complete construction, start up the facility, and begin production. I was flattered to be considered, but realistically knew I had only done one similar, but smaller, project in my career.
I had managed that project from the start to the end — so I had no experience with assuming another manager’s project. This assignment would be a three- to six-month job at a remote location. I would need to be on site in just two days, in order to have transition time with the old project manager. I worried this wouldn’t be enough time to learn everything that I would need to know.
After thinking it over for a night, I accepted the assignment, packed my bags, and arrived on site ready to debrief with the project manager — only to discover the project manager had decided not to return to the site. Thus, my transition time was zero. I focused, instead, on meeting the rest of the team and learned another key piece of the puzzle: There were serious interpersonal and functional issues within the team.
Team members were candid with me — many told me that they didn’t like other people on the team, or they wanted to be working outside their current functional areas. The R&D, engineering, construction, and manufacturing personnel had formed a variety of alliances amongst themselves, and none of these alliances were focused on getting the job completed on time to meet the business need.
By noon on the first day, I knew this was going to be an interesting challenge, to say the least. The good news was that the project files were organized and in good shape and the team members appeared competent. With the clock ticking, I also realized I didn’t have time to train new people. I decided to trust the remaining team members and focus on their strengths while trying to use each hour of every day wisely to build team unity.
I used the first two days to join up with each team member on a one-to-one basis to understand what he or she felt they needed to be successful. I used the information to define an execution strategy to meet the schedule, and then I began trying to break down the interpersonal and functional barriers I had inherited. These join-up meetings were a critical component for me to revise the existing execution strategy. During these meetings I discovered if an individual’s success criteria were different than the team’s success criteria. Even though a person has agreed to the team’s criteria, they may actually be motivated by other criteria, which could negatively impact the project. A one-to-one, face-to-face, join-up meeting was the only way I knew to build solid trust between the project manager and the team members.
I also decided to not look back or focus on what caused the team to become segregated, but to focus on moving forward. Thus, I decided never to utter the words I have heard spoken often by project managers assuming an existing project: “You wouldn’t believe how screwed up this job was when I took over.”
After the first two days it was time to tackle the files to determine the technical scope and see what omissions and cost issues, if any, we were facing. This strategy worked well and by the end of the week the team began to focus on what was needed to meet our timeline. We began a 24/7 work schedule with the project team and construction crew working extended hours. As the days passed, the team began to function better and began to pull together. We even made time for team-building activities, which were viewed positively and continued to sharpen our focus as a working unit.
To make a long story short, we performed a miraculous turnaround, but missed the start-up date by a week. Instead of berating us for not meeting the original schedule, management was elated we came that close — considering where we were six weeks earlier. The team continued to work better and better with one another and, by the time the team disbanded twelve weeks after start-up, it was a very cohesive unit.
This experience taught me something that has been born out over time: A successful transition doesn’t necessarily lie in time spent with the exiting project manager. Don’t get me wrong — that can be a big help. But the success of a transition actually lies in getting to know the people you will be working with, understanding their perceptions of what is and isn’t working, and taking the time to read and analyze existing files to get a flavor of the project as well as the cost, schedule, and technical commitments that have been agreed to or modified over the course of the project.
About the Author
 |
W. Scott Cameron is the Capital Systems Manager for the Food & Beverage Global Business Unit of Procter & Gamble. He is also a regular contributor to ASK Magazine. |
