In the ideal world, it would be easy to see where our lives were headed so that we could plan accordingly and ensure that we are successful at every turn. However, life isn’t predictable and unfortunately, the same can be said for software development as well. As much as we try and prepare for every eventuality and make our projects as predictable as possible, dealing with change becomes an inevitable part of the development process and it’s how we deal with these changes that determines how successful we will often be.
What Causes Change:
So, before I talk a little further about change management and how to deal with it, I want to first unpack the reasons for why change often occurs. Because if you can understand the sources of change, it’s often easier to mitigate or eliminate these entirely.
Changing Business Requirements
This occurs when either the underlying business function behind the existing project goes through a change, or more likely, a lack of understanding in what the business process really entailed means that the current implementation needs to be changed. This cannot always be avoided, but often the best way to mitigate this is more time spent in planning up front and regular prototyping and walking through solution with the relevant business sponsors to identify these things up front.
Changing Technical Requirements
It might sound like the above point, but it offers for the very reason that is often very much in control by the technical team and mostly boils down to a lack of POC or technical understanding than something changing. Software can be volatile and change, but not to the degree where it should effect your technical requirements extensively and so if you are experiencing this there is a chance the architecture or technical team missed something along the way. It’s pure human error here and can only be rectified by improved understanding and retrospective.
Organizational, Resource and Budget Changes
One of the most difficult changes to weather in any team is when resources or budgets change. Changing people in any team causes disruption and will affect their ability to deliver. The same goes for budgetary changes where either money/time or likely both are cut from a project and a team has to drastically look at how and what they deliver to fit into these new constraints. There is often very little that can be done by these factors as its beyond most teams control – the best way to mitigate it is to simply except some level of it and add some amount of fat and surplus into the initial estimate and planning so that should it occur, it can be weathered without too much turmoil.
How to Prepare for and Deal with Change
So, while certain elements of change can be planned for and mitigated again, the reality is that teams are going to face it anyway and its hoe teams deal with change that will allow them to be successful despite it. Hopefully the below tips can help teams weather these changes appropriately:
Don’t think it won’t affect you
One of the common threads I see with teams that are unable to successfully transition through change is that they just continue on as normal without making any re-planning or adjustments to their initial work commitments. When requirements or people change, it imperative that however small the change, the team revisits their plans to better identify how it will affect them and possibly adjust deadlines or scope as a result. Every of m of change deserves the effort to dive deeper and if you don’t, changes will come that will cause your project to become untenable.
Understand the impact and Adjust Quickly
While teams might not understand all the effects of the change when it is first uncovered, waiting too long to gather all the details limits your ability to deal with it. The moment a need to change is identified, a team should already start making changes for it – even if it is simply bumping a task off the backlog until more information is known. What should also happen though is that any impact to resourcing or estimation should be determined immediately and even where not known, at least have some form of additional buffer added in to cater for the uncertainty. Teams shouldn’t try and save face and not communicate these impacts as it will only affect them later when deadlines start approaching or even slipping. Another aspect of making the change immediately is that its easier for teams to see when the changes happened and how it impacted them, so that they can learn from this for future projects.
Prioritise and Provide options
With software development, things like deadlines and various constraints are not always fluid and so when projects change, we need to factors these things in mind. This means that we need to effectively prioritise the different contingencies that arise as a result of change and perhaps look at different options around cutting scope or changing scope to often meet some of the less flexible constraints. It’s always difficult to determine one exact path and often plans may fluctuate based on further change, but having a list of options available at least provides teams with the ability to respond as more information becomes available and they need to move towards a different option.
Ownership and Communication
With any change, it needs to be communicated to the relevant people – team members, people whose projects have dependencies and business stakeholders. Communication is one part, but ownership needs to also be provided on exactly who is going to own the tasks related to this change and how they are best going to be mitigated. Some teams can make use of formal processes to manage this change, others might be a little loose in how they track it. The method is irrelevant, provided that ownership and communication is clear.
Review and Retrospect
We shouldn’t just deal with changes when they happen, but also once everything has settled down and it has come to a time to review some of it, change management needs to form part of that process. Questions like did we handle the change effectively land what can be done to avoid this change in the future need to be asked and the team should document and come to an agreement on how changes like this need to be dealt with in the future. It may sound like unnecessary admin and time wasted, but it will save you incredibly when you need it and failure to do so means your team will likely continue to repeat the same mistakes. And that is unforgivable.
Change happens, but we shouldn’t blame it for our inability to meet the necessary goals and deadlines. It can be managed and we can take ownership for ensuring that the necessary mitigation plans are in place and well communicated should it happen. Even better yet, certain changes can be avoided entirely if we plan correctly and learn from the past.
Comments