Often times, a company will decide that they need software or a mobile app, but they have no idea what they need to do in order for this to happen. The usual course of action is to put someone with technical abilities in charge of the project. though they still receive guidance from upper management. A situation such as this can be difficult as upper management will want answers, but they haven't gone though and answered all the questions. Software is one product where you can't do that. You have to go through all the questions. You can't just say "Hey, this is what I want. How much will it cost?" There are a lot more variables that go into getting a realistic cost estimate.
More times than not I receive calls, or emails saying, “Hey Chad, we really want a mobile app for our company, how much is that going to cost?”. In a perfect world, I could read your mind and throw out a number. However, anyone that watches the nightly news for 10 minutes can tell you, we don't live in a perfect world. Telling a development shop that you want an app, is like telling a home builder, “Hey build me a house”, without saying how many bedrooms, bathrooms, stories, what tile, carpet or not and I think you are starting to get the point.
If you truly care about your project you should be investing time in creating the proper documentation to make sure you get what you are looking for. The better you can describe what you are looking for, and how you want it to function, the more likely you are to avoid that nasty project monster called “SCOPE CREEP”.
First and foremost, you will want to ask everyone for user stories. User stories are short descriptive examples of the features they would like to see in the software. The stories also outlines how they would like to interact with said software. These accounts are useful in creating scope documentation and software that is both useful and helpful for your staff.
Second, you will want to create feature lists or what some like to call "wish lists". These lists can be broken down into categories: the necessary features, the desired features and the optional features. After you evaluate the importance of said features, you can begin to pull all of the pieces together.
Now that you have a good idea of what you want, you can start to determine how you want to go about approaching the project. Now is a good time to build scope. Scope is basically written blueprints for the design you want. You will need to defined what technologies you are looking to use as well as the devices (i.e. mobile, pc, tablet, etc) you plan to use in conjunction with software both now and in the future. Planning for future development needs can help in forming the architecture of your software now. If you need examples, there are plenty of good samples via a Google search.
Got that done? Great. You're getting close to being finished. The next step is to create functional wire-frames. This documentation/design element provide further blueprints that pertain to what you want you want, where you want it and what happens with buttons are clicked. Not only does this give a good idea of what how to build want you want, it also allows us to give you a more accurate estimate.
Once you have your scope documentation, user stories and functional wire-frames, the next step is to send all of that to us. We'll look things over and setup a call/s to discuss any questions we may have. After we have a good understanding we will compile the information and provide you with a ballpark estimate. This is going to be an estimated high and low in development hours. Once you have reviewed the estimate there are a few things that can happen.
You can say, sorry that is way over our budget, this isn't going to work out.
You can said, we are close but can we cut some scope out to make sure we can afford this. This is where the prioritizing of your wish list comes in handy, maybe some of the desired features, or optional features can be pushed out to future enhancements.
You agree with the ballpark and we move forward.
If the latter two scenarios are the case and you'd like to move forward, we will set up a call with one of our technical architects, and estimators who will do a further dive into your requirements and fine tune all the documentation. This may take a little back and forth, but we will get it dialed in. Now that our side understands the project we will go back and create a full line item estimate of what we believe it will take to build your software.
At this point, we will send you a line item estimate for review. This is the time to cut or add to the scope if there's anything missing. If everything looks good, you give us the nod and we will get you going with a Master Service Agreement (MSA) and Statement of Work (SOW). First, the MSA is going to outline the partnership we are taking amongst our companies to build out the software for you. Second, the SOW is going to outline what it is we are doing, and payment details. Once all the paperwork is signed, we are ready to roll.
Now, we will schedule a quick project launch meeting, where you will be able to coordinate with your development team and get your project underway. Once it is underway, you will now direct your communications to your PM/Scrum Master. They will be your point of contact on the project from here on out, unless you have billing issues or any additional projects you would like to discuss, then you can direct your conversation back to your Business Development Rep.
Once your project is completed to your satisfaction you will be given your software for your use. At that time if you have any bug fix needs, or production related items, you will still want to reach out to your PM/ScrumMaster to resolve those issues. For any other needs you can reach out to Business Development and we will be happy to get you taken care of. Should the need arise to send over one of our favorite types of leads “referrals” you will want to direct them to your Business Development Rep.
In the end you will receive the exact project you want in a timely and realistic manner. Yes, some work is required on your part, but it's necessary for us to gain a full understanding of the project so we can then assemble all the pieces. By doing the preliminary work and working with us, you eliminate the guess work and reduce the number of unknowns making it that much easier to get to the desired outcome.