Our discovery process: Why projects succeed at The Code Company
As a software development agency, we’re all too familiar with the risks and challenges of being an outsourced engineering partner for digital publishers and enterprise organisations.
The single biggest risk with large scale engineering projects like replatformings, new builds or complex data migrations, is for the development team to underestimate the complexity involved or effort required. This means the real cost and timeline of a project is not clear until the project is mid-flight.
This has serious impacts on the proposed budget and deadline. As an agency partner who has been entrusted to deliver a project, we strive to get the cost and timeline as close to perfect as humanly possible. It’s a widespread problem too. According to a 2021 study by McKinsey, 69 per cent of digital transformation projects fail. The study reported that unclear objectives, lack of alignment, poor planning and poor execution were contributing factors.
The challenge with by-the-book Agile project management
We’re big fans of the Agile project management methodology, and have been adopters for over a decade in different capacities.
The biggest challenge with a lot of “pure” Agile projects is that they rely on strict governance of budgets and resources on a sprint-to-sprint basis. This creates a unique challenge for agencies who typically have a signed contract with a client for a fixed budget or timeline.
For example, on a 6-month project, a project manager is required to manage an entire backlog which may have simplistic Fibonacci or t-shirt size estimates. At the same time, they are accounting for adjustments to tickets as they are refined and enter a sprint.
How we do things differently
With more than a decade of experience delivering software, The Code Company has fine-tuned our process to mitigate as many of these risks as possible.
This involves front-loading a lot of the work into our Roadmapping process during the discovery phase.
Sales
In the sales phase of our relationship, we’re trying to work out if we’re a good fit for each other, and based on our experience of delivering WordPress to enterprise organisations and digital media companies, if there’s a way we can make the relationship beneficial for both parties.
Crucially, we don’t estimate work or break down functionality at this stage. Our proposals will typically have a fixed price for an initial discovery and roadmapping mini-project, along with an anticipated budget for the delivery.
Discovery
As the name suggests, we take discovery quite literally, and it is during this period that our team will take the time to understand what external dependencies may affect the roadmapping and subsequent delivery of the work.
This can take the form of tasks such as:
- Understanding an existing CMS data structure in order to design a migration.
- Studying an internal API that is crucial to the new project.
- Working with a design team to interrogate a new site design.
- Reviewing an internal bespoke CMS’ editorial controls to adequately factor in feature parity between the legacy CMS and a new WordPress deployment.
Roadmapping
More often than not, most people come to us with some key deliverables or goals in mind without considering all the work that is required to get to that key deliverable.
A roadmap details the full specification of what is to be delivered, and leaves no room for ambiguity or assumptions. Ideally, this can be done in a physical setting, but is also achievable in a virtual environment.
Team-led scoping with all stakeholders is the single greatest way to get buy-in from those stakeholders, and a shared understanding of all of the work required to deliver a project.
Simply put, roadmapping uses a range of coloured cards that have different meanings. From “deliverable”, “context” to “unknown” — these cards fill up rooms (or virtual whiteboards) with every single element of the project that needs to be delivered.
Roadmapping Part I: Breakdown
The team starts breaking down these requirements into more digestible and tangible segments. This is an intensive process, often taking days, between the project team and client.
The team engages in debate, brainstorming, and scrutinisation in order to properly break down requirements into clear and actionable tasks. We rely on the client to provide the input we need in order to understand the full extent of a requirement.
What seems like a simple requirement, such as “We need a notification bar in the navigation area of the website that displays messages” can be broken down to cover things like styling, functionality and business logic.
While this can seem needlessly arduous, it establishes what work is involved in this single requirement that would have otherwise been highly ambiguous and open to interpretation by everyone on the delivery team and client team.
Roadmapping Part II: Organise
As requirements are broken down, they get closer to becoming tasks. The team then starts to group these into categories. We’ll often start to identify similar or duplicate tasks in these categories, which might for example be a shared feature in different areas of a website.
By identifying this, we know this is really a single task that has multiple use cases. During this process, categories will sometimes break out into further categories with accompanying tasks. Eventually we refer to all these finalised categories as Epics.
Roadmapping Part III: Estimate
With a complete board of epics, tasks, and use cases, the team can as a group begin estimating on a task level. Lead developers, front-end developers, and back-end developers each provide their estimate for a task, with lead developers scrutinising each estimate to make sure it’s as accurate as possible.
It also acts as a forum for client teams to get involved and give their say as to where resources are allocated. Roadmapping allows you to move features “below the line” which essentially acts as a future icebox / phase two.
The outcome of roadmapping
The completed roadmap is clear documentation that confirms a shared understanding of a project scope.
It confirms the agency’s workload, estimates, and gives clients full visibility into how much time and budget is allocated to each feature.
As a strategic document, it can help identify any overlooked elements and makes it easier to show how changed features or priorities will affect the budget.
This approach not only safeguards against scope creep and budget blowouts but also fosters a transparent and collaborative relationship with our clients.
Ultimately, this rigorous upfront planning translates into successful project deliveries, satisfied clients, and a reputation for reliability in a field often fraught with uncertainties.
Need an agile WordPress team for your project?
