Using Agile to Integrate Two Gas Pipeline Systems
When TransCanada acquired American Natural Resources Co. of the U.S.A., they were faced with the problem of integrating 21,000 miles of American’s natural gas pipelines with their own Canadian system within a 2-year time frame. Different pipeline regulatory procedures between the two countries meant establishing new processes and governance procedures to certify the integrity of the complete network. The project team consisted of 14 engineers and one software manager, each with their own sub-teams to integrate the pipelines. The project started with a big Gantt chart for task scheduling, but since the team wasn’t fully dedicated to this project and still had their normal responsibilities, task due dates often were not met. In addition, as the team acquired more data, the project parameters and scope kept changing. To respond to these constant changes, the project team moved toward a more agile management process.
Although they didn’t adopt all the tools of agile, they did make use of some that were especially needed for this project. For example, there were daily 15-minute sub-team “stand-ups” (less talking when no chairs), and weekly meetings with the entire project team. This gave the workers the latest information on changes, problems, manpower availability, priorities, and other information to identify and solve roadblocks. The meetings promoted the needed inter-communication to keep the project moving while adapting to the constant changes.
To track actual progress, the project manager created a high-level list of the project’s tasks and, because he could trust the skill of the senior engineering sub-task managers, then regularly updated the amount of hours left to complete each of the tasks (note: not hours put in). Such daily reporting helped the sub-teams keep their focus on the results while aware of the daily changes that might affect them. This constant updating of information came in handy when the project was thrown off schedule by a vendor delay, but the ability of the project manager to alert the project’s stakeholders far in advance was positively received. Even though the project ran late, management was nevertheless pleased to know about the problem far ahead of time and why it occurred.
The project manager here pointed out that agile is simply a way to deal with projects that are in constant flux by shortening the feedback loops and keeping everyone apprised of changes so they can coordinate their efforts. Thus, it is best for organizations working in dynamic, turbulent environments. It isn’t particularly useful on projects with standard processes for completing them (like building a new pipeline), or with a project team that has workers who are inexperienced, unskilled, or unfamiliar with each other. The team needs to be able to trust the judgment of each of its members, and be able to collaborate and coordinate with them.
Questions :
- In an Agile project, the client or a representative of the client is a member of the team. Why was that not done here?
- What aspects of agile (APM) were and were not used here?
- What might be some problems with using agile for a standard project, or one with standard processes?
Source: C. Hildebrand, “The Sweet Spot,” PM Network, Vol. 24.
