Facilitating the spread of knowledge and innovation in professional software development



Choose your language

InfoQ Homepage Articles Three Things to NOT Do with Your Software Development Projects

Three Things to NOT Do with Your Software Development Projects


Key Takeaways

  • Many project failures are the result of a project going over schedule and over budget. Estimating up-front can help avoid unrealistic commitments at the outset.
  • Top-down, scope-based estimation, before detailed planning, is more effective than bottom-up sizing and “guesstimates.”
  • Top-down estimation tools can help establish realistic project boundaries, both when projects are in the initial planning stages and as they progress. This is key for setting expectations and keeping stakeholders happy.
  • Overstaffing to achieve schedule compression is expensive and often ineffective. Project managers can use top-down estimation to visualize appropriate staffing and resource demands for their portfolios.
  • When projects change (as they inevitably will) due to stakeholder demands or unforeseen circumstances, project managers should reforecast to update the schedule.

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.

We need your feedback

How might we improve InfoQ for you

Thank you for being an InfoQ reader.

Each year, we seek feedback from our readers to help us improve InfoQ. Would you mind spending 2 minutes to share your feedback in our short survey? Your feedback will directly help us continually evolve how we support you.

Take the Survey

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Top Down based Estimates

    by Anuj Kumar,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    It depends which phase of project one is estimating. In case of RFP usually both top down and bottom up estimates are taken. In case of an existing project , there is already some learning in place from subsequent Releases. Top down approach is useful in long duration projects. In short duration projects , in order for it to be effective , Estimation team should have more insights from concerned team. As mentioned more often then not Estimated vs Actual post execution is not available. May be with ML based Predictive Analysis , such factual data can give more insights like how a particular Client works in past, Timely Approvals , CRs , Any other delay factors. If all of these are available to Estimator , then perhaps Top Down will be more effective. Till that time it is contextual and no single right way in my opinion.

  • Estimating is ask an expert

    by Eric Vargo,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "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."

    There are no "facts" when estimating. It is all guesswork, but in the case of talking to the developers, it is guesswork based on their many years of experience, so the developers have an informed opinion. The author then goes on to talk about comparing estimated to actual, which isn't linked logically to the assertion quoted here. To attempt to estimate a project without asking the subject matter experts (developers) their opinion on how long tasks should take is a fool's errand. Project managers do not have the expertise in software development to make estimates on projects by themselves. Attempting to pattern-match with previous projects that may look similar on the surface is lazy. Every project is different, but the differences aren't obvious. Talk to your developers and get their input. There is no magic tool that can substitute for experience and expertise!

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p


Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.