Project Management and Process

TeachIt, based in Bath, runs a subscription service for teachers who download teaching and homework material. The product was not the emergency. The way work got into the product was.

Internal and external teams were not getting work done correctly or on time. Requests arrived without enough information, the backlog grew, and the development team were left guessing what “done” looked like.

When we sat in the meetings, the process itself was the bottleneck. It was long-winded, it did not give developers what they needed, and new ideas kept landing on top of unfinished ones. Everyone was busy. Very little was finishing.

TeachIt asked us to improve communication and efficiency, not to throw the site out. Until the work system was calm, there was no point talking about new features or new revenue. The backlog was the product.

We ran the conversations needed to see where work was actually getting stuck, then changed the operating rhythm. A weekly meeting reviewed every issue, decided what mattered, and gave the development team only a week of work at a time.

New requests needed a proper specification. That single rule stopped vague ideas turning into half-built tickets. Once people had to write down what they wanted, a lot of requests simply stopped being important.

Over six weeks the backlog fell from 237 issues to 18. The team was no longer overloaded, and the work that remained was the work that deserved to be there.

With the noise gone, TeachIt could look at the site itself: fewer bugs, more improvements, and space to create new revenue streams. Process first, product second, which is often the only order that actually works.