Three Things to NOT Do with Your Software Development Projects

Everyone is familiar with the term “prior planning prevents poor performance,” so why is it so difficult for companies to live by this maxim? Perhaps because we are accustomed to living our lives by the phrase “move fast and get the job done.” 

The problem, of course, is that moving too fast can indeed lead to things breaking – and that can cause big problems for software projects. Under pressure from up above, project managers might be inclined to forgo estimation and up-front planning in favor of jumping in with both feet. But I know all too well from over 30 years of software project management experience that a project that is rushed into development is one that is likely doomed to fail. 

Back in the 1980’s, Kodak sought to diversify their film development business with software-driven document imaging solutions. The company spent over a year and a half investing millions of dollars and significant human resource hours building their system before they asked me for a project estimate. That estimate showed they had another two years and a lot more money to go. If the company had estimated up-front they may have been able to better assess the time to market and ROI opportunities. Instead, the entire thing was scuttled – a waste of valuable time and resources.

A colleague of mine once shared a similar sad story with me. He told me of a Christmas holiday, several years ago, when a customer asked him to provide a series of 22 estimates right before he went on break. They disagreed with his data driven estimations and decided to go their own way. Their project ended up failing due to unreasonable expectations and timeframes. They ended up coming back to him to do the work properly. Merry Christmas, indeed!

Today, companies are making the same errors. One organization recently undertook a large and intensive software development project. They ramped up to over 100 developers, but, because of internal pressure and an insanely short and unrealistic schedule, decided to forgo system integration testing. By not having a mechanism to assess the quality impacts, and rushing development, they ended up missing a lot of system defects and are now in the process of re-evaluating and starting from scratch.

Thankfully, there is no reason for history to continue to repeat itself. By focusing on what notto do, project managers can avoid the pitfalls that lead to cost and time overruns and deliver solutions that create true value. 

Do NOT skip estimation and rush to detailed planning – estimate from the top down.

Any sort of planning is better than no planning at all – but top down estimation provides valuable input to the detailed planning process. 

In my experience, I have found that setting unrealistic expectations is the primary cause of project failure. Developing accurate projections is a core competency that many organizations simply have not gotten very good at doing. 

Part of the reason is because they tend to use traditional scoping processes to estimate the size of their projects, which can often lead to inaccurate projections. Traditionally, when project managers map out the scope of their projects, they do so from the bottom up. Managers ask individual team members to estimate how many hours they think they will work on a specific activities, and base their schedules on these “guestimates.” Unfortunately, this process is missing one key ingredient: facts. According to research based on QSM’s database of completed projects, two thirds of companies fail to compare planned performance to actual historical performance of similar projects, which could give teams a better indication of the time, effort, and money it will take to complete their work. Their best guesses result in missed deadlines, cost overruns, unhappy customers, and disenfranchised developers.

Taking a top-down, scope-based estimation approach at the onset of a project is a much more effective strategy. By using data from similar projects, managers can get an accurate representation of what it will take to complete their work and deliver a finished, working product. Right from the beginning they will have a comprehensive idea of how much functionality their project will have and be able to allocate resources accordingly. 

Top-down estimation tools can help establish realistic project boundaries, both when projects are in the initial planning stages and as they progress. For example, a project manager might already have a team of 10 developers working on a five-month release cadence cycle. Throughout the course of this work, the simulation software may reveal a backlog refinement showing approximately 100 story points that need to be completed. 

Further analysis shows that, while the initial estimates for team productivity and labor costs are spot on, new capabilities may not be able to added within the proposed schedule. Since that schedule is fixed, the project manager needs to focus on adjusting product features and capabilities to meet stakeholders’ expectations. They can use their simulation software to measure the probability of whether or not they will be able to achieve all 100 story points. Perhaps 80 are more realistic, or maybe 70. Whatever the number is, that is the number stakeholders can expect, at minimum. 

There is no guesswork involved; everything is based on proven data points. Therefore, the estimate is far more accurate than those derived from traditional estimation. Teams can set accurate expectations, leading to satisfied customers and less pressure on development teams to deliver solutions in unmanageable timeframes.

Do NOT react to impending deadlines by overstaffing.

To use yet another cliché, it is a fact that “too many cooks spoil the broth,” and yet the first thing that many project managers do when faced with mounting deadlines is to staff up their projects. The theory is, the more people, the faster we will get it done.

Of course, this almost never goes well. More often than not, adding more resources to a project creates more complexity and increases the chances for mistakes. More people lead to miscommunication, which can increase defects and cause rework. Indeed, more people usually leads to more -- not less – time being spent on a project.

Project managers can use top-down estimation to visualize appropriate staffing and resource demands for their portfolios. These estimates can be broken down by both initiative and month, over the course of a specific period of time. They can even break out staff by spending rates and compare them to budget constraints to ensure that those people will be appropriate for a particular project, or match up with their organization’s current and future capacity needs. Here is an example of how this may look over time.

Do NOT be a slave to your plan.

Prior planning does not mean that teams cannot change course throughout development. Despite best-laid plans, most projects will inevitably encounter some unknown factors or re-prioritization during their lifespan. Perhaps management will ask for new features to be added, or team members will be moved onto different, more mission critical tasks. 

While uncertainties can crop up at any time, they can be factored into the top-down planning process, thus mitigating their potential impact, as evidenced by our earlier example of the project that might not hit 100 story points. Incorporating this uncertainty upfront can help avoid sudden changes early on.

There may still be fluctuations throughout the course of development, most driven by changing stakeholder demands. For example, customers may demand new features to meet changing market dynamics. These requests will, inevitably, have a direct impact on development, and teams need to be ready to adjust while still managing as close as possible to their initial commitments.

Unfortunately, many organizations do not know how to adjust when these unanticipated bumps in the road come up, but estimates can easily fluctuate (hence the name “estimates”), and reforecasting can take place to accommodate changing needs and dynamics. Priorities can be shifted or removed completely to accommodate new work demands. Scopes can be refined to provide stakeholders with updated and realistic schedules to keep things on track. It is a living process that plays well with organizations’ drive toward agile development.

As with anything else, communication is critical to this entire process. Stakeholders can see numbers on a screen and take them as gospel, even if those numbers can fluctuate during the course of development. Right at the outset, project managers must be able to effectively let their stakeholders know that the estimates they develop are subject to change based on a number of factors (ironically, most of them driven by stakeholder demands). 

However, they must also communicate that the estimates are the best possible representations of a project’s scope at a given point in time – the beginning. They and their teams will work toward delivering the required capabilities on time, on budget and, most importantly, with the expected functionality. 

In the end, the most important thing to do is learn from past mistakes. That does not just mean comparing current projects to past efforts. It means learning from the likes of Kodak and other organizations that have taken some wrong steps. By planning things at the outset – and not adhering to traditional norms – project managers and development teams have a better chance to deliver software that delivers value to customers with the desired quality without running over schedule or breaking budgets.

About the Author

Lawrence H. Putnam, Jr. is co-CEO of QSM, a leader in software process improvement and systems development estimation. Larry's primary area of responsibility is to oversee the strategic direction of QSM’s products business. This includes meeting revenue goals, strategic product direction, customer care and research. Larry has over 25 years of experience in software measurement, estimating and project control. He joined QSM in 1987 and has worked in every aspect of the business, including business development, customer support, professional services and now executive management.