Why Do Software Projects Always Cost More?

Nov 22, 2005

Rajesh Setty

“On time, under budget” is the dream. But most software projects cost more and take longer than planned. Most people have given up; assuming this is the norm rather than the exception.

So, the question is: Why? Here are a few ideas that may help get started answering that question.

Managing Project Management

Project management is many things but first it’s expectation management. A good project manager should know how to set the right expectations with all the stakeholders of the project. Throughout projects new change requests are made. Each individual request seems small and manageable. However, an aggregate of such requests can easily change the size and scope of the project significantly. So the art of managing the initial and changing expectations has to be mastered.


The key part of each project comes even before the project begins. This is in the estimation phase of the project. Even if you have executed a similar project in the recent past, it is best not to conclude the effort involved in executing the project will be the same.

The big difference will be that the users for this project are different. That means different expectations. The estimation of each project has to take into account all the unique variables that are involved in that particular project.

Here are few other things that might change and may affect your project comparison estimates:

  • The team that will execute the project.
  • Versions of software used.
  • Size of the project: Number of users, locations, etc.
  • Types of end-users.
  • The deployment environment.
  • Focus on Design

    Every hour you spend on design will yield great dividends later. The problem though is that the output of design usually is a set of documents. If the right expectations are set, however, this may be just fine. Otherwise, you may need to explain why there is no “measurable” progress on the project.

    The Team

    We all know how difficult it is to get the "perfect” team on a project. When we assemble the resources for the project, we know that we are using the best of what is available to us at that time.

    What is often forgotten forget is that once the resources are in place, we expect them to be the “perfect” fit for the project. It is important for the project leader to know the strengths and weaknesses of the team members and factor that into the work-design for the project.

    Involving Users

    When is a good time to get closer involvement with the users? No, the right answer is not throughout the project. That may harm rather than help. So, what is the right answer? Balance.

    Involving users more than required will put a drag on the project and involving them less than required will create a lack of “buy-in”. Your first objective will be identify the influencers among the users and try to get their buy-in. Once the influencers buy-in, they will influence the others.

    Impact Analysis

    Very rarely do you come across projects that are standalone in nature. Projects typically plug-in to an enterprise ecosystem that is already in place.

    This important factor should be remembered throughout the project. Your project may be impacted by changes in the other parts of the enterprise ecosystem that touch your project or your project may impact other projects (and probably will).

    It is important to know where your project fits in the ecosystem and understand all the dependencies (both ways) for the project.

    Client and Industry Dynamics

    This is usually the piece that gets missed. For example, suppose you are executing a year-long project for a client (or for your own company) that is in a fast changing industry. Even if the users guarantee you the requirements are “frozen,” you rest assured that they are going to change sometime during the project.

    That has to happen because the business will not be the same a year from now. So, what can you do? For one, you can start looking at items above and beyond the project deliverables; understand the company’s business at a deeper level and look at the industry dynamics more carefully. Then, factor that information into your estimation methodology.

    Second, you could break the project into smaller pieces and create two or three sub projects of six months or less in duration. Once you complete the first project, you can scope the subsequent ones separately.

    Third, collect some history and metrics on past projects in the same department and use that information in your estimation process.

    We all know that what I touched on here is just the tip of the ice berg and each one of this topics would probably make for a good book, but it should provide you some food for thought.

    Rajesh Setty is the chairman of CIGNEX Technologies, an open source consulting services and software solutions company, which he co-founded in late 2000. Setty’s latest book is "Beyond Code: Learn to Distinguish Yourself in 9 Simple Steps!" (Select Books - 2005). Setty speaks and writes frequently on topics that include entrepreneurship, leadership and open source.


    0 Comments (click to add your comment)
    Comment and Contribute

    Your comment has been submitted and is pending approval.



     (click to add your comment)

    Comment and Contribute

    Your name/nickname

    Your email


    (Maximum characters: 1200). You have characters left.