Large companies often seem to have a few people in key positions with extra time on their hands. Occasionally, this time is used to invent acronyms that are supposed to embody corporate ideals. Mercifully, these usually fade away in time. A former employer of mine had two beauties: LOCOPRO (Low Cost Provider) and BEGOR (Best Guaranteer of Results). Unfortunately, besides being grating on the ear, LOCOPRO and BEGOR don’t always march in tandem. LOCOPRO deals with cost and the effort required to deliver something. BEGOR is a bit more amorphous dealing with quality and an organization’s efficiency and consistency in meeting requirements.
What are the normal requirements for a software project? Here’s my short list.
- Cost. What is being created and delivered has to be worth the expense in the mind of the person or organization that is funding it. (LOCOPRO is good)
- Schedule. The timeframe in which a project creates and delivers its software is frequently a key constraint. Meeting this is important. Consistency and predictability (BEGOR are good)
- Quality. In Business IT systems this is often an implicit requirement that is most noticed when it is absent. Real time, telecommunications, military, and life support systems are more frequently developed and tested to explicit quality standards.
The mantra of Faster/Better/Cheaper captures most organizations’ desires for Cost, Schedule, and Quality – all at the same time. If only the laws of software would cooperate! But they don’t. Software is like a balloon. You constrict it in one place (schedule, for instance) and it expands in another (cost). The problem isn’t going to disappear; but by prioritizing requirements, conscious and realistic tradeoffs can be made.
I conducted a study of projects sized in function points and looked at the impact of schedule on productivity. The sample included over 2,000 recently completed IT projects. First, I created a scatter plot of the projects with size in function points on the X-axis and calendar months of effort on the Y-axis and fit a regression line through them to determine the average. (This allowed me to see how much different sized projects varied from the average.) I examined the productivity in function points per person month as project schedule deviated (both positively and negatively) from the average. The chart below captures the results. The projects were sorted into groups based on how many standard deviations they were above or below average schedule. “Greater than Average” indicates that projects in that category used more time than average; “Less than Average” just the opposite.
The chart illustrates a classic software development conundrum: better productivity and lower cost (LOCOPRO) have a price and that price is a longer schedule. But increasing schedule also reduces defects and improves quality (BEGOR). The projects that had schedules longer than two standard deviations more than average had a median productivity around 28 function points per staff month while projects with slightly better than average time to market (those in the 0 – 49 less than avg. group) had a median productivity around 6 function points per staff month. Software projects are especially sensitive to schedule, and a small schedule increase can have a dramatic and positive impact on productivity.
Cost, schedule, and productivity assumptions are critical inputs to any project plan. By prioritizing these assumptions and analyzing their impact on one another, a project manager improves his or her chance of success. Either way, the following tradeoffs should be taken into account.
- If schedule is the top priority, productivity may suffer causing cost to be greater.
- If cost is more important, the schedule will need to be relaxed; but productivity gains mean the schedule increase will be small. It’s the law of tradeoffs.