Learning

5 Top Causes of Project Change

Robert Phelps By Robert Phelps Global Project & Program Management Consulting Lead November 28, 2017

Project and program managers do many things, but nothing seems to cause as much grief and heartache as managing scope and change. Sleepless nights, exasperated conversations, and hours in the fetal position are often the results of project management and program management frustrations. To make matters worse, when change does occur, a project manager frequently complains to his/her spouse, who then takes it out on the kids, who then take it out on the family dog. Thus, whenever project change occurs, a dog gets dejected!

The Truth about Change

Sponsors, stakeholders, and project managers are confronted with numerous project and program challenges; unqualified resources, limited budget, schedule constraints, and change, just to name a few. Change, usually the elephant in the room, is often the most controversial, uncomfortable, and most significant topic to be avoided, but why? Is it realistic to expect no changes to occur?  Is it reasonable to think every task and activity will be executed flawlessly by highly qualified, available, and proficient resources?  Is it rational to believe environments and circumstances will be prepared, capable, and available to accept solutions? Given the complexity of organizations, environments, and technologies, change management is inevitable despite the negative perception that change is bad.

Complexity Necessitates Change

Think about the effort required to contract with an organization to perform a large enterprise data center migration effort, or a disaster recovery solution, or an application inventory and migration to the cloud project. These can be very large, intricate, and challenging projects on a good day, then mix in the exact description of services desired, the specific milestone requirements, and the contract details and legal verbiage, the effort becomes complex to say the least. Is it really reasonable to expect nothing will change from the conception to completion process? The following are reasons why organizations should plan, anticipate, and expect change and change requests:

1) Incomplete or poorly defined requirements: often a set number of servers to be migrated, amount of files to be moved, or specific inventory parameters exclude data required to accurately estimate the level of effort required. Rather than three move events, perhaps five or six are actually required. Rather than inventorying a pre-set of applications from specific business units, additional business units have apps to include. In addition, what were assumptions at the start of a project, may now be requirements and may dramatically change project constraints.

2) Change in stakeholder requirements or sponsorship: stakeholders may change their minds regarding scope, assumptions, or project deliverables and their opinions may increase or decrease scope, modify timelines, and impact budgets. In addition, the project sponsor may change due to resignations, redundancy, or other factors, and although that is not a guarantee project change will occur, it is something that should be considered and watched.

3) External and resource factors: if there aren’t enough people, money, time, or equipment to do everything desired, a change may be forced in order to get by. Of course, if you end up compromising on schedule or quality, a change to the contract will be required. There may also be other factors outside of your control that impact the scope of the project. External events can be general or project-specific. A general event, such as a state-wide power failure due to a violent hurricane, does not directly relate to the project, but could force a change request. A project-specific event could be a delay in environmental preparedness, change in local zoning regulations, or anything that require immediate changes to the project. While this may be out of your control, it affects the project.

4) Scope error: poor scope management is the main cause of scope creep happening in most projects. It does not matter whether you apply an Agile SCRUM method or traditional waterfall, the impact to project cost and project schedule cannot be avoided. A project scope error usually results from an error in estimating or planning the work in the initial phases of the project. This could include anything from underestimating the time it takes to complete each task to not properly defining the work in each phase. Although most project scope errors cause the project to run behind schedule, they can also result in phases or deliverables being completed ahead of schedule. Using an incomplete WBS for a project would prompt a change request due to a project scope error. Since the project scope was not properly defined, activities may be missed or duplicated, causing schedule and budget problems.

5) Nothing is simple or as easy as it seems. Schedule issues, resource challenges, and strong personalities often present opportunities for change, challenges, or to put it delicately, personal development and growth. What may be anticipated as a brief status update meeting may take considerably longer due to questions, stakeholder comments, or discussions about new risks on the project.  What may have been expected as a quick requirements, risk, or deliverables review meeting, may takes longer than anticipated. Nothing is ever quite as simple or as easy (it seems) as predicted.

References

IT Project Management

Robert Phelps

About Robert Phelps


Global Project & Program Management Consulting Lead

With more than 14 years at Dell EMC and over 30 years of consulting, project/program management, and professional training experience, Robert has expertise in program management for large complex IT Transformation solutions, hardware/software deployment, education analysis, curriculum design, and training delivery methods.

Robert has participated in the management and deployment of hardware, software, and training solutions to more than 300,000 personnel in 230 locations worldwide.

Robert is innovative, methodical, and creative. Leading a team of senior program manager direct reports, Robert led the efforts to create, develop, and deploy the program management methodology (DEPGM2) for Dell EMC. In addition to his methodical and innovative side, Robert has authored numerous articles, videos, collateral and books including playbooks, pre-sales collateral, and strategic and transformed living guides and books.

Robert has participated in numerous civic organizations, taught at the US Army War College, served as adjunct faculty at George Washington University, and has numerous interests including camping, boating, writing, traveling, and playing music.

Read More

Join the Conversation

Our Team becomes stronger with every person who adds to the conversation. So please join the conversation. Comment on our posts and share!

Leave a Reply

Your email address will not be published. Required fields are marked *