As you might imagine, the topic of how to estimate the needs of a software project going forward comes up from time to time on Dev Shed’s forums; here’s a recent thread on the subject. One of our long-time members, dve83, contributed his expertise; I’m basing this article around his post.
Before you go forward with planning your project, I’d suggest you look into extreme programming practices. The idea behind this discipline of software development is to bring “the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune to the practices to their unique situation.”
The extreme programming paradigm involves the customer in the daily work of the team. The customer lays down the requirements, the team works together to deliver them. Programmers work in pairs, often switching around to gain expertise in various areas; no one person “owns” any particular piece of code, and everyone can work on every piece of code. New builds occur several times a day; completed versions go to the customer every couple of weeks. Design, as you’d imagine is an ongoing process, as is testing.
As you’d expect in such an environment, transparency, simplicity, and feedback are all highly valued. While those who have special skills are valued, the assumption is that there are no “specialists,” only general contributors who also bring specific skills to the mix. Extreme programming has been around as a practice since at least 2001 (and probably quite a bit longer). I’m mentioning it here because my tips will assume that you’re working in some version of an extreme programming environment.
So what can you count on in this kind of development environment? Well, you’ll need to keep in mind that not all of your programmers’ time will be spent on programming and implementation. You will also need to factor such items as planning, requirements analysis, and testing into your development costs.
Start with the planning and design stage. Keep in mind that your project may need to serve a number of different “customers.” And that can raise some potential conflicts. As dve83 noted, it’s often true that “the end user understand the problem and what ‘they’ need, but not necessarily how their needs would affect other customers using the same system.” As the developer/analyst, you will need to bring this up, or at least take it into consideration as you work on planning, project design, and the development requirements. You can’t do this in a vacuum; you’ll need to do a lot of consulting with the customer. At the end of this stage, you should have a requirements specification for the client to green light; it will include mostly functional requirements.
The next step involves the creation of technical development specifications. How does this new software project or implementation fit in with the various software and systems that are already in place? The pieces need to fit together, or you’ll end up with (at best) an ugly kludge which your end users wishes to avoid using at all costs.
The next thing you must consider is actual development – that is, the time it takes to do the actual programming. You can base your figures on a single developer working on it, to get a ballpark figure. Obviously, for many projects you’ll use more than one developer; you’ll be able to decrease your time estimate for the project then, but the cost won’t be any less. Factor into your calculations the amount of time your developer(s) will spend testing code.
Speaking of testing and fixing, this needs to be considered as its own step. Get someone who can test the code from an end user’s perspective. Your cost will be cheaper if you don’t use another developer to test the product at this stage, and you’ll get a more realistic sense of the product’s current issues that need fixing.
The next stage is pilot/end user acceptance testing. Think of it as a test release. You can’t bill your client for this stage of the testing process, but, as dve83 notes, “you need to include a cost for development required during this period. You have to determine a percentage of development costs to cover this. This step of the process can take a lot longer than anticipated.”
The final stage, of course, is the official release. So what does it take to get from the initial stages to this final step? The first stage, involving the planning, design, and understanding the customer’s needs, is a major part of the development process; dve83 estimates that it’s 30 percent of the full project. The next stage, involving technical internal planning, covers roughly 10 percent. Another 30 percent will be taken up in actual coding and development time. Give over another 20 percent to developer testing and extra development. Your final 10 percent belongs to the additional development that will be needed once the pilot program is handed over to end users to test. These rough percentages should give you some basis on which to build as you calculate your project’s costs. Good luck!