When TransCanada acquired American NaturalResources Co. of the U.S.A., they were facedwith the problem of integrating 21,000 miles ofAmerican’s natural gas pipelines with their ownCanadian system within a 2-year time frame. Differentpipeline regulatory procedures between thetwo countries meant establishing new processes andgovernance procedures to certify the integrity of thecomplete network. The project team consisted of 14engineers and one software manager, each with theirown sub-teams to integrate the pipelines. The projectstarted with a big Gantt chart for task scheduling, butsince the team wasn’t fully dedicated to this projectand still had their normal responsibilities, task duedates often were not met. In addition, as the teamacquired more data, the project parameters and scopekept changing. To respond to these constant changes,the project team moved toward a more agile managementprocess.Although they didn’t adopt all the tools of agile,they did make use of some that were especiallyneeded for this project. For example, there weredaily 15-minute sub-team “stand-ups” (less talkingwhen no chairs), and weekly meetings with theentire project team. This gave the workers the latestinformation on changes, problems, manpower availability,priorities, and other information to identifyand solve roadblocks. The meetings promoted theneeded inter-communication to keep the projectmoving while adapting to the constant changes.From time to time we have mentioned the fact that software and IT projects have hada very high failure rate—over budget, over schedule, and delivering less than the desiredoutput. When compared to construction projects, for example, software projects are characterizedby a much higher degree of uncertainty about the exact nature of the desired output,and often by a client (user) who does not understand the complexity of the projects and lacksthe knowledge to communicate fully with the project team. The result, understandably, has ahigh probability of client dissatisfaction with the completed project. (Much of the followingdescription is based on Hass, 2007.)The major source of the problem appears to be the complexity of modern businessorganizations. They are involved in complex relationships with each other, with multiplegovernments and external stakeholders, with customers, with suppliers, and operate in anenvironment of rapid technological change and intense global competition. Their need forcomplex information systems is a result of the complexity in which they operate.Agile Project Management (APM) was developed to deal more effectively with this problem.It is distinguished by close and continuing contact between clients (users) and softwaredevelopers, and an iterative and adaptive planning process. Project requirements are a resultof client/developer interaction, and the requirements change as the interaction leads to a betterunderstanding on both sides of the project requirements, priorities, and limitations.Agile IT project teams are typically small, located at a single site, composed of a PM, theclient/end user, an IT architect, two code writers, and a business analyst in the client’s industry.Project team membership will, of course, vary with the nature of the project’s deliverables. Asnoted above, the group develops the project requirements and priorities. One requirement isselected, usually the highest value or priority or most complex item, and the team tackles thatitem. The resulting output is tested by a test case developed as the requirement is develope The entire team collaborates in dealing with the requirements. The PM’s role is to “facilitate”rather than to “control” the process

To track actual progress, the project managercreated a high-level list of the project’s tasks and,because he could trust the skill of the senior engineeringsub-task managers, then regularly updatedthe amount of hours left to complete each of thetasks (note: not hours put in). Such daily reportinghelped the sub-teams keep their focus on the resultswhile aware of the daily changes that might affectthem. This constant updating of information camein handy when the project was thrown off scheduleby a vendor delay, but the ability of the project managerto alert the project’s stakeholders far in advancewas positively received. Even though the projectran late, management was nevertheless pleased toknow about the problem far ahead of time and whyit occurred.The project manager here pointed out that agileis simply a way to deal with projects that are inconstant fl ux by shortening the feedback loops andkeeping everyone apprised of changes so they cancoordinate their efforts. Thus, it is best for organizationsworking in dynamic, turbulent environments.It isn’t particularly useful on projects with standardprocesses for completing them (like building a newpipeline), or with a project team that has workerswho are inexperienced, unskilled, or unfamiliar witheach other. The team needs to be able to trust thejudgment of each of its members, and be able to collaborateand coordinate with them.

1. The text mention that in an It project, the client or a representative of the client is a member of the team. why was that not done here?
2. What aspects of agile (APM) were and were not used here?
3. What might be some problems with using agile for a standard project, or one with standard processes?