What we build in Smartsheet, and what we ask before we build it

More Articles
Nick Mackeson-Smith
Nick Mackeson-Smith
Chief Curiosity Officer, Founder and Director

When someone gets in touch about Smartsheet the request is usually quite specific; they want a dashboard built, or there's a spreadsheet that has grown well past what a spreadsheet can reasonably carry and they'd like it done properly, or somebody on the leadership team has asked for a view of everything that's running and nobody can produce one without a fortnight's notice. All perfectly reasonable, and we can build any of it. The question we'll ask before anybody configures anything is what you want to be able to decide once it exists, because the answer to that changes what gets built rather more than people expect.


We're a Smartsheet Partner servicing Australia and New Zealand, Julius leads our delivery team, and the people who scope your solution are the people who build it. This is what the work actually looks like.


Getting to a number your people will use

Most of the data problems we're brought in on aren't shortages, they're disagreements, because the figure in the board pack and the figure in the team's own tracker have drifted apart over time and both are perfectly defensible given nobody ever agreed the definitions. So we start by getting the definitions written down and owned by somebody, and then we build the capture so the data arrives clean rather than being cleaned afterwards; forms with the fields that actually matter, validation on the ones that cause downstream damage when they're wrong, and required entries at the point where somebody knows the answer rather than at the point where it's convenient to ask.

What you get out of it is decisions made on evidence rather than on whoever sounds most certain, which is where most of the performance gain in this kind of work comes from.


Intake, approval and triage that people will follow

This is usually the largest piece of the build and the one that changes the most about how it feels to work there. A typical shape is an intake form that anybody can submit against, routing to a GM or a sponsor to approve or decline, then a triage step where somebody sizes the work and adds the programme, the type, the dependencies and the rough effort, and from there it branches; smaller pieces go down a fast track, anything substantial goes to whatever your version of a major initiative forum is called. On approval the project sheet creates itself from a template, populated with what was already captured, so nobody retypes anything.

We'll also build the templates that sit underneath it, usually a couple of work breakdown structures covering the different shapes of work you run, so a new project starts from something sensible rather than from a blank sheet and somebody's memory of how the last one went.

The efficiency is not really in the automation. It's in the fact that a request which used to be an email, three follow-ups and a conversation by the printer becomes one form and a notification, and everybody can see where it got to.


Portfolio views that hold up in front of a board

Once the work is being captured consistently the reporting becomes a build rather than a monthly ordeal. We put together a portfolio dashboard for the people who need the whole picture, individual project dashboards for the people running them, filterable reports so somebody can answer their own question without asking you first, and resource heat maps so you can see where your people are genuinely committed rather than where the plan says they should be.

The transparency that comes with that is worth more than the time saved, in our experience, because the argument stops being about whose numbers are right and starts being about what to do.


Knowing what you own and what you owe

The inventory question gets less attention than it deserves. Which projects are genuinely live rather than nominally live, which of them are dependent on each other, who committed to what and when, which systems you're still paying for, and which one of your people is the only person left who understands how a particular piece of it works.

When the work happens in one place you end up with an audit trail as a by-product rather than as a project of its own; every approval carries a name and a timestamp, every change to a date has a person attached to it, and nobody has to reconstruct the story out of a Teams thread and somebody's recollection of a conversation in a corridor. For a regulated organisation, or one carrying a governance obligation it takes seriously, that changes what you're able to prove about yourself when somebody asks.


The plumbing, which nobody asks for and everybody needs

Workspace architecture and permissions so the right people see the right things without anybody maintaining a spreadsheet of who's allowed where. Single sign-on and automated provisioning through your identity platform, so joiners and leavers are handled by the same process that handles everything else rather than by somebody remembering. Documentation written for the person who takes it over, and a sandbox your team can break without consequences while they're learning.

We also hand it over properly, which means training your people rather than sending them a video, and staying available afterwards on set hours each month so the small things get fixed while they're still small.


What we ask before we build

All of the above is fairly standard for anybody competent, so here's the part that isn't. We won't start building until we've agreed what we're measuring.

That means a short piece of work up front where we set out the current challenges in your language rather than ours, agree three or four outcomes with a measure attached to each one that you can actually collect, map how the process runs today including the step counts and the places people get stuck, and then set out what we'd build against it with the hours, the investment and the risks written down. Our own dependencies go in the risks section too, because if we need your people available and they aren't, that's a risk to your project and you should be able to see it coming.

It takes a couple of weeks and it makes the build smaller, which is an odd thing to sell but it's consistently true. It also means that when somebody senior asks what the return was, you have an answer that was agreed before anybody had a reason to be defensive about it.


Where to start

If you've already got Smartsheet and it's spread sideways without a design, or you're being asked to sign off a build and you're not sure what it'll change, our readiness review is the place to begin; a fixed fee, a couple of weeks, and a findings pack you can take to your executive team. And if the honest answer is that Smartsheet isn't what you need, we'll tell you that too.

Come and talk to us about what you're trying to decide, and we'll work out together what needs building.

Back to Journal
Enquire Us
This is some text inside of a div block.
This is some text inside of a div block.

Who to talk to at Five

Nick Mackeson-Smith
Chief Curiosity Officer, Founder and Director
nick@fivenz.com
Julius Goh
Digital Adoption and Data Solutions Lead
julius@fivenz.com
Loading
Five logo