Development is one of the areas I looked at closely when drawing up the operational plan. The way a website is built affects the cost of the project, the time available for other work and the confidence with which the business can sell its services.
I brought several changes together: using AI where it can help with implementation, improving content population, giving feedback a defined place in delivery and making the scope easier to recognise. The opportunity is spread across the whole process, including the work that happens before and after a developer builds a page.
Understanding where the time goes
The development section sets out an ambition to reduce build time substantially. It uses smaller brochure website builds as a reference and considers how AI-assisted blocks could help reach a shorter delivery target. Those figures are planning benchmarks that need to be tested against the requirements of each build.
I want us to understand the stages contributing to the total. Coding, content population, feedback and scope changes can all consume time. Improving one stage gives a better result when the rest of the delivery process can support it.
That is why the plan connects development enhancements to time tracking and budgeting. We need to be able to compare the estimate with the time actually used, then look at which stage or requirement explains the difference. That gives the next improvement something specific to address.
Using AI to help build blocks
The plan includes ChatGPT and GitHub Copilot as tools for AI-assisted block development. I want repetitive implementation work to benefit from those tools where the requirement is understood and the result can be assessed properly.
A block still needs to fit the website and the way its content will be managed. The work includes understanding the design, the content structure and the behaviour required. I want the time saved during implementation to be considered alongside the time needed to review, integrate and test the result.
Scope matters here too. A straightforward brochure build and a complex application make different demands. The internal pricing model in the plan considers AI assistance as one of the choices that can vary with the package and the work being delivered. It gives us a reason to choose an approach that fits the project.
Getting content ready for population
Content population is a substantial opportunity in the plan. Entering material page by page can become a large part of delivery, especially when a website has many articles, products or repeated content structures.
I proposed looking at imports and other repeatable population methods. The plan references article imports as an example of work that can be organised more efficiently. To make that useful, the information needs to be consolidated before population begins.
That preparation includes the copy, images and SEO metadata. Starting while those pieces are still arriving creates extra passes through the same pages. Bringing them together gives the population team a clearer task and gives development a more stable structure to work with.
I also want the method of population to be recognised in the scope. Importing a set of articles, entering products and populating bespoke pages each need their own preparation. They should be understood when the project is priced and planned.
Giving feedback a defined phase
Client feedback needs time in the project plan. In the document, I identified the risk of feedback consuming a significant part of a build without enough visibility of the budget it is using.
My proposal is to define the feedback phases and their limits, with project or account managers monitoring the remaining budget. BugHerd is the supporting tool identified in the plan. Its role is to make the feedback visible within an agreed process, with a clear point at which that phase closes.
That requires clarity about what each item means. A correction to an agreed requirement and an additional requirement have different implications for the remaining work. Recording that distinction helps the project manager understand whether we need to complete an existing commitment or discuss a change to scope.
The aim is a delivery process in which the client understands when feedback is needed and the team understands how it will be handled. It also gives us a way to carry the lessons from feedback into the next project, rather than repeatedly discovering the same unclear requirement late in a build.
Making scope easier to recognise
I included clearer website packages, ecommerce specifications and service agreements in the plan. Features can appear during a build which were not understood when the project was sold. If the team has to decide what was included while implementing it, the scope has left an important question unanswered.
Sales, account management, project management and development all have a part in that work. The package needs to explain what the client receives, while the delivery team needs to understand the complexity behind it. Page counts alone will not explain a custom integration or a more involved ecommerce requirement.
The handover is the place to bring those expectations together. The roadmap calls for the specification to be discussed with the team, including custom functionality and the challenges a project introduces. Budgets and milestones can then be connected to the work we have actually agreed to deliver.
Finding useful automation between departments
The AI section also looks beyond website blocks. I proposed identifying tasks that take a long time or are difficult to carry out, then understanding how the relevant department approaches them. Development needs that context to produce an automation that fits the work.
SEO is a clear example in the plan. Keyword generation and metadata imports are identified as opportunities, with a custom meta-importing plugin used as an example of tooling. These are specific parts of a workflow that can be examined, improved and connected to the surrounding process.
Once the useful tasks and tools are understood, the next proposal is to join them into everyday workflows or larger systems. I want those methods recorded in the process documentation so the team can understand what they do and how to use them. The document also flags AI reporting as an area to explore, rather than setting out a completed reporting process.
These enhancements give development a role in improving how the wider business works. As we implement the plan, I want us to keep returning to the time used, the work delivered and the experience of the people using the process. Those are the things that will tell us which changes are helping and which need more work.