How To Price Projects And Manage Scope Creep

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.

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 #

• 120+ native React UI components fully compatible with Next.jsTRY KENDOREACT

The post-launch phase deals with the functionality, complexity, and other issues that we did not address in the MVP. This list of improvements is relatively easy to scope by this point and can be estimated with reasonable accuracy.

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.