.svg)
You have an idea for a software product, but you’re not a programmer and don’t have much tech experience—the first few questions that pop-up likely are:
- How much will it cost?
- Who to trust and hire?
To answer these questions, you first need to consider the preparation that goes into planning to ensure your project is set up for success. Think of software as a living, breathing organism that needs to be taken care of over time. This organism needs special skills to define, build, evolve, and grow. You, the owner of the software, are the torch bearer with the vision, but you can’t win this battle without a formidable force behind you—the software planning and development team.
When software goes south
Every single week, a software owner will come to me and complain they’ve fired their software development team and are looking for an agency to salvage the code they have. This isn’t necessarily the fault of the development agency; it’s mostly due to a lack of communication and of understanding what’s needed to satisfy the goals of the software. If proper scoping (the definition of requirements) isn’t done up front, the result will be a slow-sinking ship.
Underestimating the importance of up-front planning and it’s lack thereof is the number one culprit for failed software projects. As a wise man once said, “failing to plan is planning to fail.” If things are planned well, half the battle is already won. Planning grows your software in a methodical, controlled way. On the other hand if things are not planned well, your software project will grow like an uncontrolled weed.
Thankfully, with some understanding of the planning process, you can save thousands of dollars and hundreds of hours of time and stress.
The pitfalls of poorly planned software
I am sure you have heard or read about horror stories of software projects getting out of control and you might be wondering what could go wrong? Here are a few things:
- You could end up spending thousands of dollars and still not have a working product.
- You might miss your deadline: you wanted to launch in June, your users are waiting to use your product, then suddenly it’s November and you still don’t have the software ready.
- Or you may have to start over from scratch because of a poorly planned foundation of code.
I hope I have emphasized the importance of planning well before even getting to development and you might be saying, “Please tell me how to avoid those disasters”
Well, that’s what I wrote this article for, here we go.
6 components to software planning & estimation
With planning and estimating software, there are several components that will need to be defined and understood before starting development. The following components will serve as a source of truth to all parties involved. It will allow you to ensure that everyone has the same vision when picturing the application in its finished state. Think of these components as the “blueprint” of the project. You can’t build a stable building without a proper blueprint and the same goes for software.
1. Integrations
A large percentage of people looking to have software built want to pull in data from third-party sources. If this is the case, the team doing the estimation should look through the API documentation of the third-party source to identify if it’s easily understood, if there is a cost for the integration, and if it has the capability to accomplish what you need.
2. Requirements
Functional requirements are descriptions of the features within the software. Requirements convey the expectations of those who will be using the software. The requirements can be obvious or hidden, known or unknown, expected or unexpected from client's point of view. Besides the functional requirements, there are non-functional requirements that need to be considered. For example: mobile responsiveness, secure protocols for communication, etc. These may seem like "standard" things to have, but if not specified explicitly, the project estimation team may not consider them. As a client, you should not have to explicitly require these—a great agency will distinguish itself from a poor one by asking you these questions.
3. User stories
Each requirement should have a story behind it—of how the feature will be used. User stories are short, simple descriptions of a feature told from the perspective of a user who desires the new capability. User Stories typically follow a simple template: As a < type of user >, I want < some goal > so that < some reason >. An example: a manager who desires a scheduling feature will have a user story that looks like this: As an admin user, I want a scheduling feature so that I can add my employees to a calendar for specific tasks.
4. System architecture & User flow diagrams
System architecture provides a road map on what technologies and frameworks will be used and a birds-eye-view on how the data will move throughout the application to give direction to the development team. The two most popular web application frameworks are Django and Ruby on Rails, built and hosted in the cloud via AWS, Google Cloud, or Azure. In most cases any of these options are fine, it just depends on what the agency you choose is the most efficient in. User flow charts for each part of the system gives the development team a visual representation of how a user interacts with the application.
5. UI/UX design
If you have a vision for what they want, first work with a UI/UX designer to nail down the design. This is helpful because you can think about the small details you’re missing when you see the design come to life. You’ll answer questions you haven’t thought of. Software Architects love when there is a complete design flushed out. It really helps improve the accuracy of the estimate because they can visually see all the endpoints and how things connect together.
6. Ongoing costs
Once development starts, there are ongoing costs that need to be considered and that should be included in the estimation process. Project management is about 5% of the total time for the project duration. In the first few weeks, the Project Manager will work an average of 15 hours a week, but once momentum sets in, that can drop to 5-10 hours per week. Maintenance will be a factor after your first version is lost—this will include server costs, upgrades to technology, additions of new features, etc.
Action steps
Focus on the MVP
Identify all the critical features that need to be implemented for the minimal viable product (MVP), then put the rest of your desired features into a “version 2 list.” If you focus small and build on top of that, you will have a usable product more quickly and can receive early feedback from users. Then you can build on top of the MVP with additional features in future versions. Developing it this way will give you the highest return on investment.
Project overview document
Write up a one page overview document that provides the basic details of your project. This should include a description of the project goal, the top three pain points you’re trying to solve, any competitors, your preferred technologies (if you already know what framework you want to use), and links to any video walk-throughs you can do of existing systems (we like using Loom). The more details you add to your vision, the more time you can save with the back and forth that’s involved during the discovery phase.
Hire a software company to create the blueprint
The biggest misconception about software estimation is that any developer can accurately estimate software. Our most accurate software estimations come from a select few who have over ten years experience with development and have a deep understanding of system architecture.
Use Upwork to hire a software developer to scope out the project and send them the project overview document you created—and designs if you have them. We call this, a “Software Scoping Pre-Project.” You are not hiring someone to develop your project yet, you are hiring them to help you define your software in detail and estimate the cost that will be required to develop it. For smaller projects it could take 5 – 15 hours, medium-sized projects could take 15 – 30 hours, and a larger project could take 30+ hours. The company should deliver a detailed write-up that includes the first four components above. Your final blueprint deliverables should address all six of the components mentioned above.
Software development can be exciting and it doesn’t have to be stressful. By fully understanding the scoping process, you can better align your expectations before engaging in your project and set yourself up for success.
