I am sure you have read unrealistic articles that suggest there is some scientific approach to pricing that will magically allow you to create an accurate quote. You may also have been led to believe that scope creep should be avoided at all costs, but in the real world, it will always happen.

It is time for us to stop playing this ridiculous game and start running projects in a way that is less like gambling and more like following a robust and reliable process.

Am I exaggerating? Possibly, but let’s look at where things so often go wrong with digital projects.

The Problems With Our Project Process

In my experience, most organizations across any industry run projects in approximately the same way:

1. Somebody in management requests a project be completed. Unfortunately, this request often lacks details in terms of deliverables and tends only to have vague goals.
2. A committee of stakeholders is assembled to define the project in detail and decide on the scope.
3. The detailed scope is then taken to the team that will build it, and they are asked to estimate how long it will take and how much it will cost.
4. The project is delivered to the specification, emphasizing delivery to time and within budget. As a result, scope creep becomes the enemy.
5. The project is delivered, and everybody moves on to the next project in their task list.

This approach is far from ideal, especially for digital projects. Digital provides us with unprecedented feedback on user behavior and makes it relatively easy to implement changes (compared to physical products). Yet, once the scope has been defined and a quote provided, the project becomes locked down, with everybody reluctant to make changes as the project progresses.

Yet inevitably, the scope does end up changing, mainly because stakeholders have varying interpretations of what will be built or because they realize mid-project that critical elements are wrong.

In truth, there is nothing wrong with scope creep. Remaining flexible and adapting as you learn more is fundamental to creating excellent digital services. The problem is not with scope creep but the way we run projects.

Unfortunately, because deadlines and costs have been agreed upon, we attempt to deliver these changes within those constraints, leading to corners being cut.

Not that the timelines and costs were accurate in the first place. Digital projects are complicated, often involving specialists and stakeholders working together. As a result, they are notoriously hard to estimate accurately.

I have read many articles that propose methodologies for estimating accurately. However, they are impractical in the real world in almost all cases, mainly because they are too time-consuming to apply. Estimating a project comes down to intuition, experience, and an educated guess!

As anybody who has worked in the field for any time will tell you, most estimates are a work of fiction. We usually don’t know enough upfront even to determine what the right solution is or how users might respond to it. It is therefore impossible to accurately estimate an entire project upfront.

Unfortunately, this ambiguity often leads to unfairly distributing the blame when the project inevitably misses its deadline and goes over budget.

Fortunately, there is a way of providing accurate estimates, and managing scope creeps that involves changing the run projects. The secret lies in splitting projects into smaller chunks. This approach avoids taking on large and complex projects.

Break Projects Into a Series of Smaller Engagements

I need to be clear at this point. I am not suggesting that ambitious programs of work are wrong. I work for big clients on substantial websites and sprawling programs of work. However, I rarely treat these engagements as a single large project. Instead, I break them down into more manageable projects that I scope one at a time.

When a client approaches me wanting to undertake a digital project (be it large or small), I typically break it down into four stages that happen in the following order:

1. Discovery,
2. Alpha,
3. Minimum viable product,
4. Ongoing iteration and optimization.

Each stage is a separate engagement with clear deliverables. Therefore, I do not commit to the whole project but only to the first phase. That makes estimating and managing scope creep a lot easier.

For example, you only need to define the scope of the next stage. That allows you to manage scope creep better because you can accommodate it as you define the next stage, once the previous stage has been completed.

Instead of estimating an entire program of work, you are estimating the next project in that program. Also, you can use the previous stage to help you estimate more accurately.

Each stage helps to define and estimate the following stage, beginning with discovery.

1. Discovery

In the discovery phase, I work with stakeholders to validate the project. Depending on the project’s overall size, this could be as simple as a couple of meetings or could be an entire program of work.

Typically it includes elements such as:

• carrying out user research;
• analyzing the competition;
• identifying key performance indicators;
• defining what success looks like;
• understanding constraints;
• collating stakeholder opinions.

The idea is that the discovery phase will deliver a more informed definition of the project, including user needs, business objectives, and what needs to be created.

Most importantly, it will validate that the project will deliver the required value.

We can then use this deliverable to define and estimate the work required in an alpha phase. Doing so makes our estimates more accurate and also adjusts the scope based on what we have learned.

2. Alpha

The alpha phase is where we define how the digital service (whether that is a web app or site) will work and ensure that users have a positive experience using it.

