Software Engineering: Project Estimation – The Key To Success

Quality project management is all about the quality of one’s leadership and not their management abilities. Anyone can “push paper” but to not only get a task accomplished but done in an efficient and artful manner takes leadership capabilities which are often missing in business institutions.

Critical to the project management of a software development endeavor is having “a plan”; not a generic one that is easy to fall back on but a unique plan for each and every project that you may take on as a technical manager. This is because each and every project is a unique endeavor with a different known set of variables. Even if the scope of the project as well as the requirements to projects that you have recently accomplished, the factors making up this new project will be quite different if for nothing else than the time period in which it is being worked upon. Things are always changing in a business organization and any given period of time within it has its own unique set of environmental factors which can affect project development quite seriously.

Project estimation, is NOT the “black art” is has been made out to be by many people observing the process. Project estimation if done properly can be quite scientific in process and as a result has nothing to do with the “gut feelings” of a manager who is simply trying to promote him or herself.

Kris Hansen’s piece below introduces you to the many factors in this part of the project development process. And it is the most critical part of the entire process as it forms the basis of the long term plan should lead your effort to a successful conclusion.

Estimate your application development project

An architect’s perspective

Kris D. Hansen (kris.hansen@mac.com), Solutions Architect, Author

19 Jun 2007

Go here for article source…

IT architects are often involved in estimating software development projects, and estimation is a major contributor to the potential success or failure of a project. Many factors can affect the development of time lines and schedules. In this article, learn about estimation methods, get suggestions for ways to improve estimation, and discover what you should consider when forming an estimate.

