mbranch SIA FqvB

Work / Task Manager

Task Manager

A planning tool for a team that had outgrown a shared spreadsheet and disliked every product they trialled.

Client
Under agreement
Type
Internal web application
Platforms
Web
Our role
Design and build
Team
Both of us
Status
In service
Placeholder view of the Task Manager board
View one: the board, with column limits and the current sprint in progress.
Placeholder view of the Task Manager schedule and workload
View two: the schedule, with committed hours per person and today marked.

Both views above are placeholders drawn to the real layout. They will be swapped for screenshots once the assets land.

A spreadsheet had become the source of truth, and it was lying

The team came to us with a shared spreadsheet, four colour conventions nobody agreed on, and a habit of promising dates from a tab that was three days stale. They had trialled four commercial products and abandoned all of them, mostly because each one insisted on a way of working they did not have.

We started by copying the spreadsheet, badly, on purpose. The first version deliberately did nothing the spreadsheet could not do, so the team could move across in an afternoon without learning anything. Everything after that was added because somebody asked for it during a fortnightly review.

The board is the part people open in the morning. The schedule view came later and changed how the team quotes work: it puts every person's committed hours against the calendar, so a date is either possible or visibly not. That single view ended most of the arguments about capacity.

It runs on the client's own infrastructure, with a small footprint on purpose. No seat pricing, no data leaving the organisation, and an export that produces a plain file rather than a proprietary archive.

What we would do differently

We added notifications early because it seemed obvious, and then spent weeks tuning them down. Nobody wanted them. On the next tool of this kind, the default is silence and people ask to be told.

Next step

Thirty minutes on a call tells you more
than any proposal document will.

Bring the problem in whatever shape it is in. Half a spec, a spreadsheet that has outgrown itself, a codebase nobody wants to open. We will tell you what we would do first, and whether we are the right people to do it.

  • No sales call, you speak to the developers
  • Thirty minutes, video or phone
  • A written summary from us within two days
  • We say no when the fit is wrong