That is typically done through the creation of a prototype. On smaller projects, this might be nothing more than some design mockups. On larger projects, it could be a functional prototype that people can try out.

Whatever the case, the idea is to visualize the digital service you are building.

We do this for three reasons.

• First, a visualization will ensure all stakeholders have a shared vision of what you are creating. A document can be interpreted in many different ways, but that is much harder to do with a prototype.
• Second, a prototype will make it much easier to identify anything that might have been overlooked so avoid scope creep further down the line when it is more expensive to address.
• Finally, if we have something tangible, we can test it with users to ensure that it will be fit for purpose before we go to the expense of building the real thing.

If it tests poorly, we still have room before the next phase to adapt without breaking the budget or messing up the timeline.

As with the discovery phase, we can use the alpha to estimate the work required in the next stage. Having a visualization of what needs building makes estimating the work required a lot easier for all of the stakeholders involved. They can see what they are being asked to build.

In addition, we can use the lessons learned from testing the alpha to adapt what we are going to create, once again creating space for changes in scope without derailing the project.

Once we have the alpha, we can then move confidently into the build, knowing that we will create the right thing and that users will respond positively to it.

3. Minimum Viable Product

I used to refer to this stage as the ‘build’. However, I found that stakeholders associated finishing the build with completing the project. In reality, digital services are never done, as they need to be constantly iterated upon to ensure they are as effective as possible.

To avoid this problem, I started to refer to this stage as the minimum viable product (MVP). In this stage, we build and launch the initial version of the digital service.

By referring to it as the minimal viable product, we emphasize that there will be a post-launch iteration. That provides us with a way of dealing with scope creep and unanticipated complexity by pushing it back until post-launch. That ensures the project stays on track and maintains its momentum.

Inevitably during the build, we will shelve some things until post-launch. These elements then become the basis for defining our final stage, enabling us to make an initial estimate for post-launch optimization.

4. Ongoing Iteration and Optimization

However, in addition to this work, there should be an ongoing process of monitoring, iteration, and testing that further refines the digital services’ effectiveness.

Estimating how much of this work you undertake should be based on the size and complexity of the digital service. Your estimate should also be proportional to the investment in the rest of the project.

By breaking down your projects into these four phases and completing each separately, you will remove many of the challenges we face when using traditional project management approaches.

Why Breaking Projects Down Works

Four significant benefits come out of breaking projects down in this way:

• Each phase is better defined.
  Because the deliverables of the previous phase define each stage, it means that there is a clear vision of direction. That helps stakeholders understand where things are going and avoids nasty surprises later.
• Projects are more accurately estimated.
  For example, instead of having to guess how long it will take to deliver a significant, nebulous project with a substantial number of unknowns, you are only estimating the next phase and doing so based on the deliverables of the previous phase.
• It results in better digital services.
  Because project ideas are validated and tested with users, you can be more confident that the final product will fit the purpose. It also allows room to adapt the scope and functionality between phases to ensure you deliver the best result possible.
• It is a less risky approach.
  The company commissioning the digital service does not need to commit to the whole project upfront. If the discovery phase fails to validate the project’s viability, it can be dropped with minor loss. Equally, if the alpha prototype does not test well with users, it can be adapted before things become too expensive.

This final point is reassuring if an outside supplier is being used for the first time. Instead of signing up an agency for a substantial project without knowing if they can deliver, the client can engage them for a discovery phase to see what they are like. If they are good, they can continue working with them. If not, they can take the findings to another agency with nothing lost.

If you run an agency or are a freelancer, you might think this sounds like a bad idea. Understandably you would prefer to sign up a client for the whole project. However, I have avoided many competitive tenders with this approach because the client didn’t feel they were taking a risk on such a small initial investment. In addition, they did not feel the need to speak to various suppliers because if they did not like me, they could easily switch.

In addition, using this phased approach will make scoping and pricing your next fixed-price project a lot easier. Sure, it will not magically provide an estimate or prevent scope creep. However, it will make estimating more manageable because you are only scoping one part at a time. It will also, allow you to work with scope creep, rather than trying to suppress it.

So my advice, whether you work in-house or externally, on big or small sites, is to stop trying to estimate and scope projects without breaking them down into phases. Instead, tackle one phase at a time and use what you learn to inform the next. If you do, you will estimate more accurately, have room for adapting based on what you learn, and find that project management is more straightforward.