Sometimes, software development projects fail. When they do, it’s not much fun and in most cases, those involved would just rather sweep the whole thing under the rug and move on. According to objective analysis, 48% of projects fail because of bad planning and estimating (It should be noted here that the actual percentage of project failure is somewhat higher and has held between 60% and 75% for many years. “For successful projects, the proportion of projects that are completed on time and on budget is only 16.2 percent. And, even when these projects are completed, many are no more than a mere shadow of their original specified requirements. Projects completed by the largest American companies have only about 42 percent of the originally proposed features and functions. Smaller companies do better, but there is still a pretty large gap. A total of 78.4 percent of their software projects will get deployed with only 74.2 percent of their originalfeatures and functions. -
Project Failure—The Numbers, Why, and What It Means(2004) http://www.crmlandmark.com/library/ProjectFailures.pdf“. – Black Falcon Software, Inc.) In these cases, the projects would have been successful had they been accurately estimated. If all the issues been factored in, the given schedule and cost would have been accurate.

Who should do the estimating? In some organizations, this is the domain of the project manager. In other organizations, estimation is performed by architects or by a collaborative effort between the project manager and the architect. In any case, for software development initiatives, someone who is familiar with software development should be involved in the process!

This article is an introduction to what you must consider when forming your estimate, as well as pitfalls to avoid. This article provides the architect’s perspective on estimation, and the focus is on practical tips and practices that can help you improve estimation accuracy.

Skills and competencies

Estimation is often done informally, quite often in a hallway on the way to a meeting, and generally with a dearth of information and a tight deadline. “Hey, what will it cost for us to get that FooBar 8000 up and running in Java?” Sound familiar? It’s incredibly tempting to quickly throw out a number, but avoid the temptation and read on!

An estimate is incredibly important. It is the crux of the project, forms the development work breakdown structure, and becomes the basis of the project plan that the project manager and the rest of the team are going to be living with for the duration of the project. Developers are going to either praise the estimate as sage wisdom or curse it as folly, but they’ll have to live by it. It’s also subjective and essentially a highly experienced guess at what it’s going to take to meet the objectives. The goal is to reduce the guesswork and provide as solid an estimate as possible.

The challenge in estimating

In technology projects, what you don’t know during the design is often what hurts you the most. At the outset of the project, the details of how the project is going to be completed are typically unknown. Also, many project-delivery methodologies shift the role and phase in which high-level and detailed design is performed.

A key activity in architectural estimation is differentiating between what’s understood completely and what’s ambiguous — and to clarify the potential complexity of the unknown components. If you are typically an optimist, be a pessimist during this part of estimation. Challenge your assumptions and thinking. Assign anything that’s different from what has been done in the past an increased risk factor, and think through the aspects of what might go awry.

Build an estimation framework

You can perform estimates in several ways. Much has been written about this process, and most experts disagree on everything except that estimating is difficult and that no matter how much science, psychology, or mathematics are applied, there’s still a subjective element to the estimate. The key is to pick a method, build an estimation framework, and be consistent with its application. If you’re consistent with your framework and you analyze your results, you’re in a good position to refine your framework and, in time, improve your estimation ability.

Within your framework, include a method of capturing and measuring actual data from projects. Track the effectiveness of your estimates by measuring them against the actual delivery; then, use this actual information when forming new estimates. You can compile and store a fairly simple repository of actual delivery times in a spreadsheet or database for future retrieval. You can perform this task as part of the project wrap-up, and it will be worth the effort.

This actual information is relevant when it comes to improving estimate accuracy. You can break down the aspects of the actual data into reusable components and use them to form building blocks for future estimates. For example, any tasks that your group frequently performs (such as server builds, database implementation, and database table development) mean JavaServer Pages (JSP) page-development time, servlet development time, and average time spent in project meetings broken down by team size. Any of this type of data broken down in a way that you can use to make informed assumptions about future activities helps reduce the guesswork in estimates.

The importance of estimates

If your organization understands the importance of accurate estimation and the unpleasant consequences of bad estimation, it’s more likely to take estimation seriously and provide adequate time and resources for doing it effectively. Ideally, if you can establish a culture of disciplined estimation, you can eliminate the requests for off-the-cuff estimates. People within your organization should also understand that estimates are guidelines within which to deliver projects and that you must occasionally recast the estimate during the project.

Failing to properly estimate your project can result in the effort being held up against an unrealistic measurement. Your project could be progressing smoothly, but appear an abysmal failure because of unrealistic expectations. Guidelines for developing proper estimates should be developed within the organization and formalized as part of your organization’s project-delivery methodology. Having a consistent way of conducting estimates includes engaging the right people at the right time in the project’s life cycle to perform the estimate.

If you find yourself in an organization that fails to take estimating seriously, you need to become the champion of quality estimates. Educate people within your organization on the effects of poor-quality estimates, demonstrate how quality estimates are conducted, and involve them in the process of creating a more accurate estimate. Explain the benefit of actual information, and clearly show the correlation between estimates and the risks associated with project overruns and failure. Show them the Institute of Electrical and Electronics Engineers (IEEE) “Software Hall of Shame” (see Resources), and explain that having a solid estimation framework will help keep your organization off that list.

This article includes a few methods of estimating that I’ve worked with. (See the Resources section for links.) Some of these methods will require additional research for you to use. Others are more pragmatic and are based on my experiences with development projects as a developer, project manager, and architect. The primary difference in estimation methodologies is in the units by which you define effort. What is the most relevant unit? That depends on what you’re building and how you can best quantify it.

Estimation tools

There are no magic tools that can perform estimates for you — expertise and judgement are required. Tools can assist in the design aspect to help you articulate and understand what you’re going to build. Tools are also available to assist in the application of estimation methodologies and best practices.

Design tools that I’ve found useful when designing software and forming an estimate include:

• IBM® Rational® Software Modeler: This tool is a Unified Modeling Language (UML) V2.0 editor based on Eclipse. It takes a model-driven architectural approach to software development in which you design your class objects and map interactions between them. This approach allows for a high-resolution depiction of the system but requires clear requirements to create the models. Within Rational Software Modeler, you can transform models into other models or export them to code, which can help bridge the gap between architecture and the development team by providing some example code rather than diagrams alone.
  
• Cost Xpert: This tool assists with estimates where requirements are not readily available. It leads you through many environmental and other factors and provides worksheets for various estimation approaches (function points, bottom up, and so on). One feature of the tool is that you select the project methodology as part of the process, and the tool takes this choice into account for the estimate — an important point, because each methodology has its own documentation and “ceremony” that affect the project time lines.
  
• Construx Estimator: This tool is provided free of charge (with a limited license), which is quite a value considering the features available. It takes input in the form of lines of code, function points, or other metrics, then applies a statistical probability analysis to determine the range of effort and duration required to complete the project. Actual data can be stored and used with this tool, as well.
  
• ISBSG Early Estimate Checker: Use this tool, shown in Figure 1, as a sanity check for your early estimates. Your estimate (in function points) is verified against the International Software Benchmarking Standards Group (ISBSG) repository of actual project results.Figure 1. Validating an early estimate against the ISBSG repository of actual results
• 
  

Many other tools are available, but the tools are of less importance than the fundamental approach you take toward estimating (although the tools can assist with keeping estimates consistent and reduce some of the effort associated with creating them).

One approach to estimating requires that you fully understand the objectives of what you’re looking to accomplish, then think about each detailed task required from initiation to completion. Typically, I create this kind of estimate as a Gantt chart in Microsoft® Office Project or Excel, as shown in Figure 2 to use as a starting point for brainstorming the steps in delivery. At this point, you should have a fairly clear idea of which software development methodology you’re going to use, because the phases and steps will change depending on your approach.

Figure 2. Sample Gantt chart for a Web application project estimated with function points

Estimation methods vary in their approach and results. As a result, each method often has in a different outcome, as shown in Figure 3.

Figure 3. Different outcomes for different estimation approaches in the same project

Often, the average of multiple estimation methods is useful in determining the effort, schedule, and cost. When you have clearly defined your objectives, you can use several methods to estimate your project, including:

• Team-based, bottom-up estimates: With this method, you give each member of your team a copy of the project plan, then ask each person to provide an independent “bottom-up” estimate for the project tasks. A bottom-up estimate is one formed by compiling an estimate of the detailed tasks in the plan. It’s a good idea also to ask team members to add any tasks they believe are missing and remove any that they think are unwarranted. You then bring everyone together and discuss their estimates, assumptions, and tasks. If you’re are a team lead or architect and plan to have your team provide bottom-up estimates during the project, this meeting can be a useful way of determining how your team estimates — important information when facing deadlines.
  
• Estimation repository: As mentioned previously, if you can establish a repository of actual units, you can form estimates based on them. Factoring in previous actual data helps increase the accuracy of estimates and can be used to form a “factory” approach to estimating in which after all the components are in the repository, you can form accurate estimates based on them.
  
• Lines of code: This approach is probably most useful when applied to traditional (nonvisual or Web-based) development efforts in which a line of code is actually written and productivity assumptions made about development effort decoupled from other factors. The fundamental questions you need to ask are how long will a developer spend writing a line of code and how many lines are going to be required for this project?
  
• Function points:
  Function points are concerned with determining the functionality and functional complexity associated with the target system. Typically, this involves counting the number of inputs, outputs, queries, files, and interfaces, then assigning a complexity coefficient to each of them. Function points are most useful when detailed requirements are available and the functions can be counted.
  
• Internet points: Internet points are based on function points, with additional descriptors based on the Web-development paradigm. For example, dynamic screens are differentiated from static screens.
  
• UML use-case points: For projects following the IBM Rational Unified Process®; (RUP®) of development or relying on UML models for design, you can use use-case points to estimate based on the number of scenarios and acceptance test cases in the initiative, as shown in Figure 4.Figure 4. Sample use-case in Rational
  
• Software Modeler V7
  
  

Environmental factors

If I asked you how long it would take you to write a line of code (in any programming language) that instantiated a variable and wrote output to a terminal, you would probably think that you could perform this simple task relatively easily and quickly and provide an estimate that showed a low level of effort. Now, if I told you that the program will support 3 million simultaneous users, must be written on the summit of Mt. Everest, and will have to support the Nepali language, does your estimate change? Of course. This is an extreme example, but in every case, the environmental factors affect delivery schedule and budget.

Some environmental factors to consider when estimating include:

• Team cohesion: How well does the team work together? If they haven’t had much experience together, this will increase the time it takes them to learn how to work seamlessly.
  
• Flexibility: Does the client (internal or external) insist that the code be deployed on a specific application server or use a specific third-party product? Any “immovable objects” in the project will add to the risk that an issue is discovered and must be worked around.
  
• Precedence: Does your team frequently perform this type of project for this client? If so, this reduces the risk. If not, don’t forget to add some time to train the client on the process. This is especially true of clients who are not familiar with software development projects and especially, iterative design methodologies.
  
• Environment and location: If the project has its own space that’s designed for quiet, uninterrupted work and for group/collaborative work, this is ideal. Anything else decreases productivity and increases the cost and schedule. If many members of the team are commuting great distances or working in an unconventional location (for example, the Mt. Everest summit), you must take this into account, as well.
  
• Software development life cycle tools: Any tools your team is using to facilitate software development can increase productivity. If your team is new to the tool set, invest in training and allocate time so that the team becomes productive with it.
  
• The client: Over the life of the project, your client will have to make decisions. Understanding how your client makes decisions and their “turnaround time” is important when estimating. If the team is stuck in a holding pattern until a decision is made, this can add days, weeks, or months to the project schedule.
  
• Nonfunctional requirements: It is important to fully understand the expectations around availability, scalability, maintainability, quality, usability, reliability, and other “-ilities” when creating your estimate. Many of these elements are qualitative, and your project may need to define them in very specific terms to achieve your objectives.
  
• Integration and testing: You may be building one small component, but that component may be connecting to a large labyrinth of other systems. If so, significant time will be required for integration and testing. When considering testing, don’t forget about performance-testing efforts and time that you may need to allocate to the remediation of performance defects.
  

Milestones

There is more information about estimation than this article can do justice to, but in the interest of leaving you with practical, usable information, here are some milestones to strive for in achieving more accurate estimates:

• Establish a consistent denominator of effort: Agree with other estimators within your organization on how effort will be denominated for similar projects. Are all Web applications going to be modeled with use-case diagrams and UML use-case points? Are all C programs that are written in the IBM AIX® environment going to be based on source lines of code (SLOC)? Being consistent on this across the organization and tracking the results in the repository will help build reusable organizational knowledge on estimation and delivery.
  
• Refine your estimation framework: After you have created your estimation framework and you can track the actuals against estimates, continue to improve the framework and the estimation approach to reach higher accuracy levels.
  
• Increased clarity of requirements and objectives: As an architect, I prefer to have minimal layers between me and the users articulating requirements. Having an opportunity to hear about the objectives and probe the requirements can mean the difference in interpreting requirements literally and designing something that elegantly meets the comprehensive needs.
  
• Build organizational knowledge: Essentially this involves having enough experience within your organization to not leave anything out when estimating. This sounds simple, but it’s an important consideration. Is the application deployment included in the estimate? Has user acceptance testing (UAT) been considered along with potential additional iterations that may come from UAT sessions?
  
• Develop an aversion to mandated time lines: Sometimes, estimates are requested where there’s a right answer and a wrong answer. These are not called estimates, they’re set time lines, and they require a different type of analysis — an analysis of what a team can accomplish within a set time frame. Be sure to differentiate this type of activity from estimation. When your organization has achieved this, it’s a major milestone that demonstrates the importance of estimates as an essential element of a successful project.
  
• Leverage industry information: Information may be available about productivity levels for the types of projects that your organization engages in. Also, check the benchmarks available from the ISBSG, which has compiled a cross-organizational repository of more than 4,100 project outcomes.

Summary

An estimate is a key element of the project plan and schedule, and the consequences of poor estimating are failed projects. To improve estimation, approach it with discipline. Select a methodology and an approach, measure results, and focus on improvement.

Resources

Learn

• “Planning and estimating a RUP project using IBM Rational SUMMIT Ascendant” (Per Kroll, developerWorks, May 2004) provides more detail on estimation methodologies and demonstrates their application to a RUP project.
  
• “How late are you gonna be?” (Joe Marasco, developerWorks, February 2002) provides a humorous look at the challenges and issues surrounding estimation, although more from a project manager’s perspective.
  
• “Why Software Fails” (IEEE Spectrum, September 2005) explains why software development projects go awry, including a list of the “Software Hall of Shame” that documents recent mega-failures. This article points to unrealistic project goals and inaccurate estimates of required resources as major contributors to project failure.
  
• “Additional Thoughts on Communicating Estimates,” part of David’s Software Development Survival Guide, has some interesting insights into estimation, including thoughts on how accurate your estimate should be.
  
• “Avoid common pitfalls during Java EE project estimation” (Chandan, JavaWorld.com, April 2006) highlights some of the potential issues when estimating software projects and includes some Java™-specific points.
  
• The ISBSG publishes estimation repository data of completed projects and also provides tools for software estimation and productivity analysis.
  
• In the Architecture area on developerWorks, get the resources you need to advance your skills in the architecture arena.
  
• Browse the technology bookstore for books on these and other technical topics.
  
• IBM on demand demos to learn about various software products and technologies from IBM.
  
• Stay current with developerWorks technical events and webcasts.
  

Get products and technologies

• Download a trial version of Rational Software Modeler.
  
• Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational, Tivoli®, and WebSphere®.
  
• Find more information about the Cost Xpert estimation tool.
  
• Construx offers a free tool called Construx Estimate that is well designed and can assist with estimate creation.
  

About the author

		Kris Hansen is an enterprise technology architect and author who has been working with IBM technologies for more than 10 years. He has achieved seven IBM certifications, including IBM Certified Solutions Architect, Solutions Designer, and Solutions Technologist. Kris was the VP/CTO of an IBM business partner based in Honolulu, Hawaii, where he led the architecture, estimation, and delivery of many successful projects. Recently, he returned to Canada, where he designs technology solutions for a rapidly expanding regional bank.