Project Management Institute

Minnesota Department of Transportation

Delivering projects: the preconstruction phase

Editor's Note: We thank Randy Pearson, Gary Dirlam, and all the others who assisted in preparing this Showcase Project. Included in this team were Doug Differt, Roger Hill, Paula Gustafson, folks in the Office of Computer Aided Services, and the staff in the Office of Highway Programs Implementation. Special mention goes to Neil Kveberg who did the photography and Dennis Moline, “Graphics Wizard par None,” who did the 3-D computer models. It should be noted that the Minnesota Chapter of PMI has enjoyed the active support of MN\DOT through leadership and programs. Douglas H. Differt, Deputy Commissioner has served as Director-at-Large on the Chapter Board and is presently a member of the Chapter Advisory Committee. Roger M. Hill, Director, Office of Technical Support, is presently a Director-at-Large.

This Showcase Project began with a visit to MN\DOT in April 1987. The concepts they were implementing were demonstrated on their CAD system. Later, in June 1987, we had the opportunity to attend the AEC (Architects, Enginneers, Contractors) Show in Washington, D.C. There were CAD systems and PM systems but no evidence of their integration. Our imagination ran wild as we dreamed of a project manager, sitting at a CAD console, planning a project. Instead of drawing a network, however, the PM was building the structure, moving the dirt, or whatever the activity, right there on the CAD CRT screen. Automatically, the system was generating the network diagram that described the plan the PM was using to perform the project, choosing one piece of equipment after another, installing one piece of material after another. It may have been a dream but the MN/DOT capability certainly brings that dream closer to reality.

We commend MN/DOT for its vision, innovativeness, and persistence in developing this exemplary application of modern project management!

Delivering Projects: The Preconstruction Phase

Randall Pearson, Project Management Engineer
Highway Program Implementation Office

WELCOME! We are the Minnesota Department of Transportation (MN/DOT).

Our simple North Star logo shows pride in Minnesota's bountiful natural resources and open spaces. The green represents the state's rich deciduous and coniferous forests while the blue symbolizes our lakes and rivers including nothing less than the headwaters of the Mississippi and the earth's largest freshwater lake, Superior, or Gitchigumi as it was called by Minnesota's original dwellers. MN/DOT's logo also pays homage to Polaris the North Star, a symbol of freedom.

The State of Minnesota was founded in May of 1858 when the major forms of transportation were horse and wagon, riverboat, and train. Many of today's main highway routes were experiencing their beginnings as wagon trails. Minnesota formed its first Highway Department around the turn of the century. The Highway Department officially became the Department of Transportation in 1976, strengthening our authority and ability to service all forms of transportation.

img

MN/DOT

MN/DOT operates through nine districts located across the State of Minnesota. Its headquarters are in the capitol city of St. Paul, where many support units interface with district forces to perform highway preconstruction activities. Figure 1 is an organizational chart which details MN/DOT's structure.

Our overall complement currently stands at approximately 4,500. In each district office we have some 500 full time employees engaged in the project delivery effort. In our Central Office we have an additional 300 people who work on project delivery. The remainder of the complement is involved with contract administration, highway maintenance, personnel functions and other administrative tasks.

Project delivery entails a variety of job descriptions and work skills including design engineers, permit and agreement processors, computer programmers, surveyors, technicians, environmentalists, geotechnical experts, chemists, project managers and a variety of others.

Project management (PM), in MN/DOT, comes under the office of Highway Program Implementation (HPI). HPI was established as a special office by the State Commissioner of Transportation and ranks near the top of the organization. HPI is a relatively small group consisting of the Office Director, an Assistant Director and a staff of four others. This group is the core of MN/DOT's PM effort. The office coordinates the department's entire storehouse of PM information and administers the system which collects, processes and reports all the project management data.

img

In addition to HPI, there is a body of support staff strategically located throughout the MN/DOT. Between 5 and 15 Project Managers are assigned to each of the nine district offices. A MN/DOT Project Manager is an individual responsible for the design of several specific projects at one time.

