The Independent Consultant
October 2009, Issue No. 27

Project Management: Sticky Situations Series Topic 2—Change
(the Not–So–Innocent Enemy)

by Doris Orr

Project Management: Sticky Situations is a series of articles which outlines some potential pitfalls in the realm of project management, and which can be applied to general management settings. These situations, if left unaddressed, may certainly result in the early demise of an otherwise healthy/successful project.

Topic 1, which addressed the dangers of negative conflict within a project team, was covered in the March 2009 issue of The Independent Consultant newsletter. See http://Newsletters.soa.org/soaic/issues/2009-03-31/

Topic 2 in the sticky situations series addresses the potential dangers associated with requested changes after the project scope has been finalized. A simple change sounds so innocent but it can have a catastrophic impact on your project.

Definitions

The definition of change from Wikipedia is: "the act, process, or result of altering or modifying." The breadth of the definition is the root of the problem! The concept of a change is so simple but the far-reaching impact can be massive—and it can be destructive—to your project deliverable. Luckily, there are ways to successfully manage change.

Read on to find out how and why and what to do to avoid the potential disaster.

What Triggers Change?

Changes can result from many different sources, such as those in business requirements, project dependencies, technological environments, unforeseen circumstances, unanticipated project issues such as changes in key resources, or a correction due to an inaccurate scope assessment, estimation and planning. Some changes don't alter the business case but have a significant impact in your ability to deliver on time and on budget. Examples include the loss of a key project resource or a reprioritization of other projects that puts your project in a lower order of importance to the company than when you scoped it out.

Some changes are mandatory, such as revisions in the regulations governing your company/industry which have a direct impact on your project scope. Other changes are "nice to have" such as the "bells and whistles" that will make your project deliverable look and/or perform marginally better. To get to the root of the change request, you'll need to "data mine" (a good actuarial phrase!) to dig beneath the surface to find out the impetus, i.e. the driving force behind the change request. These insights will help you and your project team determine how best to handle the change request so that you keep you "customers" satisfied, and also still enable you to be successful in achieving your project deliverables—within your project's time and resource/budget constraints.

What's Really Going On? Listen Beyond the "Noise" to Get the Real Facts

Change requests usually arise in a very innocent way. An example may be that a project stakeholder or a key business sponsor will kindly ask the project manager to make a slight alteration to the predefined and agreed upon finalized scope. As a project manager, it always seems easiest to be helpful and accommodating—to be a good team player. And business sponsors always believe that whatever they are asking for is covered by the agreed project scope. But, watch out!

This very innocent change which was kindly requested by a stakeholder will likely be a not–so–innocent change, as the impact of it may delay your current deliverables. It may also cause your team to lose focus on their current tasks to achieve the on–time and on-budget deliverable and ultimately, it may cause your project to fail. If your project fails, then you—as project manager—fail too!

Yikes! Doesn't sound like a project that any of us would want to be associated with, does it, so read on ...

How to Deal with Change

The best thing to do whenever any change is requested is to run the proverbial red flag up the flagpole and stop the project; yes, that's right, stop the project!

Make it a really big deal each time a change is being requested of your project team. It goes without saying that there should be an agreed change-control process with request forms, an inventory of change requests and a process for evaluating and prioritizing them. This will get the attention of all the project stakeholders who will quickly assess whether they want their change request to halt the flow of the execution phase of the project.

The project manager should arrange for the project team to perform an impact analysis which will assess all the possible areas which will be impacted as a result of the change. Each identified impact will require some additional work—and yes, you guessed it—additional costs and additional effort, which can delay the project delivery date.

A predetermined dollar threshold should be set for time/effort associated with evaluating the impact of the change on the project. This will help ensure that your team properly assesses all aspects of the change and which, in turn, will help you determine the right decision based on a thorough analysis, rather than trying to make a quick and impulsive decision. This evaluation—as well as the change itself—should be allocated from a contingency fund, which is normally established for the unexpected (but essential) tasks which weren't envisioned when the project was scoped out. A contingency is usually a percentage, e.g., 5-10 percent of the known project costs. It is always best to have the contingency set up as a separate component in your project plan, rather than inflate the individual known project tasks for this buffer. I know this is stating the obvious but contingency planning needs to be part of your initial project plan.

Resolving the Dilemma of Whether to Implement the Change—Using Win/Win Collaboration The reason for the change will most likely provide the impetus for the solution and may (or may not) provide the tolerance for accepting the impact of the change. A mandatory change such as a changed regulatory requirement which has to be dealt with by the project team will receive a higher level of acceptance by the project manager than an additional bell/whistle that is a "nice to have."

Sometimes, after an initial discussion regarding the impact of the change on the current project deliverables, the project manager is able to arrange with the stakeholder/change requestor to delay the implementation of the change until a subsequent phase of the project. This will give the requestor confidence that his/her change will be delivered and will also help ensure that the current project phase will stay focused on the current set of deliverables within the agreed timelines and budget. This approach works particularly well when there is a set schedule of update releases.

Remember, everybody wants to be part of a winning project—which, in part, means delivering the
best possible product.

In light of all the excitement and/or drama around the requests (or needs) for change, remember what the initial problem is that your project team is trying to solve. Don't lose sight of what your ultimate deliverable is! This focus will help you and your project team make the right decisions and make it easier to communicate less than good news to the requestor of the change, if you determine that the change cannot be accommodated within your project constraints.

If your team has made the assessment that the change can be accommodated into your current budget—without compromising quality and deadlines—then you need to make sure that this change is quickly and clearly communicated to the entire stakeholder community. The rationale behind the "yes" decision will also help them understand the thorough process that you undertook in determining whether the change would be accepted into your project scope. You will also want to ensure that everybody impacted by this change is brought into the loop as quickly as possible, as they will need to determine what they need to do differently to fulfil their part of the change order.

Remember, there is always a fine balance between: (i) acquiescing to make project stakeholders happy that they are getting what they ask for; and (ii) ensuring that your project team keeps focused on delivering the agreed scope within the agreed timeframe and budget. Always keep this in mind as this will make your life as a project manager much easier.

Some Final Thoughts

Being a project manager is so much more fun when you stay in control of the fundamentals, which includes dealing with requests for changes in a win/win solution focused way.

Just remember what's at stake—either keeping people happy or keeping your project on the path to a successful completion or both. Make sure that a requested change doesn't become your not–so–innocent enemy!

Look for the next article in Project Management: Sticky Situations Series. Also, if you have any examples of potential project pitfalls, please feel free to submit them to me and I would be more than happy to provide suggested solutions on these.

On Oct. 28, 2009 I will be presenting a project management session at the annual SOA conference in Boston, Mass. Learn more about this session and register at SoaAnnualMeeting.org/agenda-day4-sessions.aspx#session124.

Doris W. Orr, CA, is SVP project director for XL Capital. Her passion is to add value and to help others get excited about adding maximum value in order to ignite their career paths. Through experience gained from running many projects—both large and small—and from working abroad for various years, Doris provides practical insights on how to increase your value—one second at a time. She can be reached at doris.orr@xlgroup.com.