Return to site

10 weeks is a long time in software development

Ways to save time and money on a project, and still meet user needs

Lessons from a project with the National Childcare Trust (NCT)

For a recent project we had long list of things to do, and not enough time to do them, a familiar scenario to everyone I'm sure.

We've written up some of the steps we took so that other people can apply these tips to their own fast-paced digital projects.

The Background

With over 100,000 members the NCT is the UK's largest charity for parents, providing services ranging from educational courses (such as postnatal care and baby first aid), through to running events like Nearly New Sales (where parents can save money when buying child related essentials such as prams and clothes).

The NCT has main offices in Bristol and London with full-time staff. Otherwise all the branches (300 across the UK) and events are entirely run by 1000s of volunteers.

We were asked to build a system to help the NCT manage their finances and events. We only had 50 working days to do this, in order to comply with the NCT's internal deadline for this project.

As the timeframe was so tight we were actually given the option to conduct research and produce plans for building a system.

As a rule we feel that a bird in hand is worth two in the bush (i.e. actual software is better than ideas for software), and that 50 days is quite a long time - so we said we'd see what we could get done for the NCT in that time.

1. Start and end with user needs

First things first, you have to know which side your bread is buttered. There are people relying on the products you build, if they're not happy, then you haven't done a good job. It's as simple as that.

In this case the user needs were quite straightforward, there were just lots of them. The NCT already had an existing process for every feature we were being asked to build, and we were able to see how these worked.

A common user story might be, 'Anna is a volunteer in the Cambridge branch, after spending £80 hiring the local hall for an event, she wants submit an expense claim, know when it is approved/rejected, and when she will be reimbursed'.

It would have been nice to do a bit more 'discovery' and see if there was any scope to modify and update these processes, but that was a moot point, as there realistically wasn't enough time to do user research, propose new methodologies, get universal buy in, and then build these out.

The list of ideal features was as follows:

- Import existing data into beta system where available (e.g. volunteer data, customers, suppliers)

- Associate users with their correct regional branch
- Support different user permissions (volunteer, treasurer, admin)
- Create a purchase
- Create an expense
- Create an invoice
- Allocate transactions above to the correct regional branch
- Approve and reject transactions (treasurers and admins only)

- Integrate system with NCT Bank account data

- View bank data per branch
- Reconcile bank transactions
- Create an event (e.g. Nearly New Sale)
- Sell tickets to events (via Sage Pay)
- Email alerts (notifications when items are approved, rejected and so on)

If we managed to do the list above we'd have built the whole system, so the question was, what could we build in a 50 day beta release?

2. Decide on the essentials

On the first day of the project we asked the client to picture that the project had finished, and that Day Digital had handed over their new system.

The client pictured themselves logged into a new system, in which some of the requested features were there, and others were not (they could always come later of course), so which features could the NCT not live without and why?

This proved to be a great discussion as the client were very receptive and pragmatic (a lot of people would try and dodge the bullet by insisting all 10-20 features are top priority, and that they are all equally important).

It was clear that for example reimbursing volunteers would be 100% essential on any system (as this kept the majority of the user base happy, and there was no workaround). However a lot of the banking features were only going to be used by a handful of people in the head office, so were not of immediate interest to volunteers (i.e. the vast majority of users).


On our side we were keen to point out external dependencies (i.e. things we cannot control), such as data migration, integration with banking systems, and also integration with SagePay (for selling tickets to events) were the most 'risky' items. These were effectively unknown and therefore until we started working on them, it would be harder for us to estimate these features.


We lowered the priority on banking, and also data migration (as this was a beta system), so it was more important to get people excited and have a feature rich beta product, than spend hours and days rooting around making sense of legacy systems in the hope of finding usable data.


From there we agreed on what would realistically form the scope of the 50 days.

3. Don't re-invent the wheel

When embarking on a project, a lot of people (particularly specialist agencies) like to put their stamp on things, and shudder at the thought of using someone else's work.
 

We believe getting the job done is the most important thing.

Given that the NCT were requesting what seemed to be a standard finance system, prior to winning the project we actually suggested they consider an off the shelf tool such as Freeagent or QuickFile (thus talking ourselves out of a potential project).

It turns out that the NCT had already done the due diligence on this approach, and found that the per user costs of paying for 1000s of volunteers to use a system would not make sense.

Knowing that we were going to build a web application in very tight timeframe we decided to leverage an existing Bootstrap template, as pretty much all the elements you'll need (data grids, filters, pagination, buttons), and more have already been done for you, we couldn't afford to spend time going back and forth over designs.

When building software it's best to be pragmatic, as quite frankly your users will often not care about finer details (i.e. 'Is this screen a template or has an agency spent weeks designing this?') as long as they can do the things they want.

4. Go with the leanest possible team, and include all rounders!

This may sound counter-intuitive but often a small team is better than a large team when you're up against it. When every day counts you want to be building software, not having meetings and discussions. The old cliché below holds as true as ever.

Nine people can't make a baby in a month. Brook's Law

We decided we'd be better off with a team of just two people, who would be very strong at the essentials, and could also turn their hand to everything else that was needed.

Backend Developer = Make technology decisions, architect, build, deploy, and test the system, participate in user testing.

Product Manager = Analyse client needs, produce requirements (including wireframes), drive the project, make decisions on priorities, gather user feedback, handle all client communications.

