A Critique of
Edward E. Douglas’s
Article
“Effective Management of Project Change Orders”
Table of Contents
Abstract
Introduction
Planning for Change
Planning and Design
Change during Application Build
Closeout
Conclusion
Abstract
Scope is the total sums of all the products/services that are required to complete a project (PMBOK, 2013). But even when the scope has been completed and a freeze is agreed upon, change occurs. Edward Douglas’s article “Effective management of project change orders” discusses how to effectively manage any requested changes that may come up during the life of the project. And while he concentrates considerably on the construction industry, much of what he suggests is applicable to any project. Could these concepts be used in another industry such as IT applications development projects? This paper will explore that possibility.
Introduction
Scope is the total sums all the products/services that are required to complete a project (PMBOK, 2013). But even when the scope has been completed and a freeze is agreed upon, change occurs. Edward Douglas’s article “Effective management of project change orders” discusses how to effectively manage any requested changes that may come up during the life of the project. And while he concentrates considerably on the construction industry, much of what he suggests is applicable to any project.
In this paper I will apply what Mr. Douglas suggests to Information Technology (IT) projects as there are a lot of similarities in the methodology Edwards advocates. For instance, we can all agree that the earlier we can identify a change the easier it would be to implement that change and the less costly it would be to implement. Further into the life of the project, the harder it will be to implement and the cost goes up. For example, it is much easier to change the foundation of a house before you pour it then it is to do so after the roof has been installed. In the programming world, it is much easier to make changes to the user interface while it is still in design then it is when you’re ready to push it out to production. There are many different methods and processes that can be put into place to help ensure that changes are identified and considered early in the process rather than later. Are these 100% effective? No, but it does help to eliminate many a costly error or change.
Planning for Change
Before any planning of what the project is actually to do begin, the project leadership needs to develop a project change management plan. The object is to put into place an agreed upon process for managing change should it occur.
The change management plan needs to plan who has the authority to approve changes. One has to take into consideration the threshold in which a change, such as a simple one, can be made by the project team, or if it is of such impact to the project that it needs to be approved by a higher authority. The plan has to outline the process for approval and everything that is needed for approving changes.
This plan needs to consider the process for submitting the requested change. Questions to be answered are who can make the change request? Who does a change request need to be submitted to? These are not easy to answer questions. Usually it’s the Project Manager who should initially receive the initial request for change. But sometimes one of the lead managers can receive a change request and then submit it to the Project manager. But, a change request should always go through the Project Manager since they oversee the entire project and can see impact where others are not aware (PMBOK, 2013).
The change management plan needs to consider how a change will be analyzed for impact to the project. What will be the impact to the schedule? Will it require overtime or extra resources or specialized help (availability)? Once the change request goes through impact analysis it will need to go through the approval process. The analysis process needs to outline what information is required and in what format should it be delivered and to whom it should be delivered in order to get approval. Should all change requests go through a steering committee for consideration, or can the PM decide that a requested change is too far outside the scope of the project for it to proceed (Verzuh, 2012)? Perhaps consideration of the change will take away resources from work underway and will have an adverse effect on the project timeline and budget; should the project budget money towards considering change requests?
Planning and Design
The most appropriate phase in which to take on change would have to be during the planning and design phase. It is best to consider and implement change as early as possible in the project as it is easier to and more cost efficient than it would be in later phases (Douglas, 2003). It is recommended that the PM and the sponsors freeze the scope of the project as early as possible in the planning or design phase. This holds true in construction as well as in IT projects; IT projects will find it a little easier to make changes to the scope even while in the execution phase. The master schedule should also be completed and approved during this period so that any requested changes can take into consideration impacts to it. Early completion of the design of the application will allow for build reviews and to catch any possible changes before construction of the application even begins.
By determining the scope, the work required, like through a Work Breakdown Structure (WBS) and completing the design of the application before even beginning to execution a build the project team can identify any changes that may be needed and to determine if implementation is needed. If the change identified is needed then the steering committee can determine if it wants to approve the impact the change will have to the project.
Change during Application Build
Since the project leadership team created a change management plan early in the project it would seem reasonable to say that any changes to the scope would go through this process before any change occurs.
The team would have to be thoroughly knowledgeable on the project plan and scope and understand the impact any change could have on its outcome. When a change is requested the team would have to put together an analysis of the impact that change may have. The PM would have to determine if he even wants to commit resources to doing the analysis of a requested change. The first questions to be answered are whether there is time and money in the project to consider changes. Another concern would be the impact of cumulative changes to the project. The danger here would be scope creep and budget overruns leading to financial failure of the project (Douglas, 2003).
Closeout
The concern here is that if the project is not properly closed; have all changes been completed; have all changes been properly documented, even those not approved? Subcontractor and vendor claims have to be closed before usage of the projects product and/or service is used. Potential problems include changes that were not completed properly or just simply not done. If the project is not properly closed problems could crop up. Too often closing the project is given little notice. The project team and leadership have often moved on to other projects leaving the PM to try to clean up the pieces.
Conclusion:
Douglas points out that it is best to develop and to put into place a proper change management plan. PMI points out that it is best to develop a number of management plans that help to guide the different processes of the project; a plan for each phase, so to speak. Many of the suggestions and guidance given by Douglas can be used in projects in other industries, too.
References:
Douglas, E. E. (2003). Effective management of project change orders. AACE International Transactions; ABI/INFORM Global, PM111.
Kerzner, H. (2009). Project management: A systems approach to planning, scheduling, and controlling. Hoboken, NJ: John Wiley & Sons.
Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK guide), fifth edition. Newtown Square, PA: Author.
Verzuh, E. (2012). The fast forward MBA in project management, fourth edition. Hoboken, NJ: John Wiley & Sons.
