We hear a lot about software projects that are too large or attempt to do too much in too short of a time. They are very visible and negatively impact both budgets and careers in a not positive manner when they fail. Small projects may fly under the radar. This is a mistake. Most IT projects aren’t large undertakings like Healthcare.gov; rather, they are enhancements and customizations to already existing software systems and account for the majority of most enterprises’ software budget. Planning these projects to be optimally productive is an area in which most companies can realize the greatest returns.
How do you know what is the optimal amount of software to develop in a project? In a newly published software benchmark study QSM analyzed productivity, cost/effort, and time to market of a large sample (over 600) of business IT projects that have recently completed. The projects were divided into quartiles based on the amount of software they developed or customized, which were then compared to each other. Fully ¼ of the projects were smaller than 3,200 implementation units in size or 68 function points for projects that used that size measure. Projects in this quartile had a median productivity of 200 IU per staff month or 5 function points per staff month. The median duration of these projects was slightly more than 3 months. The second quartile contained projects from 3,200 IU up to 8,000 (or 69 to 149 function points). These projects had a median productivity of 377 IU per staff month (or 7.62 function point per staff month) and lasted a little more than 5 months. This is a productivity improvement of 89%. The smaller projects were markedly less productive. So, simply by bundling software work into larger packages there are significant efficiencies to be gained.
Factors to Consider When Planning a Software Project
There are at least four variables that must be taken into account when planning a software project. Each of these impacts the others and all must be taken into account and balanced. They are
- Minimum viable product. Every project needs to produce a functioning end product that fulfills a need. Overhead is often a fixed cost or does not increase proportional to the increase in functionality produced, so there are productivity advantages, which ultimately translate into cost savings, in bundling small enhancements together.
- Budget. Cost is always a constraint, whether implicit or explicit.
- Available resources. Is there staff available for the project without impacting higher priority projects, especially staff with specialized skills?
- Schedule. Can the project be completed in the available time? What is the impact on other projects? Has the project been modeled to see if the desired schedule is practical?