Project Managers are supported by a PM Coordinator who is responsible for maintaining a district's project information through HPI. District PM personnel are located in the Operations Division while approximately 20 Project Managers in our central office are under the jurisdiction of the Technical Services Division.

At any given time MN/DOT has approximately 1,100 projects in active development for delivery to contract letting. The number of projects that are annually let to contract averages around 300, with about the same number of new projects being programmed into the system each year. This volume of work and rate of turnover necessitates an effective, reliable and readily usable project management system.

A “project”, in our context, is generally a highway construction improvement. This might be a new trunk highway or interstate freeway, a new bridge or the restoration of an existing facility. Although road and bridge design projects are our bailiwick, as a department of “transportation” we also participate in projects involving airports, waterways, railroads and an occasional bicycling facility.

For the most part, each project results in a construction contract, though in some cases more than one project may be combined under a single contract. MN/DOT's project management responsibilities shift from scheduling to administration when a project enters the construction phase.

Background of Project Management in MN/DOT

MN/DOT's roots in PM reach back to some of our first formalized efforts in the late 1950's, when upper management brought in a device which they called a “Sched-U-Graph” system. This consisted of a rather elaborate wall chart with projects listed vertically, and required activities across the horizontal. Colored cards for each project were placed appropriately to identify the progress of an activity at a glance. This system evidently proved useful in its day, but time and technique gave way to a change in our scheduling needs.

