Running a software development project can be a daunting task. Keeping control over the project, schedule, and budget while dealing with different expectations and changing requirements can lead to ulcers. The best way to avoid pitfalls is to spend the time up front to define the problem, design a solution, and assign a legitimate schedule and budget to the solution. However, a design study is like a project with a life of its own and you may find all the time and money allotted for the project disappear in design before you even get started. So how much is too much and how much is not enough? That is a question that does not have a single answer for all projects. Each project will be different.

Iterative Phased Approach 

At Bit-Wizards we use an iterative phased approach that allows us to gauge the amount of study time needed on a project-by-project basis. Phase 1 defines the problem and sets the scope, Phase 2 analyzes the problem and creates a design, and Phase 3 implements the solution. We can adapt to a simple component that can be mapped in a week, go through several iterative cycles over a couple of months on a large scale project, or continually update the requirements and design on a project that is completely fluid. The phased cycle is never quite sequential, but it does not run in a continuous whirlpool either. At Bit-Wizards we tend to deal with external clients, but these techniques will work with external clients, internal clients, or even if you are your own client.

Phase 1 - Problem and Scope Definition

The first phase of any project must be the problem and scope definition. Every phase has a deliverable, goal, or output that you work towards. The goal for Phase 1 is to define the scope of the solution. Some people confuse this phase with the requirements gathering portion of Phase 2, the design phase. This is an easy mistake to make, because you will be extracting requirements while you define the scope. However, the information you gather needs to help define the requirements and constraints that will dictate the scope of the solution. For example, a hypothetical requirement that the system solves the problems in routing work from accounting to purchasing helps define scope. To the contrary defining an equation used to find the tax liability of a widget does not help define scope. Defining the scope first keeps you from wasting time gathering facts that will never be used. You would not want to spend time gathering details on a component of the project that will be dropped due to some constraint. 

If technology is the first thing you discuss when you start a software development project, you are already off to a bad start. Trying to force fit a problem into a particular technology can leave you short sighted. There are many factors that will determine the technology you will use. Will the application be used over the Web, with hand held devices, or on a stand-alone computer? What skills does my IT team have? How long do I need the lifespan of this application to be? But before we can answer these questions, there are other questions that must be answered first. The problem must be defined and the scope set before you can even consider the questions of the solution.

Once you have the problem and the scope of the solution defined, you must get everyone involved to agree to it before moving on. It is important that everyone have the same expectations on the project. Once everyone’s expectations are set then Phase 2, the analysis and design phase, can begin. The beginning work here is much the same as in Phase 1, so you might ask why we differentiate. In Phase 1, we defined the scope of the solution - not the solution itself. A fully designed and well planned solution blueprint is the goal of Phase 2. This being the goal we do not reach it in a straight line. We reach this goal in an iterative spiral having a design, alternate designs, and revision after revision of the design, schedule, and budget. Phase 1 draws the boundary of the first spiral before we start working our way in. Setting the first boundary early and shoring it up with everyone’s approval will save you time and money by focusing all your efforts in the right area and that is why it is set apart from all the other iterative cycles. Phase 1 produces a tentative quantity of how much time and how many resources will be needed to go through Phase 2. With this information, you can keep the design phase from decimating your budget.

Phase 2 - Analysis and Design

Phase 2 is the assembly and study of all the requirements and the careful analysis and design needed to arrive at a desired feature set with its associated schedule and cost. When there is more up-front planning and analysis, then features are better defined, and in turn, schedule and cost are better defined. Depending on different constraints your ability to define the features will vary. We always recommend defining a feature set completely before beginning, but different constraints may make this impossible. The important thing to remember is that features, schedule, and cost form a triangle that we at Bit-Wizards like to call the technology triangle.

All three items are mutually interdependent. The more obscure the feature set, the more obscure the schedule and budget. Another important thing to remember, which I mentioned at the beginning, is assigning a legitimate schedule and budget. All too often, I’ve seen projects that worked backward from a set amount of money or time and tried to justify a set number of features into that schedule or budget. If you only have a set amount of money or time to compete a project, pick the features you need most, then the secondary group of desired features, and so on until you reach your limiting factor and stop. Hopefully, you have identified this constraint in Phase 1 and concentrated your efforts on the most important features.

You should also make sure the people doing the estimating are people who really know what it will take. Having a domain expert with no technical background estimate the effort to program a module will yield poor, if not completely useless, results. It is best to use time as the glue between features, schedule, and cost. Obviously, time is the working component of a schedule and it is also a good way to relate cost and features. Asking someone what it will cost to build a feature is a lot tougher than asking how long it will take. It is also a lot easier to estimate and measure costs by the number of hours used on a project rather than a feature-by-feature basis.

Phase 3 - Development and Implementation

Phase 3 is where the software or IT solution is implemented. The solution may consist of computer hardware, custom software, off-the-shelf software, or business process changes. But as I’ve mentioned all along in this article, things are iterative; so there may still be some design work, and perhaps even some scope definition, going on in Phase 3. However, if you have done a good job on the first two phases, there should be little to no work being done on the design and scope, or you planned your project to have continues revisions.

Following a process and having defined goals to work towards will increase your chance of having a successful project that will be delivered on time and within budget. The process I have outlined has been successful for us at Bit-Wizards and will help guide you through your projects. Now you are ready to implement a successful solution to your problem.