In part 1 we looked at this question in a general context—what makes project pricing a challenge and lifting the lid on some general tips and guidance on getting more accurate estimates (spoiler alert: creating trust and providing confidence in what it will take to move a project forward, before tackling the £££).

In this second half we're taking a deeper look at our approach to project planning, and how that leads to better estimates of time, effort and, ultimately, cost.

Our Approach to Project Planning

Objective Setting

We have the least knowledge of a project's ultimate outcome during the discovery stage. It's impossible to know everything about the demands of clients, consumers and users from the start. Therefore, we define specific high-level business objectives which act as a guide to the project's development planning—these objectives provide clarity on what should be built and when, and, by informing lower-level targets, what should be achieved at each stage.

For example, is this a new business opportunity which needs testing with a minimum viable product (MVP)? Are you preparing to take your business to the next level by expanding an existing product or service? Or are you overcoming an existing operational challenge? If we can begin to understand the answers to these unknowns, in the context of high-level objectives, we can start to explore more concrete deliverables.

The Essentials

In broad terms, these are the specific, must-have features required to meet your desired users' needs—a short list of essential requirements which will determine the success of the project because they answer the high-level objectives outline in the previous step. The are the essentials which your users will need to be able to use the project's overall outcome successfully.

Again, there's always a relevant XKCD. Source: https://xkcd.com/1425/

Desirables and Potentials

If essential features solve a problem (or problems), desirables and potentials should be considered as the cherries on top of the proverbial cupcake...

Desirables are those features which are not essential to the success of the project outcome, but will those which will surprise and delight your users. While important, these can be de-prioritised if absolutely necessary, but should remain as targets wherever possible.

Potentials are things—features, functionality, or architecture considerations—which could be useful at a later date but which offer little to no immediate return on investment, or that are otherwise not important during the initial scope of development. While potentials are worth identifying now, they should only act to inform discussions around future scalability or from future success criteria.

Solution Architecture

After setting objectives and defining essential, desirable, and potential features, we move on to finalising the solution architecture best-suited to accommodate those features and achieving the objectives.

Solution architecture involves understanding the logical relationships between features, planning the architecture of each layer, and identifying how those layers will be developed—essentially beginning the process of allocating development resources to the project. Solution architecture is vital because it will inevitably identify complexities which need addressing from a technical perspective before we can move on to implementation.

For example: a project with only a few essential requirements may require a simple data migration from an existing solution to a new environment—with no integration to existing systems. However, an increase in the number of essential requirements may require more complex data transformation and integration with legacy applications, which will affect how we implement features, structure the application code, and provide for future scalability—perhaps even necessitating a requirement for user training or dedicated, ongoing product management.

Side Note: Agile Practices

In our experience, large projects are much more likely to be successful when they progress in an agile, fashion—i.e. built in smaller iterations of work delivered over a number of sprints. This allows us to put the project under close scrutiny and gather feedback from stakeholders at regular intervals throughout the development process, and allows for early detection of issues which could jeopardise the deliverability of the project, with feedback helping to shape future sprints.

Release Planning

Once a proposed solution architecture is approved, We will then start planning delivery stages, or sprints, with lower-level features mapped to each. This is a more definite release plan covering the broken down by release date, including a number of gates which cover a feature, or set of related features, which must be accomplished to consider that stage complete.

This is entirely dependent on the size and scope outlined by the essentials, desirables, and potentials, and our estimation of our team's capacity to deliver well-written code which satisfies those deliverables and achieves your essential business requirements.

An alternative scenario is where delivery dates are not clear but that an initial budget has been approved. We will then use the objectives and feature lists to propose a timeline to deliver based on our development capacity for the given budget. This is often called velocity planning—how quickly we can move a project forward given the rate at which we can develop specific features.

The True Cost

At this point, you should have a better idea of where your money is going, what your delivery timeframes are likely to be, and how much it will cost—the "true" cost. However, there is still the potential for factors to arise over the lifetime of the project which may impact this.

Planning for Risk and Uncertainty

As with all approaches to development projects, both release planning and velocity planning carry a certain level of risk and uncertainty, but this can be mitigated by adding buffers in the planning process. Buffers in release planning typically take the form of specific desirable features which should be prioritised, with lower priority features moved to later stages as required. For velocity planning we typically include a time buffer—where gates may be completed early or delayed—and re-adjust the following gates accordingly.

Summing Up

Hopefully these posts have provided you with some insight on how we plan, estimate, and define a price for our project, and begin to answer the question of "how much..."

Ultimately, our aim is to put our clients' minds at ease regarding what it will take to progress a project by, first and foremost, establishing trust and providing confidence in your decision to move forward with a development project.

Drop us a message to discuss your next project.