MN/DOT's highway preconstruction role has become more complex due to environmental concerns, governmental regulation and increasingly difficult engineering, funding and management decision-making processes. Today, the preconstruction phase is governed by a Work Breakdown Structure (WBS) designed for MN/DOT in the late 1970's. The structure details about 100 activities and 75 functional groups (FG's).

Of the 75 FG's, 40 are actively used in house. The remaining FG's are duplicates reserved for consultants who assist with our work load. Most of the 40 active FG's are located in the central office which controls functions that do not need to be repeated in each district. These include the groups that work in program development, transportation analysis, municipal agreements, environmental affairs, etc.

Six FG's are duplicated in each district: right-of-way, preliminary design, detail design, surveying, traffic engineering and materials engineering. These FG's are duplicated because much of MN/DOT's work revolves around such activities.

MN/DOT's WBS still stands as the foundation of our PM efforts today and is at the center of what we call The Project Management and Scheduling System (PMSS). This system creates a common language necessary to carry out the department's preconstruction activities in a timely, efficient and cost effective manner. PMSS is designed to provide appropriate information for decision making at all levels of MN/DOT's management.

A District Engineer heads each district and represents one of the most important levels of management in MN/DOT. The value of PMSS at that level of management has been addressed by one of our District Engineers as follows:

“In MN/DOT each project is broken into a varying number of activities that are required to move that project from the initial conception through the preconstruction phase to bid letting. PMSS requires input from both the district and central office because both have responsibility in the delivery of any given project. Typically in our district we will have between 80 and 120 active projects running all the way from $50,000 paint jobs on bridges to multimillion dollar freeway interchange projects, so that PMSS itself has to be able to react to a number of different work types and complexities.

At the district level we have six functional group supervisors who meet once each month. They go over each project to determine if there are any problems coming up and if some of the deadlines need shifting. There is also the opportunity for comments about any other concerns that the supervisors may have. These meetings last between one and three hours depending on the complexities that are encountered.

My feeling is that PMSS, as a scheduling and resource tool, has aided both the districts and the central office in keeping our projects on track. I know, in the district, we depend on it heavily and with updating every month we feel that we have a system that is genuinely reflecting where we are in our project delivery process.”

Our system encompasses three broad areas: scheduling, funding and human resource planning. It provides a method for continuous operation of a multi-year, multi-project program planning and control process in which work progress and resource requirements are constantly monitored and related.

The integration of the three areas offers the capability to relate work plans to the availability of financial and human resources. Conversely, resource planning can be accomplished based on the planned construction program. Advantages of the ability to relate resources and projects include:

1. Assuring that the number of projects programmed are within appropriation limits, and

2. Better identifying projects that a preconstruction FG should concentrate on to meet contract letting.

PMSS is oriented to the multi-project environment of MN/DOT, and the design was based on specific needs of our organization. This system, as it stands today, reflects both the formalization and our essential approach to the PM process.

Intergraph System Configuration

Figure 2. Intergraph System Configuration

MN/DOT'S PM Automation History

Prior to the complete installation of PMSS in the late 1970's MN/DOT made a few attempts at maintaining project schedule data on a computer. Our first efforts used a terminal which accessed the University of Minnesota timeshare computer system. It was, at best, a minimal and tenuous connection; but at least it was a link with automation. MN/DOT's top officials at the time recognized the need to maintain and develop our automation capacity.

Initially, PMSS featured on-line inquiry and schedule updating using 16 high speed terminals dedicated to PM functions. The system, as a whole, served us well for about 10 years. But the software coding, in COBOL and Assembly languages, showed itself, over time, to be lacking in flexibility and responsiveness. Any modifications to the system required time consuming and expensive rewriting of code.

Massive changes in central computer technology were making our on-line PMSS program obsolete. We were faced with greater expectations for using historical data, an emphasis on critical path techniques, and a major rewrite of the system to run under a standard on-line system. We found ourselves at a crossroad.

MN/DOT had been successful in automating PMSS and we were satisfied that our WBS was conceptually sound. We realized that hardware technology was adequate and that PMSS was functioning well, but our software problem needed to be addressed.

In 1986, after evaluating software alternatives, MN/DOT selected the ARTEMIS (TM) system. To translate our PM and Scheduling System into Artemis, the contract included training for key people and consultant programming assistance. Two years later, we continue to develop and program applications which enhance and expand our PM capabilities. Our system is now providing the flexibility which users require, and offers much promise for the future.

Current Automation Status

MN/DOT has endeavored to secure effective levels of equipment, training and support to allow us to process, format and present accurate information about the projects we develop, design and produce.

Since the department's first exposure to computers, we have been able to grow in both understanding and ownership of a variety of software and hardware technologies. A substantial inventory of both mainframe and microcomputers is used in our organization. The mainframes operate throughout the State for a number of purposes including scheduling, cost accounting, plan sheet production, mapping, graphics and much more. Figure 2 represents MN/DOT's VAX mainframe inventory and the computer aided design and drafting workstations that function through them.

This is an example of just one dimension in our automation profile. We have parallel mainframe computer support in processing design and survey computations, transportation information, interoffice information, and PM information. MN/DOT's automation today provides valid production with tangible benefits.

Using Automated Resources

The majority of MN/DOT's automated resources are applied to program delivery - getting the projects to letting. But a portion is allocated strictly for PMSS. HPI has also been able, in certain cases, to tap into resources used for program delivery. The automated resources have allowed us to offer better PM service within the organization, which we continue to fine tune. Additional benefits result from applying these resources to respond to a larger arena of clients outside our organization.

MN/DOT's external clients include cities, municipalities, counties, the Federal Highway Administration and, most importantly, the public. Each has specific input and a need to be informed. Interaction comes in the form of regular inter-office correspondence, planning meetings, opportunities for public hearings and more. Client concerns range from funding allocations and fiscal responsibility to location designs and right-of-way acquisitions. Participation of these groups comes at various points in the project development process, requiring that we account for delivery of our projects in an almost “gymnastic” way.

The PMSS system has enhanced our ability to answer questions relating to activities, funding, manpower and equipment necessary for successful project completion. The challenge lies in providing information from each of the automated systems, and in combining different systems to present parallel, supporting and meaningful data beyond the usual host of schedule, cost and manpower reports. The product is configurations that command attention and communicate quickly and cleanly. Combining of systems attests to our goal of achieving an integrated project management system.

The major difficulty in integrating systems is interfacing, and that includes both hardware and software. This is the point at which project management yields to the science of computer technology. These technological efforts are not always guaranteed to be successful or easy. Coordinating sets of data from two or more products can be a resource intensive process.

Interfacing computer equipment is a significant concern and an area not necessarily well understood by all Project Managers. Many components and products fit together with interfacing equipment, and the complexity can seem like a virtual “hornet's nest” of confusion. We contend with differing operating systems, software interface routines, PC/Mainframe communications, work station configurations, send and receive options, data structure, format processing, controller hookups, plotters, and so on. Detailed knowledge of this process is not inherently required of a Project Manager, however, awareness of the presence of these factors is mandatory. This responsibility simply comes with the territory of an automated/integrated project management system.

In MN/DOT, awareness of automation components is even more important because of the variety of equipment we have available in-house. To better meet the needs of various applications, we have purchased products from many vendors creating a very diverse (and we hope strong) base of automated resources. It has also left us with an implied responsibility to work toward our goals through this variety of automated devices.

This diversity is not unique to MN/DOT. Many large organizations have accumulated a variety of makes, models and brands of computer equipment. There simply is no single, comprehensive solution to the predicament of tieing all that variation into a cohesive unit. Each need breeds its own special solution. And it is here, among the maze of technological interconnections, that a Project Manager might find subtle snags to delivering top notch PM information.

MN/DOT EXAMPLES OF PM AUTOMATION

Metro Area Construction Map

One of the first hybrid products used for PM purposes was the “MN/DOT METRO CONSTRUCTION MAP”. An example is displayed in Figure 3. It was developed by one of our graduate engineers in 1986 and combines PMSS data with the graphic capabilities of the Intergraph CAD system. The map itself covers the Twin Cities of Minneapolis and St. Paul along with surrounding communities. On average, there are between 40 and 60 major transportation construction projects in the Twin Cities metro area each year. Our construction map displays traffic delay information about these projects.

The base map comes from our database where we store digitized map information for the entire state. We simply use that portion of the data which suits our needs and place it at an active level in the memory storage. With this data in place, we use another active level to designate the specific construction locations. The map's annotation includes numbering codes, project limits and expected traffic delay, along with the titles and legends. That comprises the graphical portion of the construction map.

MN/DOT Metro Construction Map

Figure 3. MN/DOT Metro Construction Map

The next step is to gather and format specific project information, including highway number, construction start and finish dates, work description, and expected traffic delay. All project information is stored in our PMSS database, and this is translated and transported into the graphics file through a FORTRAN routine. After the project information data has been merged, the graphic file is plotted to yield the final product.

As a result of this process, the map is a very effective communication and management tool. It is used in meetings with entities outside of MN/DOT including affected cities and counties. The map is used to make decisions about scheduling and coordinating associated construction projects. Working together, they can minimize the negative impact of congesting an area with too much disruptive activity. The metro map, as a visual tool, works very well in these situations.

Governmental agencies aside, there is also the public's need to be informed about the construction season. The map, and its information, is turned over to the local papers so they can publish a facsimile for public benefit. We supply copies to the MN/DOT district offices that are responsible for construction in the metro area. We also send copies to our executive offices as an easy reference for the upper level managers.

The Metro Construction Map has become a tool with proven value to our PM effort both within MN/DOT and our contacts outside of the organization.

Corridor Management

The concept of “corridor management” resulted from a need to perform major reconstruction on large portions of the Twin Cities metro area's interstate freeway system. This reconstruction poses a different set of circumstances than those present when the interstate system was originally built. Initial construction of the highway meant new alignment through essentially virgin territory. Of course there were many concerns involved, such as environmental issues, right-of-way acquisitions, etc., but one thing it did not involve was average daily traffic counts of the hundreds of thousands of vehicles. Twenty-five years ago, there was no traffic because there was no system. Today, the corridor concept has evolved through the necessity of having to perform large scale reconstruction under heavy volumes of live traffic.

For our purposes, a corridor tends to be a stretch of freeway from 5 to 15 miles in length, including entrances, exits, separated grade crossings, and interchanges. In this type of situation, the reconstruction work is scheduled to be funded over a specified number of years. Corridors take on justifiable importance when consideration is given to the cost of the work done. A single corridor can account for 10 to 15 percent of MN/DOT's annual budget for each of the years it is active. We must also consider the cost of inconvenience to the motoring public in terms of time delays and fuel idled away in traffic jams. These considerations, plus less quantifiable “driver stress,” make it essential for us to carefully regard the way we manage these reconstruction projects.

Once a corridor has been identified and defined, the next step is to determine the number and types of projects required. This can be a substantial task when faced with the need to coordinate as many as 50 to 100 projects to complete the work in one corridor.

Detailing this work is a complex process. Large quantities of information must be organized in order to segregate the work types, design requirements, and funding allocations that define he scope of individual projects.

To facilitate this scoping process, we have developed an application similar to the one used for the construction map. Again, we start with a base map of a specific corridor and overlay segments of relevant data ranging from structure type and location to contract dollar amount and anticipated project letting dates. Different versions of the base map may include the number of working days and scheduled dates for construction work on the various projects.

The corridor map enables Project Managers to gain a clear picture of work flow over time and also offers them a forum to express the logical sequencing and staging of projects.

It is here that the graphic model begins servicing the project rather than being serviced by it. It can be used to present, in essence, an accurate visual snap shot of scheduled project progress at any point in time.

This allows the large number of projects involved in a corridor to be organized so that priorities can be assigned. In this way, the design for grading projects is completed in coordination with the design of surfacing projects and then to design of the finishing projects such as signing, lighting landscaping and noise abatement. In effect, we use the corridor map to manage the coordination of the “big picture” and allow management decisions to flow down to the finer degrees of scheduling. In the end, the project delivery process is initiated with qualified and realistic schedules.

An example of the corridor management application is found in Figure 4. This example details the corridor between the city centers of Minneapolis and St. Paul along Interstate 94. This is a corridor that is both complex and politically sensitive. I-94 is the central artery of the metropolitan highway system and work is highly public, reflecting directly on MN/DOT. Also, numerous road and bridge designs must be completed in order to perform the reconstruction within a maximum of four construction seasons.

To further complicate the situation, this corridor is located in two MN/DOT districts, two cities, and two counties, magnifying the difficulty of coordinating and approving a multitude of project considerations. All these factors combine to make use of the strongest PM tools available to MN/DOT.

What we have shown specifically in Figure 4 is a version of the corridor map which displays the state projects that are scheduled for letting under Stage One. These projects include a major grade and surface job on each of four segments along the corridor. Also shown are the bridges that will be affected in segments one and three during Stage One. Those contracts being let first will be constructed in 1989. In total, there will be five stages of contract lettings over the course of the next three years to complete the work slated on I-94.

In cases like this it is important to use all the PM tools at our disposal; tried and true, old and new. Those include not only the full capability of our PMSS system but also efforts such as the corridor and construction maps. The benefit is realized when these products facilitate the decision-making process.

We are now using captured data in a way that was not nearly as convenient prior to the availability of our automated graphics. The PMSS system has, from the beginning, held the data which defines the attributes of any stretch of road, be it a corridor or a point location. But our ability to report and configure that information into new and more meaningful forms has been increased through the growth in automation.

In an effort to enhance corridor management, MN/DOT's Computer Aided Engineering Services section is working on a series of user commands that operate through a data retrieval system. This will lead to a menu driven front end to the application so that it will become easier to use for a larger number of people. This again is an example of making use of interfacing routines which tie our project data to our graphic data for the sake of cleaner and more versatile information presentation.

Management of an Individual Project Design

The preceding discussions have been focused on MN/DOT's multi-project environment and using our management tools to help deliver those design projects. But there are occasions when a single project will take on importance for reasons of public sensitivity, environmental impact, historical significance, or political reasons. In such cases, many resources are called to bear on the final outcome of the project. These may include automated engineering, professional and technical manpower, and monetary resources as well as PM resources.

img
Management of an Individual Project Design

Figure 5 Management of an Individual Project Design

Under these conditions, the need for project control is met by relying on the elements of our WBS with its 100 activities and the supporting FG's. Herein, the specific project is given careful consideration as to the schedule of required design activities along with the assignment of participating FG's. Activities are networked and a letting date targeted. The network is then analyzed to render a schedule and critical path for the project and forces are set in motion to monitor and track its development through the design phase. All projects receive the CPM treatment, but tracking is closer and more pronounced on these special or “hot” projects.

Tracking through the design phase in MN/DOT can be a fairly detailed process, especially on large scale projects. And special projects tend to be large scale.

These projects generally entail about 30 to 40 activities for tasks like preliminary design mapping, geometric layouts, right-of-way process, detail design, plan specifications and estimates, bridge design, agreements, permits, and environmental impact statements. As each of these activities is completed, the project takes conceptual shape on plan sheets. But today, with the tools of automation, plan sheets are not always enough. Recently, there have been some projects which have been conceptualized not only on the plan sheets, but also in the form of three dimensional computer models.

In Figure 5, we have a somewhat abstract, but still accurate, representation of a recent special project. This figure shows a precedence network diagram, with critical path, reflecting off of a schedule report and projecting forward into a 3-D computer model which resulted from combining information generated as scheduled activities were completed.

The reality of Figure 5 is expressed in the fact that we employ CPM scheduling techniques on every project designed in MN/DOT. We also make full use of the activity schedule reports in project review meetings. In this way, the schedules (for all projects) are tracked and monitored; usually resulting in the timely completion of the various activities. In this particular case we carried the project development and management process one step further and developed the 3-D computer model.

The first step was to electronically transfer relevant United States Geologic Survey (USGS) data into a graphics file. This defined the basic topography of the crossing site. From here we began tying in information generated from the scheduled activities for the project as they were completed. This information comes in various forms such as Control Survey work which sets the horizontal and vertical control for the project site and ties in directly with the USGS data. Next Bridge Surveys and Design Surveys are completed. This supports the USGS and Control Survey information and fine tunes the exact alignment of the project location as well as defines specific horizontal and vertical curvatures.

A CAD drawing of the Stillwater Crossing

Figure 6 A CAD drawing of the Stillwater Crossing

With this information now digitized into a computer model, the product of several other schedule activities can be incorporated. Activities like Preliminary Design Mapping, Bridge Design and Detail Design contribute data regarding road width, structure height and other engineering detail.

A primary concern for transportation projects is environmental impacts. Accounting for these impacts can be a Federal requirement in the form of producing draft and final Environmental Impact Statements. Completion of these statements also happens to be scheduled project activities in our WBS. The computer model can facilitate these activities.

It is here that the graphic model begins servicing the project schedule rather than being serviced by it. It can also be used to present, in essence, an accurate visual snap shot of scheduled project progress at any point in time.

Even though our efforts in three dimensional modeling are in their infancy we feel there is tremendous value in this approach to handling project information. The potential lies far beyond the notion of determining the visual impact of a finished project. The potential exists in using these models as a means of automatically calculating amounts of material used for a project, which in turn translates into estimates of manpower required. Both of these translate in to dollar values contributing to the overall cost of a project.

PM Automation Benefits

Exploring and using PM automation for MN/DOT has resulted in a strengthened PM base. More people, both inside and outside the organization, have been reached using techniques in automation to present project information stored in PMSS.

Automation has allowed us to find better and more effective ways and means to present our PM information. Our progress has exposed project management as a valid and valuable tool to a larger audience of people, which, in turn, has generated more widespread interest in PMSS. Interest in the system translates into stronger support in terms of feedback, input, and updating from system users.

One of the more exciting aspects of investigating PM automation, is that the area is still wide open. Very little stands in the way of this exploration. It has been our experience in MN/DOT that people's ideas are the greatest source of direction in using automation to improve and expand project management. Surprisingly, most of the ideas are not the product of formal brainstorming sessions or meetings, but rather, as a result of seeing a tool at work performing one task and transposing it toward a different end.

Another source of ideas comes from staff without strong automation background but who know what they need. These individuals will come to our office in HPI and ask if we can gather information into a particular format. This scenario is a fairly natural occurrence because a Project Manager is bombarded with a great deal of information from a number of different sources. It is completely understandable that an individual will want to take bits and pieces from various systems and have them combined into one report, or one graphic.

Regardless of where our ideas come from, HPI is almost invariably called on to get them off the ground. Thus, we have the responsibility of pursuing the connections required to produce the end product. This, again, is where the multiplicity in variation of automation products tests the true integration of MN/DOT's PM system. We are still in an experimental stage, testing our equipment as well as our ability.

The Difficulties

Testing the limits of MN/DOT's PM automation capabilities often illuminates problems which must be overcome. Those of us who understand PM must learn more about automated technology. And of course, those who understand the technology usually have very little background in project management. It is not necessarily the blind leading the blind, but sometimes it can seem that way.

Other difficulties come in the form of training needs and productivity gaps. Often, the time spent working toward a goal means time spent learning but not producing. The value of training is well recognized in MN/DOT. We realize the training usually comes at a certain cost of productivity, but we view the production gap as temporary while the value of training is valid in the long run.

Another difficulty with automation is the changing nature of equipment and software. Sometimes it seems that as soon as a system is set up to perform a function one way, you learn it can be done faster (and better) another way. However, faster and better does not necessarily mean cheaper. It then becomes a point of economics. Once an application is working, it is not always worth it to push for a “crisper” line on a graphic, or reducing CPU time by fractions of a second. There is definitely a diminishing rate of return.

At MN/DOT we do have a fairly strong base in automation technology, but that base is by no means complete. It will never be final due to the growth which lies ahead for both PM and automation technology. The best we can hope for is simply keeping up.

In MN/DOT, keeping up means using computers as much as possible where available. It also means that we still carry the bulk of our load manually. But we believe that we are going in the right direction with our pursuit of automation.

Visions for the Future

The facts are quite easy to see. Technology will continue to grow and develop. The means of using that technology in the field of project management will also continue to grow.

As Project Managers, we must not be shy about embracing technological growth. We must remain cognizant of the availability and expansion of information that is stored electronically. Information will continue to be a key management resource. Technology must work in concert with available information to enhance a project manager's ability to get relevant data in a more concise form.

These are the horizons that lie ahead. The age of automation offers an open end of opportunity and challenge to those of us who pursue the artful science of project management. Spurred on by the need to provide required information, we must learn by investigation to find use for the automated tools at hand. We must also keep looking forward to sharpen our skills and shape the direction of our profession.

img

Randy Pearson is a Project Management Engineer in MN/DOT. He works in the Office of Highway Program Implementation facilitating the department's project management needs. Pearson is a registered Civil Engineer in the state of Minnesota. He is an avid runner and bicyclist and loves to travel. In fact, he plans an extensive vacation during 1989, including visiting Australia, Thailand, and the United Kingdom. Anyone interested in meeting him on this trip should contact him at MN/DOT asap.

Note: Artemis (TM) is a trademark of Metier Management. IGDS (TM) is a trademark of Intergraph Limited.

img

A View of Construction in MN/DOT Management

Gary Dirlan, Pre-Letting Engineer
District 3, Brainard

The purpose of this article is to share with other Project Management professionals the experience of one Project Engineer within the Minnesota Department of Transportation (MN/DOT). MN/DOT has been studying the benefits of increased utilization of the critical path method of scheduling for PM on highway construction projects.

MN/DOT designs most of its own plans and puts together specifications for highway and bridge construction contracts. MN/DOT also has responsibility for the maintenance of over 12,000 miles of highway plus numerous other transportation related functions. After a contract has been prepared, MN/DOT holds a bid letting process wherein the low bid contractor is determined. The low bid contractor is then evaluated to verify proper bonding and insurance status. The contract is then awarded and the construction process begins.

A basic philosophy within MN/DOT is that the low bid contractor knows best how to schedule their construction operations. Therefore MN/DOT does not set the schedule for construction activities. However, we do require the contractor to provide us with their schedule. In this way MN/DOT has an understanding of the contractor's schedule of operations.

Scheduling of Two Construction Projects

The first project was constructing a concrete surfaced highway that entailed five miles of new alignment. This 4.5 million dollar project was basically a two lane, two way road.

This contract required a standard schedule barchart which is part of MN/DOT's specifications. This barchart required only major activities to be performed during the working days specified in the contract. Under the contract, a major activity was defined as an item whose cost was 5% of the overall contract cost. Therefore, any item that cost more than $225,000 needed to be shown on the barchart. Only 10 individual items met this qualification, so the barchart contained only those 10 different items.

The project was such that the overall work was serial: one subcontractor started placing pipe for drainage; when this work was almost 100% complete, the grading contractor started moving dirt which allowed another subcontractor to start hauling in granular material. Moving dirt and hauling in granular material were the only two activities done simultaneously to any extent.

The project management on this type of project was not elaborate. The subcontractors would check with the prime contractor or wait for the prime contractor to call them and inform them when their services would be required on the project.

While this project had been scheduled to be completed in one construction season, it was eventually completed in one and a half. This was attributed to an increase in the required quantity of granular material, and wet weather. Contract changes were made to increase the efficiency of the contractor. However, the changes did compensate for the delays due to weather. With only a single barchart to actually gauge the construction operations, delays caused by weather and other factors were not readily apparent.

One should keep in perspective that MN/DOT, as an owner, has a slightly different motivation than private enterprise. Private enterprise tends to have monetary profit as its primary motivation. As a public agency, MN/DOT cannot go out of business. Therefore, our motivation is more strongly developed by our charge to provide safe and efficient transportation.

The second project was a 9.5 million dollar flood control project for the U.S. Army Corps of Engineers (COE). MN/DOT was under contract with the COE to raise T.H. 169 at the western edge of Mankato, Minnesota. Flood walls will be constructed. New bridges are being built to span the walls and the Blue Earth River. This project is less than one mile long, relatively small for the 9.5 million dollar cost.

The variety of work involved on this project required close cooperation between the prime contractor and subcontractors. One contractor had to put in the sewer and water utilities. The contractor's grading crew then put in the granular backfill; and finally a subcontractor placed a bituminous cover to finish the by-pass. Opening of the bypass by winter was a critical deadline. On this project the construction activities were networked and a critical path was determined. Many project personnel were skeptical of making the deadlines shown within the critical path. Some of the smaller tasks were missed, but for major tasks the schedule held true.

The historical experience of the Project Managers on this project was stronger in some areas than others. Therefore, a better aggregate estimate in those areas was possible. The project also had weekly meetings of the contractors involved over the life of the project. These meetings helped overcome many problems caused by minor slippage of the schedule.

In the case of this project it can be said that the critical path, and visualization of the path with barcharts, proved to facilitate the construction of this intricate project. There had been delays caused by forces outside the realm of the schedule which forced the contractor to review the schedule and respond to the problems. At the time of this writing the project is on schedule to make the second year's winter deadline.

In summary, the utilization of the critical path method for scheduling construction projects in MN/DOT is viable. Usage of CPM in the construction phase has and will continue to increase as MN/DOT personnel become more comfortable using this management tool MN/DOT Project Managers understand the claims for benefits/advantages and are looking forward to seeing more of the fruits of this approach to project management in the area of construction.

*         *         *

Gary Dirlam is a registered civil engineer in the State of Minnesota. Dirlam has worked for MN/DOT in the offices of project management, construction and detailed design. He received the Minnesota Government Engineers Council “Young Engineer of the Year” award in 1984.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.

THE PM NETWORK November 1988

Advertisement

Advertisement

Related Content

  • The Innovation Imperative Pulse In-Depth report cover

    The Innovation Imperative

    Organizations must invest in building a culture - and project teams - that can turn cutting-edge ideas into reality, according to new PMI research.

  • Project Management Journal

    Thinly and Thickly Capitalized Projects member content locked

    By Styhre, Alexander In the contemporary economy, finance industry interests and finance theory propositions increasingly determine investment behavior. Project management scholars access conceptual frameworks and…

  • Project Management Journal

    Project Studies Beyond the Straitjacket member content locked

    By Jacobsson, Mattias | Söderholm, Anders This article provides insights into ways in which project studies can be extended to make further impact on and contributions to other research domains, including more general management and…

  • Project Management Journal

    We Are Projects member content locked

    By Carlsen, Arne | Pitsis, Tyrone S. Research on projects has to a limited degree taken issue with how projects are chief producers of meaning at work. We develop the concept of narrative capital as a basic mechanism for how people can…

Advertisement