Have you experienced an IT project that crossed the finish line on time and within budget? Congratulations! You’ve been part of a project where scope management was handled properly.
Those three cornerstones of project management, namely time, money, and scope, are intertwined in such a way that you can’t increase one without affecting the others. Yet, more often than not, the scope of the project seems to stealthily expand as the project progresses – and bam – there you have it, the dreaded Scope Creep!
For the client, Scope Creep means either an extending schedule or a growing budget – usually, it’s a bit of both. When planning development work, we start with average estimates in terms of time and labor. The supplier wants to make an offer that is attractive but also sizable enough to deliver a functioning system. And no matter how much experience one has, these estimates are always just that, estimates – not promises of the future.
For the supplier, even a slight scope creep can create pressure to stay on schedule and within budget, causing the project manager sleepless nights and gray hairs trying to prevent it. It’s all too easy to start cutting corners on the “invisible work,” such as testing and adhering to best practices in version control.
This inevitably leads to a deterioration in quality, making the supplier appear unprofessional.
Although I thoroughly enjoy the Finnish language, there’s no suitable translation for “Scope Creep.” I hope you’ll forgive my use of the term from here on out.
When projects just swell and swell
There are numerous reasons for Scope Creep. Depending on the size and nature of the project, it can be quite challenging to estimate the total cost or the required time to cross the finish line in advance.
Often, projects are constrained by factors such as maximum budgets or deadlines. Regardless of the delivery model, be it waterfall or agile methods, the same principles of scope management apply. For simplicity, I will use the tools and terminology of the agile method in this discussion.
Scope management begins with defining the project objectives.
What are we aiming to achieve with this project? What should the final product be capable of? What functionalities must be available to the end user? What is the sufficient level of functionality for automation or the user experience?
The answers to these questions set the foundation for workload estimates. Nowadays, when assessing the scope of IT projects, we’ve gotten pretty good at accounting for all sorts of surprises that pop up during the project, as well as the time needed for testing, deployment, and documentation. Despite this, it’s tough to draw a firm line on just how extensive a project should be. Especially tricky to estimate are integrations between systems.
Agility does not mean lack of planning
Contrary to many prejudices, the agile delivery model doesn’t just throw plans out the window. On the contrary, continuous evaluation and simple math ensure that the big picture remains under control.
Core tools of agile development include the backlog and user stories. The backlog is a list of tasks that encompasses all the tasks and wishes pertaining to the project. These tasks are written in the form of a user story, formatted as “<Who> needs <what> and <why>”. True to its name, a user story describes a business need from the user’s perspective, not a technical description or a task to create button x in location y.
From the backlog, user stories are selected for development during the sprint in accordance with priority. A sprint is a period during which the delivery team develops the chosen tasks, which are ready to be moved to production at the end of the sprint. The duration of a sprint can be determined based on the project or development model. Typically, sprints last two weeks, but they can vary from one week to one month.
Whether you’re using project management software or a spreadsheet, it’s crucial that the backlog user stories are evaluated for workload and prioritization is done at the end of each sprint. This way, any creeping scope can be addressed promptly.
The user story description must include a clear definition of done. When the particular user story passes the acceptance testing with flying colors, it is closed, and the functionality is moved to production at the end of the sprint. Sounds simple, right? If only it were that easy!
The definition of “finished” always depends on the interpreter, and mere technical functionality doesn’t guarantee customer satisfaction. A clunky user experience might technically work, but if it’s too difficult to use, it can decrease user engagement and thus, the value delivered to the customer.
In challenging cases, it’s wise to factor in the time spent refining usability in addition to just the technical implementation. Keeping the customer’s business objective as a core part of the project makes it easier to make the right decisions when managing scope.
Transparency benefits everyone
Transparency in project planning and delivery alleviates pressure on the supplier side in managing scope.
It’s much easier for the client to grasp the big picture and the dependencies between components when communicated openly and regularly. Excess requests and desires diminish when the entire implementation is transparently laid out by the numbers.
Even the client can see that it’s impossible to complete new functionalities within the given time frame when all tasks have been pre-estimated.
No amount of dissecting user stories is enough if the project owner either can’t or won’t make the tough choices. Because, indeed, that’s what success demands. Prioritizing one thing over another.
When it’s a showdown of tough versus tough, not all user stories are created equal. Needs can also change during a project; that’s why prioritization must be ongoing.
In the delivery side, you might hold the title of Scrum Master or Project Manager. However, prioritizing user stories is not part of that role. That responsibility lies solely with the client, regardless of whatever title they may hold within the project. I’ve found it highly effective to use price tags when a client wants to stretch the scope of a user story.
Customer: “Otherwise, this functionality is great, but could we get our logo added to each screen, nicely spiced up with flashing lights?”
Me: “Sure. Rough estimate for that is two days. Should we drop something from the upcoming sprint, or shall we increase the budget by x euros?”
Suddenly, additional requests decrease dramatically when even the smallest matter is presented with two concrete options, each having its own consequences.
The work of a consultant or developer becomes tangible, and a large project is no longer just an ambiguous black hole sucking in money. We are one team, united by the same goal: to bring the project to completion within the set timeframe and budget. No Scope Creep allowed.