Project Requirements and Estimates
It is a widely repeated fact that software development projects often go over budget and schedule by large margins. Many different, jaw dropping, stats are quoted on this subject. At BinaryOps we work very hard to not become part of those stats. We understand that cost and schedule certainty is important to our clients. The traditional approach to achieve that certainty was to document the requirements in painful detail. Painful, because requirements are notoriously difficult to document. They need to be free from interpretation, measurable and testable. The requirements document then becomes the blue-print for a traditional waterfall style project execution. Every time the project team uncovers an issue that contradict the requirements document, there is potential for major upheaval in the project plan, as well as project costs.
Successful software, especially successful mobile apps, have achieved that success by releasing new versions often, and pivoting on their idea. Success like that is hard to achieve when you're stuck half way down the waterfall, tied to a hefty requirements document. We like to use more Agile methods in our projects to help our clients achieve success. The requirements are documented in a more conversational style, using 'User Stories'. Groups of user stories are bundled in releases of the software. Releases are happening frequently, so that the team can receive feedback on what works and what doesn't. After a few of these releases everyone on the project (See our post on Communication) knows how fast we are able to implement features and with what cost. Using this method everyone is always up to date on where we're at and how far we're going to get in the future.
Of course this doesn't mean that you get to step into a project clueless about cost and schedule. Nor does it mean that the whole product is built without any pre-conceived architecture (That's another post, coming soon). At the start of every project we make sure that we have a good understanding of the high level requirements of all the deliverables. We will provide a substantiated estimate for those deliverables. More often than not, we come in close to the estimate. Larger deviations only happen when new user stories gain priority, (as they should!) and everyone on the project agreed with the course of action chosen.
Flexibility achieves success, and you don't need to be confronted with unpleasant surprises along the way. You can always talk to us about project execution.
Wiebo Troost
