Change will make or break your project

It is always easier to talk about change than to make it.” ~ Alvin Toffler

Change will make or break your project, changes can‘t be controlled your reaction can. A fixed mindset breaks instead of bends when confronted with change. Change is constant, some don’t adapt, others adapt enough to survive, a few use change to be successful. The less rigid and more adaptable you are, the fewer times you get stuck.

Technology, resources, environment and tools change, it costs you time and effort to change but the cost of not changing will be higher.  What was successful in the past, might not be successful in the future. By focusing on the past, you won’t be prepared for the future. The past has gone and can‘t be changed but the future is yet to be defined, embrace change and improve your situation.

Code and change

The art of develop lies in the constant adjustments to change

Robust code is decoupled, ensuring it can adapt to the evolution of requirements and manage the effects of change. Agile development leaves design decisions to as last as possible, giving more time to gather information and decide based on better understanding.

Requirements and solutions evolve, the more detail you uncover, the more feedback you receive the greater your awareness of the problem and the solution.  You can’t capture requirements up front and get a deep understanding without going through iterations of designs and problems.

Project change

A project won’t change but you can change yourself and the approach to be successful.  A project which does not adapt to the changes will fail.  We are servants of projects, they will tell you when it‘s not working.  Think about the pain points, how could this work differently.

Nothing is fixed, people, requirements, technology and politics change, be fluid, formless and adaptable. Take a flexible approach, what was successful on previous projects might not be successful with these requirements, environments and people. When you think requirements are certain, you risk creating brittle designs and brittle plans that will break when change happens.

It’s not if change happens but when and how you react.

Projects evolve, the design at the start is not the functionality in production. This is because the requirements change with understanding and feedback.

Each projects rhythm is unique and the most efficient way of working different. You have to adjust and keep improving, finding a smoother way to move functionality from requirements to production.

Conclusion

Don’t fight change and don’t wait for it to happen, embrace change and use it as an opportunity for improvement. Change is not comfortable or easy and involves conflict but through this something better emerges.

Knowing change is coming won’t make it easier because you will need to move past the friction but it’s the only way to make progress