Dec 8th, 2020


Part 4: Change Is Inevitable

  Written by: Jesse LaDousa, Chief Executive Officer

author image

For the past several weeks, I’ve written about how to define success, prioritize your approach, and build an effective plan. During my ‘Planning’ article, I touched on a phrase my West Point graduate business partner likes to use: “No plan survives first contact with the enemy”. Within that article I briefly addressed how to handle disruptions to your plan, but today I’d like to spend some additional time on this topic.

As anyone who has ever run a software project (or any type of project for that matter) knows, disruptions and changes are inevitable. Never in the history of project-based work has an initial plan been executed with zero adjustments. As many of us who grew up utilizing the waterfall method of software delivery know, regardless of the weeks or months we spent on the requirement and design phases, once we started implementation changes were bound to occur. We slogged the project with change requests and updated requirements with revised definition. These changes were often looked upon as negative impacts to the project.

What if we turn around that thinking though? What if changes aren’t negative, but the result of the team gaining more knowledge as they work towards the objectives? What if these changes were looked at as positive developments to the project? If a change is important enough that the team’s focus is shifted to work on it, that change should be a positive development for the project.

One thing we spend quite a bit of time on with our teams is the way in which we communicate change request impacts. Changes can come from many directions: a shift in business priority, a new feature that is driven up in urgency, or a technology approach that simplifies maintenance and/or performance. Regardless of where the change comes from the most important thing is to immediately discuss its impact on the project.

Changes aren’t bad, but they all have impact. We must be abundantly clear as to what that impact is. It’s too easy for teams to simply respond to a request with “Sure, we’ll take care of that”. All of us want to please our customers and it would seem on the surface that just agreeing to take care of something is the right thing to do. Check that assumption and be sure you are evaluating what impact your agreeance will produce. It’s highly likely that something you already committed to deliver will be affected (or not accomplished at all) by agreeing to that change.

Instead, evaluate the new request and determine what the impact is. Work with the requestor to clearly articulate the size of the new request, the impact to work currently in process, and most importantly, what won’t be able to get done if this request is honored. This isn’t a contentious conversation but rather a fact-based discussion on what the true priorities are. Many times, the new request will trump other work. Sometimes though, existing work is determined to be a higher priority and that new request can be shelved for a later time. Without having this conversation though, you can’t truly get to either of those answers.

Change is inevitable. Let’s stop treating it as negative and instead embrace it with fact-based evaluation of impact to best determine its validity.