Phases of a Construction Project Life Cycle – Part 2

In Part 2 we’ll continue to look at the phases of a construction project as laid out in F. Lawrence Bennett’s book entitled “The Management of Construction – A Project Lifecycle Approach.” In this article, we’ll see how Mr. Bennett desribes the pre-project, planning, and design phases.

As I’ve already mentioned, I find this interesting as my experience has been almost exclusively with software development projects. If any of our PM readers are in the construction industry, I’d enjoy hearing your feedback and perspective.

Pre-project phase

A construction project begins with an idea, a perceived need, a desire to improve or add to productive capacity or the wish for more efficient provision of some public service. Whether the idea will be converted into a completed project will be decided during the planning and design phase. However, prior to that, among the first things the owner must do is to decide what sort of project delivery system will be used. How will the various parties be related? Will the owner engage a design professional to prepare plans and specifications and then contract separately with a construction contractor? Or, will a single entity be responsible for the entire project? Other possible options include several separate specialty contractors, each related by contract with the owner, the use of a construction manager as an advisor to the owner, the use of the owner’s own construction forces and the phasing of the project such that individual portions of the field work are commenced prior to the completion of all design work.

The other primary decision required by the owner early in the project relates to the type of contract to be used with the contractor. Will the contractor be paid a specified fixed price, regardless of the actual quantities used in the project and regardless of the contractor’s actual costs? Will the quantities of materials be measured and the contractor paid on the basis of those quantities and pre-agreed-upon unit prices for each material? Or, will the contractor be reimbursed for its actual costs, plus a fee, perhaps with an agreed-upon upper limit? The owner will also need to decide the basis upon which the design professional will be paid. Often these decisions are not made without consultation and advice. Depending upon the owner’s expertise and experience in administering construction contracts, the owner may engage a professional engineer, an architect or a project manager during this pre-project phase to advise on these important decisions.

Planning and design phase

The project is fully defined and made ready for contractor selection and deployment during the planning and design phase. It is convenient to divide this phase into three stages. The goal of the first stage is to define the project’s objectives, consider alternative ways to attain those objectives and ascertain whether the project is financially feasible. In this process of planning and feasibility study, a project brief will be developed, more details will be set forth in a program statement, various sites may be investigated, public input may be sought, a preliminary cost estimate will be prepared, funding sources will be identified and a final decision on whether to proceed with the project will be rendered.

In the second stage, the design professional will use the results of the planning efforts to develop schematic diagrams showing the relationships among the various project components, followed by detailed design of the structural, electrical and other systems. This latter activity is the classical hard core engineering familiar to students in the design professions, in which various engineering principles are used to estimate loads and other requirements, select materials, determine component sizes and configurations and assure that each element is proper in relation to other elements. The output from this design development effort is used in the final stage, wherein contract documents are prepared for use in contractor selection and installation work at the construction site. The design professional prepares not only the detailed construction drawings but also written contract conditions containing legal requirements, technical specifications stipulating the materials and the manner in which they shall be installed and a set of other documents related to the process of selecting the contractor and finalising the contract with the successful tenderer.

Next

In Part 3 we’ll look at Mr. Bennett’s description of the contractor selection and project mobilization phases.

Phases of a Construction Project Life Cycle – Part 1

Having almost exclusively only dealt with and led IT software projects throughout my career, I’ve always been intrigued by the area of construction project management. Though with my background, getting in the door – even on a consulting basis – to gain that experience just hasn’t happened or the timing was just never right – either in the Midwest or in Las Vegas during the housing boom.

So running across F. Lawrence Bennett’s book entitled “The Management of Construction – A Project Lifecycle Approach” peaked my interest. I’ve written about project lifecycle and methodology phases at great lengths in my articles and would like to present here Mr. Bennett’s parallel segments on the construction project lifecycle. Due to the length of the material, this will likely need to be shared over multiple parts starting with his general overview for the purpose of this article. The following text was derived from Mr. Bennett’s Management of Construction book.

Overview

Every project, not just those in the construction industry, goes through a series of identifiable phases, wherein it is ‘born’, it matures, it carries through to old age and it ‘expires’. A software development project manager, for example, might define the following phases in the project’s life cycle: initial proposal, process engineering – requirements analysis, process engineering – specifications, design, development, testing, deployment and support. Likewise, a project that results in the development of a new product might contain the following phases: conceptual, technical feasibility, development, commercial validation and production preparation, full-scale production and product support. Although there may be some overlap in the phases, the work generally flows from the first phase to the last, with the outcome of one phase providing the basis for efforts carried out in the phase that follows.

