Predictability can be achieved, but not without cost. And the larger the project, the higher the price. (And the price is not linear, as noted later in this post.)
Large-scale projects have more requirements – and thus more product features. More features mean more components, more interfaces between the components, more behavior expected of the software, more testing, and more sleepless nights than smaller projects. After all, getting a large number of features correct, and operating correctly with one another, is a challenge in and of itself.
When talking about software project predictability, the most common definition of success is really about predictability, the delivery of projects:
Am I talking about a waterfall project? Let's say that I am.
- On Time
- On Budget
- Of High Quality
- With the Expected Features
Given all of these constraints (including the choice of a waterfall methodology), predictability becomes a function of:
Note that I’ve made the target that the project team needs to hit crystal clear right out of the gate. In addition, the software requirements need to be clear; they must be expressed clearly to the satisfaction of the project team. This alone requires a skilled job performed by those responsible for crafting the requirements, plus an investment in time to ensure that the project team understands the requirements.
- Clear, unambiguous, well-understood requirements that will not change during the course of the project.
- Estimation and work performed by experienced, competent professionals who can and will work together as a team.
- Project scheduling performed by experienced, competent project managers.
I’ve also added the rule that the requirement cannot change during the course of the project. Getting the requirements right, ensuring that they are understood by the team, and managing change is a big part of meeting the predictability/success criteria. This requires an up-front investment of time that before a project actually begins; and the more requirements to be addressed by a project, the greater the investment in time required.
It shouldn’t be too difficult to see that I’ve also stacked the deck with experienced, competent people – the “secret sauce” to any successful project. Good, experienced, competent professionals will not take undue risks, and they can be counted on to work a project to completion, hitting their dates with quality. I’ve also stipulated that they can and will work together as a team, something that is easier said than done.
What else drives unpredictability?
One of the problems with predictability in software projects is that they are the most unpredictable in the early stages of a project. This phenomenon is reported by Steve McConnell in his book Software Estimation: Demystifying the Black Art. It is known as The Cone of Uncertainty.
The cone is largest the earlier in the project life cycle you are. The cone narrows from uncertainty to certainty as different stages are reached. Steve McConnell points out that a significant narrowing of the cone occurs during the first 20-30% of the total calendar time for a project.
What happens when someone asks you to take extra time to work on your estimate, so that it contains less uncertainty? Nothing that makes the estimates any better than the already are. Improving the estimates requires working out the variability that drives the uncertainty, and this means performing the actual work of the project.
What else contributes to software project uncertainty?
In a word: People.
Let’s face it; everyone has their strengths, weaknesses, preferences, and idiosyncrasies. Some mixes of people work better than others, and no matter what it takes time for people to understand each other and balance out each other’s strengths and weaknesses so that they can work effectively as a team.
In the real world, you will likely have a mix of seasoned and less experienced personnel on a project. It simply isn’t economical or feasible to staff each and every project with people highly experienced in the position required for a project. People need to learn and grow, and they will need new experiences to help them grow.
Giving people new experiences and challenges is a great investment; your organization gains bench strength and providing new opportunities and challenges keeps people happy and motivated. This will sacrifice some predictability, a risk that can be mitigated through mentoring and additional oversight.
If you attempting to predict one project's completion based upon another project, keep in mind that studies have proven that software projects are not linear in nature. Referring back to Software Estimation: Demystifying the Black Art, Steve McConnell points out that if a 10,000 lines of code system required 13.5 staff months, a 100,000 lines of code system should require 135 staff months, but in reality it requires 170 staff months.
The amount of people involved with large-scale projects introduces extra overhead, part of that being extra lines of communication. And when there are more people and more lines of communication, the greater the opportunity for miscommunication to occur.
Is predictability all that you care about? Consider this: Time will likely change your perspective, especially in today’s fast-paced business climate. What you think is a priority today many not be one tomorrow.
Instead of being predictable – like predicting what you need software to do one year from now – another option is to be fast and adaptable. Be prepared to embrace changing conditions and circumstances by building smaller software projects that focus on the high-value, high-return features first, deferring on the rest.
Smaller projects enable a faster return on investment; the quicker that the software is in use, the sooner that a return is provided. Decisions to continue to enhance the software to provide even greater return can then be made. In a worst-case scenario, a smaller project enables you to fail fast, and with less expense incurred.