In an ideal world you might have multiple specialists on this type of software project (pick 5 people from Business Analyst, User Experience Specialist, Visual Designer, Front-end Developer, Back-end Developer, Software Tester, Architect, Product Manager, Account Manager). These specialists would certainly be stronger at a number of the tasks given to the core team of two (such as wireframing, documentation, front-end development, and design), but we decided we'd be overcomplicating things with a larger team.

The more people, the more opinions, the more meetings, the more clarifications, the more back and forth over every decision, and also room for misunderstandings. With any client (and especially a charity) value for money is important, so we decided to go with specialists in the essential areas who could also turn their hand to other tasks.

5. Get it done. It can look nice later.

An obvious 'weakness' with our chosen team was going to be design and aesthetics, however everyone was agreed we were going for style over substance in this project (this being an internal finance system after all).

If we put one of our designers on this project, they might need 2 weeks to produce and iterate designs. Would we reject features such as expense forms for not meeting design requirements? (probably not, so we decided this would not be a priority in the first place).
 

In week one the product manager produced the wireframes (so that we were on the same page as the client), this saved time/money vs having lots of people involved - and also meant our team was focused on the task in hand.

A basic wireframe (produced by a non-designer), it still does the job.

The wireframe turned into actual software via a Bootstrap template.

When you have a list of features to get through, the key thing is to get them done, and get them user tested. You can always iterate later.

By focusing on building features and not getting distracted by other possibilities, you get things done.

If you want to get things done quickly, you have to make tough decisions fast.

(Back to the most important rule)
1. Start and end with user needs

We had been allocated a single person from the NCT who would effectively be our user tester and key stakeholder. On a 50 day project there wasn't really time to have too many people involved. Each sprint our stakeholder had been happy with what we delivered.

We felt it would be better to involve more people nonetheless, so our team helped set up a user testing session and went over to Bristol to spend half a day with 5 different people (see graph below for why 5 is a good number) testing some of the key scenarios of the beta system (creating expenses, setting up suppliers, invoicing a customer, creating an event and so on).

"Zero users gives zero insights." - JAKOB NIELSEN

The user testing did throw up some interesting surprises, as it always does (see here for a blog article we wrote on user testing).

For example no one noticed our tooltips, so we made these bigger/more colourful. We thought we'd made creating tickets for events really easy by pre-populating all the ticket types, but 2 out of 5 people didn't notice these either (so we changed the navigation slightly to make it more obvious).

User testing feedback: 'It would be helpful if we had tooltips'
People didn't spot we already had tooltips in the system (the grey 'i' icons) during the first round of user testing!

So we changed the colour to blue and made them bigger next time around.

The 50 days are up...

So what did we get done?

The original list of requested features, and how far we got with each one.

The log-in screen of the Beta system

Volunteers: can create transactions (expenses, purchases, and invoices), and also create events.

Creating transactions: Text in each box guides users on how to fill these out correctly.

Treasurers and admins have increased permissions, they can approve/reject transactions, and also view banking pages.

Whilst not fully integrated with real time data, we were able to provide limited banking functionality within the 50 day beta.

Creating an event is simple and easy in the beta system.

Sage Pay integration was very easy, so [using test credit cards] you can actually buy tickets to events.

Final thoughts: What could we have done differently?

With any project (even ones that go well) there's always things that could go better. We had a team meeting to debrief on the project, and also one with the client. Overall the thoughts at both meetings were positive (including the quote below)...

'As the project owner, I could see things were heading in the right direction, and could also show progress internally, which was good for everyone's confidence' - Thom from the NCT

That said a number of things came up that we felt we could learn from, and potentially do differently next time:

- Dedicate at least some time to development tasks and tools
We basically went full steam on features for the client (see point 1 on meeting user need), and skipped these kind of tasks wherever possible. That said there's always an argument for working on tasks that make your own life easier, even though they do not directly result in a client feature being built.
If the project was longer we should have paid more attention to code refactoring, unit testing (automated testing of the product), and leveraging more continuous integration tools for deployment.

- Maybe use Jira over Trello for project management
Trello is less feature rich in terms of tools for estimates and sprint planning than JIRA, we couldn't decide whether we liked this or not, it made life easier at times, but also less structured.
On a larger project we may have been caught out, common sense prevails though... when the team is only two people you can just pick up the phone and speak to each other!

- 'Above and beyond' features to get people more excited

We'd have loved to have put some features in the product that went way beyond user expectations, as this gets people really excited about a system.
e.g. have the landing page as a dashboard, use more graphics/charts/data visualisation in the app, or maybe even include alerts (e.g. reminders for Treasurers to approve/reject items).

We discussed these with the NCT, and they (quite rightly) preferred that we stick to the tasks in hand (the irony wasn't lost on me, as I'm usually the one espousing dogged focus on key features in client meetings, project planning, and blog posts like this one). 
That said it would have been nice to give people something they weren't expecting, and if we'd have had just a few more days, we'd have put something in.

- More structured updates to the client

The NCT were very happy with our attitude and work (i.e. we 'focused on results, not meaningless charts and updates') that said, after the project, with a bit of cajoling to give us constructive feedback we were told we could have given more structured updates.

Throughout the project (once we had 'broken ground' so to say and there was something to see) we gave the NCT access to the system, agreed a weekly plan, and then had a walkthrough of the new features we had created each week.
This feedback was valuable and we've taken it on board, we'll now give a few different options to clients at the start of projects to see how they'd like us to handle progress updates.

By David Fallon

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly