Traditional views of project management often focus on ensuring that a fixed scope is delivered on time and within budget. When the tasks involved in achieving a project's goal are well-known and easily estimated, this makes great sense. The most used example of this is the construction industry, where a clear relationship exists between the size of the project and the amount of time and resources (money, materials, etc) required to complete it. Sure, unforeseen circumstances arise; permitting failures, errors in surveying and the like. However, even these pitfalls are relatively foreseeable and their risks can be allocated during contracting. The process of transforming architectural blueprints into a physical space is not one that experiences frequent fundamental changes, and the external factors that can impact that process are fairly well known. With software, "not so much"...

An Ever-Evolving Landscape

Software, and its construction, operates in an environment that is never static. At any point in a software project, all manner of external factors may impact the validity of your plans. For example:

• Your competitors may emerge with functionality similar to what you're building, without your prior knowledge. Time to pivot.
• A change in a system you want to integrate with may turn the interconnectedness of your systems from an asset to a liability. Time to rethink how you're integrating (and maybe what you're integrating with).
• Legislative change might trigger new compliance requirements for your product, on a timeline you have no control over. Time to call the policy team.
• Consumer preferences could shift, reducing the value proposition of your project. Again, time to pivot.

While these are foreseeable possibilities, the magnitude of each of the examples above could range from a minor inconvenience to a total impediment to progress, and that magnitude is not foreseeable. Moreover, the pace of change only increases in the technology industry and business as a whole, making the odds of encountering such a problem more likely. Unlike a construction project, the risks are simply too numerous and difficult to categorize to reasonably allocate them through contracting.

So what happens when such a problem arises in a fixed scope, fixed budget project? Someone gets the short end of the stick, depending on contracting, which leads to rushed low-quality work, conflicts of interest between client and technology team, and often the dreaded death march. What happens when these problems arise in an agile project?

"No problem."

Adapting to Shifts

Agile has meant many things to many people over the years, but fundamentally it means moving away from fixed scope projects to projects where scope, even if well defined at the beginning (and this is a good idea), is fluid and responsive to change. That happens through small, iterative cycles of work where the project team surveys the remainder of what needs to be done, prioritizes tasks, and agrees to deliver a small number of those tasks in a fixed unit of time, typically two weeks. Done early? No problem, go back to your prioritization and start working on the next highest priority item. Not done yet? No problem, let's revisit our estimates and improve them for next time. Major external change? No problem, let's figure out what it means, how to respond to it, and work it into our priorities.

Fundamentally, agile processes put you, as client, and stakeholders in control. Since you're highly involved in prioritizing work, your technology team is constantly working on your highest priorities. That means after your first cycle (typically called sprints), you're always in a position where the most important work so far has already been done. That also means you, as client, get to decide when your project is done. Has enough value been delivered to create ROI, even if there are still low-priority tasks remaining? No problem, let's get your project live and whittle away at the nice-to-haves as needed.

As the saying goes, "Scope, time and budget. Pick any two." Pick the right two by using agile and adjusting scope on the fly.