How to Complete a Software Development Project on Time, on Budget

Recent industry studies show that modern software projects on average spend 40 percent of their effort on rework, and as a result, over 80 percent of software projects overrun budgets, miss schedules and substantially reduce delivered functionality.

It’s a software development business analyst’s nightmare – that doesn’t seem to end.

The potential for error is further heightened because, unlike mechanical or civil engineering where the results of your efforts are tangible, the product of software development is largely conceptual.  When a manager is directing a complex project with several teams, the potential for mistakes or misdirection is especially magnified. Unlike a bridge being built from two sides of a river, significant discrepancies can creep in without an obvious reality check.

To avoid costly errors and delays, business analysts should consider seven key steps in tackling software development projects.

1. To manage software projects effectively, business analysts need to have an explicit definition of the project’s scope. A clear demarcation of what is in and what is out, what is essential and what is would be nice to have, and what needs to be delivered at the end of the process. All major stakeholders and team members need to have a common understanding of the project goal. Ambiguities at this step can lead to major problems later that can only be resolved by a significant waste of time and money through rework.
2. Develop concepts into clear requirements. Once stakeholders agree on a common goal, they need to refine their understanding into precise requirements, understandable to all. While it is common for requirements to evolve, starting from a specific requirements baseline provides a foundation to ensure the development process doesn’t drift. By ensuring that stakeholders are deeply involved in defining requirements, business analysts have a solid, universal understanding of the project’s path and scope.
3. If the project is complex, use models that can be updated as the project evolves. Models represent the product in varying levels of detail and from various perspectives.  Sometimes, there is resistance to building models due to the effort required to maintain them, as new and different elements are incorporated. It is precisely because software development is so complicated that models are needed. With so many conceptual layers being tied together, it can be difficult to keep track of each and every element and their interrelationships. You wouldn’t consider building a bridge without a model. Why would you consider developing software, which is every bit as complicated, without one?
4. Manage expectations through the project. As software development proceeds, stakeholders often suggest that more functionality be added to the project beyond its original intent. It’s necessary to rely on more than the legal contract to keep projects focused. As more people become involved in the project, regular get-togethers become even more important to ensure that all stakeholders stay aligned.  
5. Keep the model up to date. Feedback loops are an essential part of most successful projects, and software development is no different. While it might seem time-consuming, keeping the model current provides a touchstone for all stakeholders as the project progresses. It helps maintain focus and exposes when any aspect of the development drifts from its original, or modified, intent. As much as possible, design the model so that it can be updated automatically.
6. Decompose the model. The model should be designed in such a way that its constituent parts align with work tasks of the team.  In this way, the model parts can be delegated to individual teams to develop or maintain, and later reassembled as needed, to ensure overall integrity at regular milestones.  The process should be managed so that teams, including subcontractors, can come back to the model every so often for a reality check. By so doing, the business analyst keeps the potential for significant rework or outright failure at a minimum.
7. The process should be built so that all aspects of the model, including those that have progressed, are pulled together regularly to ensure that everything still fits and that modules under development are still proceeding toward the ultimate goal.

But Won’t it Cost More?

Using a management structure that relies on a series of reality checks requires a project budget that allocates time and money for periodic review. The result, however, is that this marginal investment yields far more payback in terms of reduced rework.   An accurate and representative model is a catalyst for more valuable and more frequent feedback. Feedback loops are designed precisely to reduce risk and are found in nearly all engineering disciplines.

With software development projects spending on average 40 percent of their effort on rework, it is worthwhile to use an effective model to ensure your project achieves success.

Consider the alternative: A project that the client rejects, one that has to be reworked hastily, held together by shunts and duct tape. Not only are project funds wasted unnecessarily, but the delivered product’s quality suffers.   Status quo is the expensive path.