With 30 years' experience in grain handling, we were very confident of our ablity to manage a complete automation retrofit at a large grain ship loading facility. We knew several things were not well defined at proposal time, but time was short and our workload was high, so we kicked off the project without digging into the issues. Some of what we missed only came to light in the client's user acceptance test, when they informed us the system would not work as designed. This meant we had to go back and rewrite a significant portion of programming code to make it work. As a result, start-up was delayed several months and staff hours rose. All of these problems could have been avoided by getting one of the key pieces of project management correct: effective communication.
In the design-build project delivery world, having perfect information going into a project is an elusive goal. And during the project, integrators have to perform just-in-time design to stay ahead of construction teams, while recognizing that details are still being firmed up by the various engineering teams. Knowing that this level of change is inevitable puts the project manager in a scope- and risk-management role right from the start.
Communication and relationships are what determine how the people involved will respond to those changes. Even if you hammer out every detail in a kick-off meeting, you still won't know how people will respond to project scope creep. And what do you do when what the client changes his mind about what he wants and, in the process, creates more risk?
With situations like these being commonplace to project management, you have to have a game plan for handling new information that comes to light after months of work based on incomplete information.
I have found it helpful to use kick-off meetings to find commonalities and points of agreement with the client. I try to get a feel for their degree of reactivity and response when discussing potential risk. I want to know which people have the answers we need and how I can build in access to those people, especially if I need to go through another contractor or process engineer. I will not be told I didn't communicate enough in a project. It has to be a top priority of my job as project manager.
We decide at the kick-off meeting what we will do and what roles people will play when scope creep happens or timelines change. We write proposals relying on our experience with comparable projects, existing client relationships, and understanding of our own strengths. We remind ourselves that we are always learning, that we simply don't know how much we don't know about this client or this project. We try to communicate in real time when things change and make sure that our communication will keep the relationship healthy over time.
At the end of hte project comes feedback. This is when we ask ourselves and others what we did correctly, what went wrong, and how that can happen more smoothly so we can improve.
There are tools that help with this. We use templates to make sure all the details are covered and that we are asking relevant questions. We complete reports and get scheduled responses from other players along the way to make sure we're all still on the same page and everyone knows what has to happen next or why it isn't going to happen. When the work is done, we measure results and test processes and ask the client for their judgment on how things happened. We don't begin a project from scratch, but we do know that our tools only help us construct an initial framework; they don't tell us what the end result will look like.
Jeff Miller is director of project management at Interstates Control Systems Inc., a Certified member of the Control System Integrators Association.