So it is also with construction projects. We will be identifying six phases in the construction project life cycle, each with its own purposes and characteristics. First, the owner must make certain pre-project decisions. Then the planning and design of the project is carried out. Next, the contractor is selected, after which the contractor mobilizes in order to carry out the field operations. The field work that the lay person often considers to be ‘construction’ can be considered a separate phase. Lastly, the project must be terminated and brought to a close; because these activities are distinct from the installation work, we separate them into a distinct, final phase.

To attempt to understand the management of construction by organizing the study on the basis of the project life cycle may be somewhat arbitrary, because there is admittedly some overlap between phases and thus some duplication in the presentation. However, this deliberate design of this text will provide a logical basis for tracking the project’s activities and understanding the roles of the people responsible for those activities, from the time the owner first conceives the idea for a construction project until that point when the contractor has vacated the site for the final time.

Structured in this way, each section provides a description of one of the project’s phases. The result should be an understanding not only of the importance of each phase individually but also of the way they interrelate to form an integrated whole project.

In Part 2, we will present an overview of each of the six phases of the construction project life cycle.

A Project Management Historical Timeline

While reviewing my latest copy of Project Manager Today – a UK-based PM magazine – I was reading their article entitled “A Profession is Born” which looks back on the 20-year history of the publication. Included in the article is a timeline of some key points in project management history – though with a very UK twist to it.

I decided to put together a more all-inclusive timeline by grabbing some info from Wikipedia and whatever other sources I could find.  The resulting timeline follows – I hope you find it as interesting as I did. If you have anything that should be added or revised – please let me know…I’m always interested in accuracy and completeness.

Project Management Timeline

1910s

• 1910 – The Gantt Chart developed by Henry Laurence Gantt (1861–1919)

1950s

• 1954 – Bernard Shriever (US Air Force) coins the term Project Management
• 1956 - The Critical path method (CPM) invented by Du Pont employees
• 1956 – The American Association of Cost Engineers (now AACE International) formed
• 1958 – The Program Evaluation and Review Technique (PERT) method invented and used on the Polaris project

1960s

• 1962 – DoD/NASA publish a description of the Work Breakdown Structure (WBS)
• 1967 – The International Project Management Association (IPMA) founded in Europe
• 1969 – Project Management Institute (PMI) launched to promote project management profession

1970s

• 1973 – International Computers Limited (ICL) offer PERT on a mainframe computer
• 1974 -PROMPT method launched (later known as PRINCE2)
• 1975 – PROMPTII methodology created by Simpact Systems Ltd (source: PRINCE2 manual)
• 1975 – The Mythical Man-Month: Essays on Software Engineering by Fred Brooks published
• 1979 – Central Computer and Telecommunications Agency (CCTA – later known as Office of Government Commerce or OGC – UK) adopt PROMPT II

1980s

• 1980 – First ‘on screen’ bar chart on early PCs
• 1981 – UK Army adopts PROMPT method
• 1984 – The Goal by Eliyahu M. Goldratt published
• 1986 – Scrum was named as a project management style in the article The New New Product Development Game by Takeuchi and Nonaka
• 1987 – First Project Management Body of Knowledge Guide (PMBoK) published as a white paper by PMI
• 1989 – PRINCE method derived from PROMPTII is published by the UK Government agency CCTA and becomes the UK standard for all government information projects

1990s

• 1996 PRINCE2 published by CCTA (now OGC) as a generic product management methodology for all UK government projects.
• 1996 – First published edition of the PMBoK appears
• 1997 – Critical Chain by Eliyahu M. Goldratt published

2000s

• 2000 PMBoK second edition published
• 2001 Agile Alliance formed to promote “lightweight” software development projects
• 2004 PMBoK third edition published
• 2006 Total Cost Management Framework release by AACE
• 2008 PMBoK fourth edition published

Testing Practices and Processes Defined

One key aspect of any project is the testing that is performed during Development by the delivery team and during Testing by the delivery team and the customer User Acceptance Testing (UAT) team. Testing, of course, is that last critical step to ensure both the requirements are met and the system is a working, functioning system and is ready for deployment.

Therefore, I thought it appropriate to present at this time some testing documentation I’ve been carrying around for quite some time on the subject. This information is from the Carnegie Mellon Software Engineering Institute (SEI) and describes the various types of testing that are commonly carried out during the development process up to deployment.

The following is an overview of each testing approach.

Design model validation: Each phase in the development process that creates a model of the product or some portion of it should include testing activities that verify the syntax of the model and validate it against the required system. The test can serve as the exit criteria for that phase. We use “model” in a broad sense, to refer to non-software assets that represent a product for the purpose of either making predictions about the product implementation or prescribing constraints for other assets. A business case for a product line is a model; it predicts how profitable the product line will be. Software designs are models; they predict behavior and also impose constraints on implementations.

