You've got a great idea for a product, or app or service and you need to make some software for it. But, you don't have a software development team, or your current software development team is barely able to keep their head above water. Oh no!
Have you considered hiring a software agency (says the person from the software agency)? Chances are, if you're here, you already have.
But, if you've never worked with one before, it might be a little daunting as to how to engage one. Of course, most agencies will be happy to walk you through the process. So here's our take on what the process will be like and what we look for in a project.
Just a note, this is a long post and is really meant to help you prepare for engaging an agency. If you're here looking for an easy, quick answer, you can stop reading now. Just hire Rocket Insights 🚀😊
If you're really serious about things though, read on. The more you have answers to the questions you have below, the better, but don't be afraid to admit when you don't know the answers. If you're able to answer every question in this post, you are in excellent shape, my friend!
We'll meet you and get an overall sense for your business and the problem (or problems) you're trying to solve.
- Are you a new company or how long have you been around?
- Are you an old hat in your market? Breaking into a new market?
- How many employees do you have? How much revenue are you pulling in? How are you funded?
- Have you worked with a software agency/consultancy before?
About the Project
We'll then dive into the specific project you want help with. We'll ask things like:
- What's the high level overview of the project?
- What's the broader context for why the application is going to be developed? How did the idea come to fruition?
- What business goals will the project achieve?
- What are the various user types that will use the product/app/what-have-you and what will they do?
- Do you already have User Experience (UX) designs for the project or do you need help with that?
- Who are the stakeholders inside your business? (Just roles, names aren't important yet)
The Technical Details
As we move along in further meetings, we'll start asking you about more detailed technical questions.
If you don't have a technical team, don't sweat this one. We got you. But, if you do, we'll ask things like:
- How many engineers do you already have?
- Do you have system administrators or DevOps talent? Will they be available to help with this project or are you looking to have us deploy the project?
- Do you already have a Cloud Provider of choice? Are you On Premise?
- Do you have build pipelines in place for your software?
- What languages or frameworks is your engineering team already using?
- Are you open to using new languages/frameworks/technology?
Getting the Project to Users
Ok, so we’ve developed the app, but at the start of the project a lot of people don’t think about the logistics of delivering the project to users. We’ll ask questions like:
- Who will be testing the project? Do you have your own Quality Assurance (QA) team? Do you want us to do that?
- You'll want someone to User Acceptance Test (UAT) the project, who will that be?
- Do you already have an idea of how you want to roll the project out to users?
- Are you open to doing small, iterative rollouts to get feedback from users? This is the best way to release software as you don't go too far down a wrong path and spend too much money on the wrong thing
The Often Overlooked Stuff
This is the stuff that often gets overlooked when starting a new project. If you have answers to these things, you are well ahead of the curve, but if not, start thinking about them now!
- What sort of administrative requirements do you have - Things like reporting dashboards, auditing, onboarding new users, ability to manually correct mistakes.
- What kind of external dependencies does this project have. In our experience, external dependencies are usually the things that make software projects take forever. An external dependency is anything outside the purview of the organization driving the project itself. This could even include a sibling group in the same company. Here's some examples:
- Relying on an overworked DevOps/Sys Admin team with no capacity to deploy new software
- Reliance on a vendor for an API or some kind of data
- Downstream systems that require the data that will be captured by the application
- Regulatory approvals necessary to deploy the application to real users
- Who from your business will run point on unblocking the development team on business decisions? Lack of a dedicated business champion to push the project along is another typical killer of project timelines.
It's also important to be able to address how success will be measured. This could be ROI, process efficiencies, or even just gathering user feedback. Regardless of what it is, know what it is so that we can measure it.
And finally, have a clear understanding of what you want to have happen after launch. For instance, do you have staff to support the application? Do you need help with training? What about marketing the product? These are all things we can help you with, but at a minimum you should know how you’ll support these things yourself.
When do you need the project done, ideally?
Be honest about target dates versus deadlines. What's the difference? A target date would be you, or your boss, or some C-level executive saying "This project needs to be done by end of year" without any other reasons why.
A deadline would be a regulatory requirement stating something needs to be done by a certain date. Or, you need to have the product ready to demo by a trade show on X date.
If you really have a deadline, be prepared to discuss which portions of the scope can be adjusted or slip if necessary. Pleasant to talk about? No. Necessary to plan for, yes.
Do you have a specific type of team already in mind? Are you looking for more senior people? Are there any specific requirements for them to be a part of your organization like being authorized to work in the US?
Finally, we'll talk about the budget. Things like:
- Do you already have the budget secured for this project, or are you looking to get an estimate of cost?
- If you do have a budget, what is it?
- Are you looking for a fixed bid project or time and materials? (Rocket usually bills as time and materials)
- Are all your internal stakeholders bought into the project or do you expect any pushback getting funding or while the project is in development? This doesn't scare us! We just want to know what to expect.
Once we have some or most of this information, we'll tell you what we think it would take to complete the project in terms of timeline, budget and possible scope reduction and we'll go from there. If you like what you see, we’ll get the contract process started!
Design Sprints further shape your project idea and test it with users to help get you started. Architecture Sprints take a project's functional design, and start diving into a plan for how we would engineer the project. They're both great ways to start to dive into a new project without fully committing to a whole development team starting in earnest
There's a lot that goes into even the smallest software project. We hope that this article helped get your mind going on what it might take.