A military quote, but applicable to software projects as well. We both have objectives to meet, resources to implement the plan, third parties to interface with, the terrain or environment with which to operate in, communication of the plan to the troops, communication of progress and issues to stakeholders. I’m not sure there’s a software equivalent for the enemy, but I’ll leave that to your imagination.
As prototypes or betas get in the hands of end users, key features and requirements of the solution can alter.
There’s a gaggle of ways a plan can change, and although my war movie watching experience is extensive, I’ll keep this post limited to typical scenarios with software projects.
Scenarios
As prototypes or betas get in the hands of end users, key features and requirements of the solution can alter. You expected users were going to use it this way, but they don’t. Or business processes change as the system automates previously manual tasks.
Information that was expected to be entered by users or received from other systems can be poor or inadequate: processes may need to be changed, data may need to be cleansed, alternative sources of data may need to be found, or logic applied to fill in the gaps. In some cases we have the opposite problem where we have to wade through mountains of data to pull out the small pieces the solution needs.
Delays from third parties can cause delays in milestones, or result in functionality being moved to future phases.
Technical issues may include issues with third party components, poor documentation for third party libraries or services, poor data in the DEV or UAT environments to sufficiently test against. These issues cause delays and extra costs while workarounds are found.
There are of course external influences not relating to the project that can have an effect: new business opportunities, influence from competitors, government regulations, or a global financial crisis can all result in a change in priorities, features, and resources.
Being agile means responding to change over holding steadfast to the original plan.
Scope Creep
At some point you knew I’d mention scope creep. Along with some of the items previously mentioned, scope creep is normally due to stakeholders wanting the solution to achieve more. This is understandable, as when working through the designs and requirements it’s easy to get excited about how the new solution is going to change your business. Like a kid in a candy store wanting more and more, the solution starts to grow and grow. Often these extras will find themselves on a wish list, but sometime the scope of the project will be extended to include them.
Being Agile
The best laid plan will go a long way towards achieving the original objectives, budget, and timeframe, but also plan for change. It’s why we follow agile principles. Being agile means responding to change over holding steadfast to the original plan - “harness change for
the customer's competitive advantage”.
A word of caution here: I’ve seen some project teams not plan in their belief that it wasn’t agile to plan, instead they bumbled from sprint to sprint. I think those teams could have spent a bit more time planning the project, and less time adhering strictly to their adopted agile methodology.
Have a plan, assume the plan will change, have the tools to manage change, and of course have the right people involved. Success requires both planning and teamwork. In the end it’s the team that will have to execute the plan and roll with it.