Unit testing: Testing for implementation defects begins with the most basic unit of code development. This unit may be a function, class, or component. This kind of testing occurs during coding; therefore, the intention is to direct the testing search to those portions of the code that are most likely to contain faults–complex control structures, for example. As each unit is constructed, it is tested to ensure that it (1) does everything that its specification claims and (2) does not do anything it should not. A test case associates a set of input values with the result that should be produced by a correctly functioning system. The functional testing strategy uses the specification of the unit to determine which inputs to use in the testing. This strategy provides evidence that the unit does everything it is supposed to. A second strategy, termed structural testing, selects test inputs on the basis of the structure of the code that implements the functionality of the unit. This strategy provides evidence that the unit does not do anything it is not supposed to.

Subsystem integration testing: The integration of basic units, even those that have been adequately unit tested, may produce failures resulting from the interaction of the units. Timing discrepancies and type/subtype relationships can be the source of these errors. The tests are constructed from the use cases used to represent the full product’s requirements. The integration test plan should describe tests that have been systematically selected from the interactions among the units being integrated. Protocol descriptions between pairs of units or flows through sets of units that implement a specific pattern of behavior can be used to select the test cases. Test cases should include instances in which the error-handling capability of the units is evaluated, such as when one unit throws an exception that should be caught by another unit.

System integration testing: When some critical mass of subsystems has been fully developed and tested, the focus shifts to representative tests of the completed application as a whole to determine whether a product does what it is supposed to do. These representative tests are selected to cover the complete specification for the portion of functionality that has been produced. The amount of testing a specific function receives is based either on its frequency of use (operational profiles) or on the criticality of the function (risk-based testing). Special forms of system testing include load testing (to determine if the software can handle the anticipated amount of work), stress testing (to determine if the software can handle an unanticipated amount of work), and performance testing (to determine if the software can handle the anticipated amount of work in the required time).

In addition to testing as the exit criteria for process phases, the next five types of tests described are applied to verify certain product properties.

Regression testing: Regression testing is used to ascertain that the software under test that exhibited the expected behavior prior to a change continues to exhibit that behavior after the change. Regression tests are constructed, and periodically applied, to determine whether the software under test remains correct and consistent over time. Regression testing is triggered by changes that affect a predefined scope of assets or that affect certain critical assets. The actual test cases used in regression testing are no different from any other test cases. The regression test suite is a sample of the functional tests from the original test suites administered prior to any changes.

Conformance testing: Conformance testing determines whether the software under test can be used in a specific role in an application. The conformance test set should cover all the required interactions between all the components that will participate in the application.

Acceptance testing: To validate the claims of the manufacturer or provider, the consumer performs acceptance testing. The acceptance test is more realistic than the system test, since the application being tested is sited in the consumer’s actual environment.

Deployment testing: Deployment testing is conducted by the development organization prior to releasing the software to customers for acceptance testing. Where acceptance testing focuses on the functionality of the delivered product, deployment testing covers all the unique system configurations on which the product is to be deployed. This testing focuses on the interaction between the product and platform-specific libraries, device drivers, and operating systems. During the deployment testing phase, the application’s ability to deploy or install itself is also tested.

Reliability models: Testing is used to estimate the reliability of a software component or system; however, establishing the reliability of a piece of software through testing is a costly process. The test cases are selected based on the expected frequency of use of each product feature.

AMEC awarded $7.3M contract for solar plant at Buckley AFB

Sourced from the Denver Business Journal.

The U.S. division of AMEC plc of London said Tuesday it has landed a $7.3 million contract to build a 1-megawatt solar power plant at Buckley Air Force Base in Aurora.

The international engineering and project-management company’s Earth and Environmental Division, based in Plymouth Meeting, Pa., has a Denver office and four other Colorado offices.

Under the contract with the Air Force Civil Engineer Support Agency, AMEC will design the solar photovoltaic system for the Aurora base.

AMEC said it plans to complete the project in 368 days, less than the 449 days required by the Air Force.

“Bringing the system online more than 3½ months ahead of schedule will result in construction cost savings as well as energy cost savings for the government from power generated earlier than originally planned,” AMEC project manager Steve Felice said in a statement Tuesday.

AMEC will work with SolSource Inc., a Denver-based renewable energy and “green” building company that has designed and installed some 400 solar electric and thermal systems.

About 5,000 PV modules manufactured by SolarWorld at Camarillo, Calif., will be used in the project. The modules are made to be anti-reflective for use in a flight zone.

The Buckley project is AMEC’s second major Colorado solar-energy project announced this month.

On April 3, AMEC was selected to install a 2-megawatt solar power plant at the foothills campus of Colorado State University.