When launching a new software project, best practices suggest enlisting the help of a subject matter expert, who is knowledgeable about software development and can assist in the early stages of project planning. This strategy has proven to greatly improve the project outcome, yet at the end of the project you’re staring at a failure. How did this happen?
Project failure can be defined as one or a combination of cost overruns, late deliveries, poor quality, and/or developing a product that does not get used. Regardless of their involvement during the planning stages, more often than not, software developers bear the brunt of the responsibility for such situations; after all, they’re the ones who built the application. However, closer examinations of the projects do not always show evidence of incompetence.
When assessing these failed projects some of these perform “reasonably” when compared with industry trends, yet to the organization they are deemed failures. The reason is that overwhelming majority of the problems can be tied to flawed estimation or poor business decision making at the very outset of the project.
To avoid this, first organizations need to use a standardized set of estimation terms. We often find that individuals and organizations use a number of key terms interchangeably when they each have a unique meaning.
- Target – A goal, what we would like to do or achieve.
- Constraint – Some internal or external limitation on what we are able to do.
- Estimate – A technical calculation of what we might be able to do at a defined level of scope, cost, schedule, staff, and probability.
- Commitment – A business decision made by selecting one estimate scenario and assigning appropriate resources to meet a target within a set of constraints.
- Plan – A set of project tasks and activities that will give us some probability of meeting a commitment at a defined level of scope, budget, schedule, and staff.
Being clear on these definitions ensures projects get off on the right foot with realistic targets and an understanding of the project’s constraints. Not doing so can send a project on a death march from the start due to one of more of the following factors.
1. Accepting a forced schedule or mandated completion/ milestone dates without substantial data and analysis.
Someone in your organization publicly speculates that the project will be done by a particular date, thus unintentionally commits the team to that deadline. Perhaps your budget cycle dictates that the money allocated to this project must be spent by the end of the year or the next release will not get funded. Maybe the stakeholder wants the project finished by Christmas so that he/she can enjoy the holiday in peace, knowing that the project is complete. Or maybe the stakeholder just really likes round numbers and wants the project to release the 1st of the month. There are numerous reasons why a development team would be given an arbitrary project completion deadline. The unfortunate reality of an overzealous schedule often results in overstaffing the project, the next reason why software projects fail.
2. Adding excessive personnel to achieve unrealistic schedule compression.
How do project managers deal with an overly optimistic schedule? One common response is to staff up the project, often adding way more people than necessary to complete the project. Not only does this drastically increase the cost of a project, but it also decreases the quality. Having more people involved in the project increases opportunities for miscommunications and also makes it more challenging to integrate the different sections of code together. Additionally, Frederick Brooks (1975) would argue that “adding people to a late project only makes it later,” which makes sense. The people have to come from somewhere, often from other projects. This puts the other projects further behind schedule and requires that the new staff get caught up by veteran staff, thus decreasing productivity across the board.
3. Failing to account and adjust for requirements growth or change and making necessary adjustments to the schedule and budget forecasts.
“Wouldn’t it be great if…?” Those five words can be some of the most dreaded, especially when heard halfway through the construction portion of a project. While there is certainly a time and a place for brainstorming, those activities should take place in Phases 1 and 2. In fact, the purpose of these two phases is to determine whether or not a project is feasible, and what features the application should have. If you think of it this way, Phase 2 helps you figure out what you are building, while in Phase 3, you build whatever you decided upon in Phase 2. While some overlap may exist between the two high-level phases, by the time you’re in the Phase 3, the scope of required functionality for a given product release should be clear.
- Requirements growth is a problem if you’re adding functionality without allotting more time and budget for development. In essence, you’re asking for more work in a shorter amount of time, a technique that we’ve already found does not work.
- Changes to existing requirements can also be a problem depending on the nature and timing of the change. Projects using Agile methods can manage changes to requirements details, as long as they occur before construction of a given iteration. However, any changes to requirements of software architecture that cause rework of code already written will almost certainly have an impact to the schedule and budget.
4. Emotional or “intuition-based” stakeholder negotiation that ignores facts and statistics.
At some point or another we’ve all become attached to a particular project that we’ve worked on and become emotionally invested in its outcome. For many, this may be the project where your reputation is on the line; the one that is too-big-to-fail, and often we let our emotions get the best of us.
When the pending success or failure of a software project puts an individual’s career on the line, it’s likely that any related business decisions will be impacted. Stress can cloud one’s thinking, especially when the stakes are high. A stakeholder may call for a 12-month schedule in order to impress a customer despite the fact that reports from previous projects of similar sizes all show a 15 month lifecycle. The stakeholder may dismiss advice from team members, stating that he has “a feeling” that the team will be able to pull through. In such situations, following your gut could be extremely detrimental and potentially lead to project failures.
5. False, but common belief that the proverbial IT silver bullet alone can solve project throughput or process issues.
When all else fails, a common next approach is a change of strategy. “We must be doing it all wrong” and “What are our competitors doing?” are common thoughts at this point. This is when musings of an “IT silver bullet” may start circulating around the office. For instance, someone may suggest that the organization needs to adopt the latest bandwagon development approach. While that might be a great direction in which to take the organization, a decision like this should not be taken lightly. Whichever development methodology your organization decides to use, it’s only as good as your implementation. Merely switching development methodologies is not enough to transform your development operation. Regardless of what you decide, in order to make the implementation successful, there needs to be buy-in from all sides, individuals need to be trained, and everyone needs to be held accountable to the same standards. Otherwise, your development strategy will be roughly equivalent to waiting for the stars to align perfectly and hoping for a miracle each time you begin a project. If implemented without thought, this strategy is not only incredibly risky, but also reduces opportunities for team members to give feedback mid-project.
In short, software projects fail for a number of reasons. Take a moment to reflect on whether any of the above reasons may have been the cause of a project failure in your organization. Now what can you do about it? As an executive leader you can do a lot, but it will require some courage to support your development operation. They need to function within a reasonable set of expectations. Obviously, they will still have to be held accountable, so you will also need historic performance data as evidence of their capability.
You will need to collect data on several different metrics, including the project’s schedule duration, the effort expended, the scope of the work performed, the project’s overall quality, and the productivity level achieved. In this case, productivity (PI) was measured in index points, a calculated proprietary QSM unit which ranges from 0.1 to 40. It allows for meaningful comparisons to be made between projects and accounts for software development factors, including variables such as: management influence, development methods, tools, experience levels and application type complexity.
Once a repository of an organization’s completed projects has been established, custom trend lines can be calculated to use for creating the baseline. These trend lines serve as a reference point that can be used for comparing projects within your organization. Where your projects fall relative to the trend line will indicate better or worse performance than the average. This will give insight into your organization’s current capabilities.
Figure 1. Company project portfolio plotted against their baseline productivity trend.
We can learn a lot about what we do well and what we can improve upon from looking at our projects relative to the baseline. Examining how far a project deviates from the various trends can help isolate best- or worst-in-class performances. Project outliers can also provide great insight into this. Figure 1 displays the company project portfolio against their baseline average productivity. Two of the projects stand out since they fall outside two standard deviations, one above the average and one below respectively. Further examining the factors that influenced these projects (i.e. new technology, tools and methods, personnel, or project complexity) will help shed some light on why these projects performed so well or so poorly. Mimicking what went well for best-in-class projects and avoiding what didn’t for the worst-in-class projects can help improve the performance of future projects.
Understanding the baseline for your current development operation can help set reasonable expectations for future projects by showing what has been accomplished in the past. If the desired project parameters push the estimate into uncharted territory, you can use the historical baseline to negotiate for something more reasonable. This baseline can also be used for contract negotiation, evaluating bids and vendor performance, and navigating customer constraints, thus allowing you to achieve your cost reduction and process improvement goals.
Doing this will put you in a much more powerful position to negotiate with customers and business stakeholders. The ideal outcome is one in which every entity can be successful. In all likelihood this will require some compromise, but through this process you will be sowing the seeds of success.
About the Authors
C. Taylor Putnam-Majarian is a Consulting Analyst at QSM and has over seven years of specialized data analysis, testing, and research experience. In addition to providing consulting support in software estimation and benchmarking engagements to clients from both the commercial and government sectors, Taylor has authored numerous publications about Agile development, software estimation, and process improvement, and is a regular blog contributor for QSM. Most recently, Taylor presented research titled Does Agile Scale? A Quantitative Look at Agile Projects at the 2014 Agile in Government conference in Washington, DC. Taylor holds a bachelor’s degree from Dickinson College.
Doug Putnam is Co-CEO for Quantitative Software Management (QSM) Inc. He has 35 years of experience in the software measurement field and is considered a pioneer in the development of this industry. Mr. Putnam has been instrumental in directing the development of the industry leading SLIM Suite of software estimation and measurement tools, and is a sought after international author, speaker and consultant. His responsibilities include managing and delivery of QSM software measurement services, defining requirements for the SLIM Product Suite and overseeing the research activities derived from the QSM benchmark database.