Let’s talk
Washington DC is full of government agencies and non-profits. It’s also home to a thriving startup community and some of the best web and mobile app developers in the world. Your budget might be tight and your policies restrictive, but you can still tune in to this frequency and develop apps as quickly and effectively as a lean startup.
^ An example of an app we developed 'like a startup' with AARP
A few years ago we didn't know our ideal customer. Our best app development work was with startups, where mobile apps were in demand. Meanwhile, our most stable long-term customers were large non-profits like Special Olympics International who wanted database management systems. We were worried we were stretched too thin, trying to be all things to all people.
Thankfully we stayed the course, and patterns began to emerge. It dawned on us that our diverse set of customers were not all that different after all, and neither were the projects. They share an important trait—they see the pain and they envision a better way. This innovator, the entrepreneur—or just as often, the "intrapreneur" within a larger organization— can see the future.
So why do you really care about this? What problem are you solving? What is the goal? Who are you trying to help?
For example, you might see the frustration in your people because they’re wading through paper or endless Excel docs, or maybe there are just too many people repeating data-entry and report generation. The dollars are disappearing and your best staff are wondering when and why their workdays started to suck. But you know there’s a better way of doing something, one that takes less pain, less time, and less support, meaning your employees (and perhaps volunteers) could be spending more time doing what they enjoy and, ultimately, making you or saving you more money.
Yes, you may have a “what” in mind. Maybe you really want an app with real-time updates to prevent duplicate entries or a custom digital filing system to reduce paperwork. It isn’t bad to have specific features in mind, but allow them to change, because solving the problem is the most important thing.
If you haven’t read Simon Sinek’s book Start with Why, I highly recommend it. It’s mostly about galvanizing your team based on your company’s raison d'etre, but it also applies to user experience.
In order to get a project moving, you’re going to need some allies. So, if you’re not doing this already, start being nice! If you call the shots yourself, than you won’t need this (please still be nice!), but otherwise ask for advice from those who have a voice in your organization, or have been around long enough to know how things work. Better still, ask for their opinion, explaining the “why” again. This provides them a sense of ownership in your success. The red tape of large organizations is a lot easier to navigate if you’ve got the inside scoop, and selling the idea is much easier if you’ve got a champion on your side already.
When you’ve got the backing, it’s time for an RFP, right? Well, not necessarily... A lot of folks don’t realize this, but there’s usually a threshold for requirement of an RFP. At the non-profits we’ve worked with, that number is $150,000—and you can get a lot done with that budget if you play your cards right (see below). The RFP process is costly for everyone involved, and so many assumptions are made, without due process. Your development team should have the experience to help guide some of the big decisions, and you’re losing about by not involving them in the planning phase. Start small, and let your users drive the next phases once they have something useful in their hand.
One last note regarding RFPs: the best app development companies firms do not waste their time and ultimately your money on formal RFPs. They focus all their energy on what’s most important. New clients seek them out, not the other way around.
This part is not easy: assemble or hire app developers. Find a team you can trust, or find an individual to recruit and run that team if necessary (since you’ve landed on the 3Advance blog, you’re doing something right!). Personal recommendations are best, past work in the non-profit app development space is vital, and good chemistry will be crucial for the difficult decisions ahead.
Now just because your development team is agile in nature and process, that doesn’t mean you can’t set a budget and define expectations. It does mean you have the ability to change requirements as you learn more, and you actually get to see results sooner, and more often. This will put your mind at ease and keep your brain in the game.
Take time for the discovery process and user experience design. You can do only this if you’re still courting your app development agency and not ready to take the full plunge (it will probably cost you a lot less than that RFP process). Ask questions, listen to answers. Interview those who will use the app, and then under-promise and over-deliver. We learned a long time ago that our goal was not just to develop applications but to make heroes out of those who have put their trust in us. Honestly, you deserve it.
So work with your app development team through the user experience process, and make sure the first deliverable is a well designed clickable prototype. As well as getting stakeholder buy-in early, it allows you to realize what's most important, what's less important, what's too costly or untimely.
Allow mistakes to happen and for your assumptions to be wrong. Remember the "why" and don't lead your dev team down a rabbit hole when it's not necessary.
Get over the finish line. Go live with less. Go. Live. Run a pilot, do it for real. Only then can you get real feedback. Test, listen, iterate, improve.
Sometimes our clients want to reach perfection before launch: include everything, exclude nothing. MVP stands for Minimum Viable Product. This is not a buzzword. This should be your target, in as short a time possible to achieve your goal (the “why”).
My favorite phrase is “That can be Phase 2,” not just because it means we'll keep working together, but more importantly it means that you're focused on MVP and preventing distractions from affecting success.
Lots of software projects fail. I was shocked when I realized that the United Airlines app, with the massive technology budget they must have, doesn’t allow me to check-in. Feature bloat at it’s worst (that all must be versioned and maintained). But the single most important thing doesn’t even work. Some things are unacceptable. Don’t be that app.
Your risk of failure increases when you try to do too much, especially too soon. It’s costing you much more, and you're asking your users to understand layers of complexity right off the bat. If Facebook (or even the iPhone, arguably, but that's for another post) was released today as is, it would fail horribly. Early adopters and new users need to understand things quickly or they'll move on. You can add the bells and whistles later, but for now, do the simple thing really, really well. Remember: under-promise, over-deliver.
Also, know that you're embarking on a journey. It doesn't end when you go live, it just begins. So make sure you have the budget to back it up. You'll (rightly) decide to skip some things initially, and roll them out in phases later. So be ready. Plan for success, and know that success is when your users ask for more, not less.
Now go make your people happy again!
