Here are some of the questions that were answered after the webinar with Bill Curtis, David Herron, and Dan Galorath.  They were answered on Cast software’s Facebook page.

What about aerospace component level software and how would you apply a cost factor their  complexity factors?

What is IFPUG Back Fired Points, how does it help?

Daniel Galorath Backfiring  means counting lines of code then using a number of lines per function point to approximate function points.  I think it is much better than nothing for a finger in the wind.  Many others in the industry object strongly to it.

Another question – What type of information is needed to start using a software analysis and measurement tool?

Bill Curtis First  you need to know how you want to use the results.  That will help you establish criteria for evaluating which of the various tools best meets your needs.  The Goal-Question-Metric paradigm is a good guide for determining what your measurement needs are.

Here’s  another question from the webinar – Would like to understand how we can  improve our ability to capture metrics (defect density either using effective loc and or functional point) for applications that rely heavily on database’s where the logic resides – e.g to map biz rules existing in table rows/columns etc?

Daniel Galorath Generally  you would count the work involved in building the database, not the entry of the data into the database itself. SEER will provide estimates of defect density, etc.  From my understanding CAST can provide measurement of this.

What  is the panel’s opinion on LLOC to FP translation such as QSM language by language table which they developed from their database.

Do you have to have a technology inventory?

How do you extend the IT governance to software suppliers? what requirements to pose to them?

Bill Curtis Customers are starting to write measurable quality targets such as robustness or security targets into their outsourcing contracts as the equivalent of service level agreements. They then establish a Quality Gate where all software received is measured and evaluated before being put in operation. If the supplier’s software falls below the quality target they must remediate the code or face a financial penalty.

Related posts:

1. The Future of Software Analysis Measurement Webinar Featuring Bill Curtis, David Herron and Dan Galorath We have some exciting events coming up this month with...
2. Estimation Plus Process and Measurement Rigor Yields More Successful Projects: SEER and Tracer It has been rewarding working with the Computer Aid  (CAI)...
3. Clean Energy Analysis Software The RETScreen Clean Energy Project Analysis Software (from Natural Resources...

Galorath’s Dr. Denton Tarbet offers thoughts on Project Monitoring & Control:

Galorath’s SEER SEM with Project Monitoring & Control (PMC) option provides a simple tool to overcome the schedule prediction shortcomings of traditional Earned Value Management (EVM) methods.   In particular since EVM expresses project performance in terms of cost, the method loses the predictability of evaluating schedule at complete (Schedule EAC).  As Walt Lipke Points out[i], “Eventually all budget will be earned as the work is completed, no matter how late you finish.  The Schedule Variance improves as the project progresses and ends up with $0 variance at the end of the project.”  Recall that SV = BCWP – BCWS which by definition will be 0 at the end of the project and the SPI will be 1.0.

To overcome that issue it is necessary to develop an earned schedule concept, with some additional effort.  In lieu of adding effort to the EVM process, simply incorporating the EVM metrics as snapshots of project performance into the SEER PMC tool using the project model developed for the initial project estimates provides output that parallels the EVM output for cost and schedule, but the value of the schedule projections is retained throughout the project. PMC forecasts a realistic schedule variance from plan in terms of schedule metrics which is calibrated to reflect the actual accomplishments.  In addition, it can be demonstrated that PMC provides the project control feedback to project management to provide a method to evaluate alternative options designed to improve project performance in an attempt to improve project schedule performance.

Robert Hunt, et al provides a relevant discussion of EVM on software intensive projects[ii].  Additional white papers and referenced articles on the Galorath website provide more detailed discussion related to using  SEER SEM and PMC to develop and manage a successful software intensive project[iii].

[i] www.earnedschedule.com/Docs/ES%20-%20an%20extension%20to%20EVM%20EVA-10%202005%20Lipke

[ii] Data & Analysis Center for Software (DACS) Software Tech News –EVM issue (Volume 12, No. 1) DACS Software Tech News

[iii] http://www.galorath.com/search_results.html?q=EVM&cx=016648429445878925337%3Ajnoaofuymoe&cof=FORID%3A11&sa=Search#1304

Related posts:

1. Performance Based Earned Value It has been very interesting reviewing Paul Solomon’s Performance Based...
2. More Software Project Failure / Challenge Information From CAI Bob Lawhorn of CAI, one of my favorite speakers, had...
3. Galorath Article “applying Earned Value Management To Software Intensive Programs Part 1 The new Galorath paper on performance based earned value went...

Dan will be speaking at the Chicago SPIN on November 12, 2009 on the topic of controlling software projects.  Estimation, planning, control, metrics, and maintenance for a total ownership cost view will be discussed.

The presentation is here: Chicago SPIN November 2009 Galorath Presentation Controlling Software Projects Development Is Only Job 1

PS Dan looks forward to his short visit to Chicago, his home town.  And is going to carefully avoid pizza, hot dogs, and Italian beef while he is there.

The flyer follows:

Chicago Software Process Improvement Network

(C-SPIN) Meeting

AT&T Center Campus

AT&T Institute 2501 W. Eagle Way at

Lakewood Blvd and Eagle Way, Hoffman Estates, IL 60192

Be sure to check the C-SPIN website (http://c-spin.net/) to confirm details.

SPECIAL DATE: Thursday, November 12, 2009

6:00 – 7:00 PM – Atrium: Registration, Networking, & Light Snacks

6:20 – 6:40 PM – Birds-of-a-Feather Topic – TBD

7:00 – 8:30 PM – Auditorium: Presentation

8:30 – 9:00 PM – Auditorium: Additional Q&A and discussion

Abstract:

Planning software development projects is never easy. Requirements, time-to-market, architectural and quality issues, staffing, risks and many other factors must be carefully considered. Development tradeoffs impact software maintainability andcan significantly impact total cost of ownership. Many factors other complicate software planning.  Software planners tend to underestimate the degree to which code degrades over time. Software development costs are only a portion of the total cost of ownership. Software maintenance can often be up to four times the initial development cost.

This session will provide a systematic approach to addressing total cost of ownership across the software lifecycle, including design for maintainability, development of measurement criteria, collection of metrics, and industry standards, guidelines, and best practice options. Parametric modeling will be discussed using the SEER platform as a specific example. Estimating block changes and their potential interdependencies and impacts will also be covered.

Biography

Over a period of three decades, Dan Galorath has established a reputation as a leading expert in project estimation, analysis, management and control. He has literally written the book on the subject (Software Sizing, Estimation and Risk Management, Auerbach Publishing). Dan realized early that there was a better way to develop accurate project estimates. Today SEER ® analysis tools from Galorath Inc. are saving millions of dollars for organizations worldwide. Galorath’s customer base reads like a who’s who of American and European industry: Airbus, Bank of America, Boeing, Ford Motor Company, Lockheed Martin, NASA, Raytheon, Siemens, and the U.S. Army, Navy, and Air Force, etc.

Dan lectures internationally and has published numerous articles and papers on software cost modeling, testing, software lifecycle error prediction and requirements definition. Dan was named winner of the 2001 International Society of Parametric Analysts (ISPA) Freiman Award presented to individuals who have made outstanding contributions to the theoretical or applied aspects of parametric modeling. Dan also received the 2009 lifetime achievement award for his contributions to estimation, planning and control from The Society of Cost Estimation and Analysis (SCEA)

Driving and Parking Directions

From I-90 Northwest Tollway, exit North on Barrington Road; take Barrington Road to Lakewood Blvd (2nd light) and turn East (right) onto Lakewood Blvd.  Turn right into the AT&T Campus Center’s West Employee Entrance (the first entrance past Eagle Way) and follow the signs to the West Parking Structures.  Parking in covered lot W3 is recommended.  Look for parking spaces near the west entrance/exit of parking structure W3. Then walk west from the parking structure to the Institute Building to the main door, which has a big ENTRANCE sign over the door.  The Institute is approximately 100 yards from the parking structure–back across the road you came on.  Visit http://www.c-spin.net for a map of the AT&T Campus Center.  (Additional parking is available in covered lot W2 as well as upper level parking lot W1.)

About C-SPIN

C-SPIN is a leadership forum for the free and open exchange of software process improvement experiences and practical ideas. We promote achieving higher levels of process maturity, software quality, and mutual respect. Companies, academic institutions, government organizations, and individuals are invited. For information about C-SPIN or the steering committee, contact Karen Mermel at kmermel@yahoo.com.

To receive future announcements electronically, register your e-mail address (include name, personal email address, company, and phone number) http://c-spin.net/newsletter/

Related posts:

1. Software Measurement and Total Ownership Costs… Dan’s Presentation at the NYC SPIN I had the opportunity to present at the New York...
2. Dan Galorath Presentation at SEER / Tracer Seminar In Tysons Corner October 2009 It was exciting to participate in a seminar with Computer...
3. Optimizing Development Projects With Multi-Vendor Approaches Using multiple vendors to develop software, each with their own...

I attended a very interesting session presented by Eric Druker and Dan Demangos of Booz Allen Hamilton and Richard Coleman of Northrop Grumman Information Systems, at the Department of the Navy Cost Analysis Symposium (DONCAS) last week covering improving Earned Value (EVM) analysis with statistics.  The speakers covered many of the common points regarding EVM weaknesses and showed some work they had done in helping solve some of these issues.

I found it interesting that SEER-SEM’s Parametric Progress analysis solves the same problems by looking at EVM type data and parametrics in concert.

The Problem Statement from the briefing included:

• Currently, the traditional Earned Value Management calculations suffer from several shortcomings that lessen their viability as a cost estimating tool

Estimates developed using most EVM equations are subject to tail-chasing whenever the CPI changes throughout the life of a program

• Tail-chasing is when the EAC for an over running program systematically lags in predicting the overrun, and vice-versa
• This occurs because these equations are backwards looking in regards to CPI; they lack the ability to predict changes in the CPI looking forward, and fail to perceive trends
• Tail-chasing is thus inevitable because “in most cases, the cumulative CPI only worsens as a contract proceeds to completion.”

Since the traditional EVM equations are simple algebra, and not based on statistical analysis, estimates developed using them are not unbiased, testable or defensible

• Testable estimates are those which can be subjected to decisions based on measures of statistical significance
• Quantitative cost risk analysis can not be performed on EVM data without subjective inputs

They pointed out that statistics are rarely used with EVM data because it generally falls under program management or financial control, not cost estimating.  This makes the data difficult for cost estimaters to acquire.  They provided several other reasons as well.

Their conclusions were that statistical EVM analysis of programs of a similar nature, or performed by a similar contractor, can be used as a basis to project patterns in the CPI over time.

They actually showed how, in the particular environment and commodity they were able to accurately predict where the program would end up based on its progress to “time now”

Excellent paper and worth a look when the papers are published on the DONCAS web site.

Related posts:

1. Applying Earned Value Management to Software Intensive Programs Part 4 For paper with figures see Applying Earned Value Management To...
2. Galorath Article “applying Earned Value Management To Software Intensive Programs Part 1 The new Galorath paper on performance based earned value went...
3. Galorath Article “Applying Earned Value Management To Software Intensive Programs Part 2 For paper with figures see Applying Earned Value Management To...

I received an email from the Josephson Institute of Ethics today that included this quote from a well known comedian: “The Sooner You Fall Behind, The More Time You Have To Catch Up.”

As I pondered the absurdity of the statement my mind focused on the many projects I have seen where this might have been taken seriously.  I recall, many years ago, preparing an estimate for a new project, an in-house typesetting system.  While this was not the most complicated software in the world, it took a lot at that time to do a decent job of typesetting with hyphenation, justification, kerning, leading, etc. all having to be implemented by hand generated code (how big is Knuth’s TEX  application?).  The customer had received a proposal from a trusted supplier (who did business reporting software) to build an entire system in just months.  When confronted with the implausibility, the vendor’s only response was, “I just know I can do this.”   Thank goodness the customer didn’t go for it.  If they had, what would have happened… After the original target day came and went there would have been a flurry… a descoping… more promises that “we are almost done, I just know it”… and after a year or two the project would probably have been canceled.

I recall another time, very early in my career… before parametric estimating, when we had a 4 terminal cluster system to develop.  We had a functional spec and a (probably poor) estimate.  We saw an ad in a computer magazine that said this particular programming language would cut costs to 10%.  The supplier came out and guaranteed it: even bidding fixed price and just a few weeks for the entire job.  I must admit I wondered how the vendor would do it… an assembly line type of setup where a team would pass information and where a chief programmer would allocate tasks or what.  When the big day came one guy showed up.  He worked about 24/7. The deadline came and went.  Still no worries… it was the world’s answer to software and it was fixed price.  Six months came and went. Now the vendor came in and said they couldn’t do it.  Four employees plus the vendor and 5 months later it was complete.

I have heard it said that if a cost performance index was below .95 or so, the project cannot catch up.  While no one wants their projects to be in trouble, isn’t it valuable to understand what you can’t catch up?

Viable plans help make successful projects.

Related posts:

1. Cloud Computing Can Save Time and Money: MIT CIO Panel Conclusion MIT Sloan’s CIO Panel identified cloud computing as a near...

It appears that this is the final version of the GAO cost estimating guide which provides guidance on preparing viable cost estimates both early in the process and throughout the life cycle. Congratulations to the team.  This is a great contribution to the industry and can, if used as intended create more successful projects.  I especially appreciate the focus on preparing a viable estimate of cost, schedule, etc. then applying earned value management (EVM) to that. So often, in the past we have seen a chasm between those that generated estimates and the EVM people.  These are two sides of the same coin.  The introduction follows:

Because federal guidelines are limited on processes, procedures, and practices for ensuring credible cost estimates, the Cost Guide is intended to fill that gap. Its purpose is twofold—to address generally accepted best practices for ensuring credible program cost estimates (applicable across government and industry) and to provide a detailed link between cost estimating and EVM. Providing that link is especially critical, because it demonstrates how both elements are needed for setting realistic program baselines and managing risk. As a result, government managers and auditors should find in the Cost Guide principles to guide them as they assess (1) the credibility of a program’s cost estimate for budget and decision making purposes and (2) the program’s status using EVM. Throughout this guide, we refer to program cost estimates that encompass major system acquisitions, as well as government in-house development efforts for which a cost estimate must be developed to support a budget request. The basic information in the Cost Guide includes the purpose, scope, and schedule of a cost estimate; a technical baseline description; a work breakdown structure (WBS); ground rules and assumptions; how to collect data; estimation methodologies; software cost estimating; sensitivity and risk analysis; validating a cost estimate; documenting and briefing results; updating estimates with actual costs; EVM; and the composition of a competent cost estimating team.6 The guide discusses pitfalls associated with cost estimating and EVM that can lead government agencies to accept unrealistic budget requests—as when risks are embedded in an otherwise logical approach to estimating costs. Since the Department of Defense (DOD) is considered the leader in government cost estimating, the guide relies heavily on DOD for terminology and examples that may not be used by, or even apply to, other federal agencies. Chapters 1–17 of the Cost Guide discuss the importance of cost estimating and best practices associated with creating credible cost estimates. They describe how cost estimates predict, analyze, and evaluate a program’s cost and schedule and serve as a critical program control planning tool. Once cost estimates have been presented to and approved by management, the chapters also establish the basis for measuring actual performance against the approved baseline plan using an EVM system. Those chapters explain how EVM, if it is to work, must have a cost estimate that identifies the effort that is needed—the work breakdown structure—and the period of time over which the work is to be performed—the program schedule.7 In essence, the cost estimate is the basis for establishing the program’s detailed schedule, and it identifies the bounds for how much program costs can be expected to vary, depending on the uncertainty analysis. When all these tasks are complete, the cost estimate can be used to lay the foundation for the performance measurement baseline (PMB), which will measure actual program performance. Since sound acquisition management requires more than just a reliable cost estimate at a project’s outset, chapters 18–20 provide guidance on converting the cost estimate into an executable program and a means for managing program costs. Our program assessments have too often revealed that not integrating cost estimation, system development oversight, and risk management—three key disciplines, interrelated and essential to effective acquisition management—has resulted in programs costing more than planned and delivering less than promised. Therefore, chapters 18–20 address best practices in implementing and integrating these disciplines and using them to manage costs throughout the life of a program. OMB has set the expectation that programs will maintain current estimates of cost. This requires rigorous performance-based program management, which can be satisfied with EVM. Chapters 18–20 address the details of EVM, which is designed to integrate cost estimation, system development oversight, and risk management. Additionally, for programs classified as major acquisitions—regardless of whether the development work is completed in-house or under contract—the use of EVM is a requirement for development, as specified by OMB.8 The government may also require the use of EVM for other acquisitions, in accordance with agency procedures. Since linking cost estimating and EVM results in a better view of a program and allows for greater understanding of program risks, cost estimators and EVM analysts who join forces can use each other’s data to update program costs and examine differences between estimated and actual costs. This way, scope changes, risks, and other opportunities can be presented to management in time to plan for and mitigate their impact. In addition, program status can be compared to historical data to better understand variances. Finally, cost estimators can help EVM analysts calculate a cumulative probability distribution to determine the level of confidence in the baseline. But bringing a program to successful completion requires knowing potential risks and identifying ways to respond to them before they happen—using risk management to identify, mitigate, and assign resources to manage risks so that their impact can be minimized. This requires the support of many program management and engineering staff and it results in better performance and more reliable predictions of program outcomes. By integrating EVM data and risk management, program managers can develop current estimates at completion (EAC) for all levels of management, including OMB reporting requirements. Therefore, chapters 18–20 expand on these concepts by examining program cost planning, execution, and updating.

Related posts:

1. GAO Cost Estimating and Assessment Guide Released Congratulations to the GAO team for releasing the “Cost Estimating...
2. GAO Cost Assessment Guidebook The GAO cost assessment Guidebook is something you should keep...
3. Galorath Article “Applying Earned Value Management To Software Intensive Programs Part 2 For paper with figures see Applying Earned Value Management To...

For paper with figures see Applying Earned Value Management To Software Intensive Programs Final   This article was originally published in the Software Tech News, Volume 12, No. 1, April 2009.  The web site for more information about this publication is www.softwaretechnews.com  This paper illustrates how to achieve more successful projects with estimation, planning and control.  Cost estimating as well as effort, schedule, and risk are included with illustrations from SEER for Software (SEER-SEM)

Using an analytic process to project cost and schedule based on actual performance

Once the requirement definition is complete; the cost and schedule baseline has been established; the appropriate metrics have been selected; and a PBEV system is in place, the final challenge is to implement a process that quickly and accurately estimates final cost and schedule based on actual performance.  This analysis is best accomplished using an analytic/parametric process.  Galorath Incorporated calls this process SEER Control (formerly Parametric Project Management and Control.  The purpose of SEER Control is to provide an understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan.  SEER Control applies a four-dimensional (4-D) approach for assigning progress to the development of each program/application that is part of the project. The first dimension is Software Development Life Cycle (SDLC) primary activity completion for the development of a specific program/application.  Each SDLC primary activity, in turn, is assigned progress according to a weighted combination of three other dimensions: artifact completion, milestone completion, and defect discovery/removal.   SEER Control provides an “at-a-glance” indication of project status.  This concept is presented in Figure 5, Understanding and Tracking Defects and Other Metrics.  This analytic process uses actual performance to re-estimate the anticipated cost and schedule.  The “dashboard” at the bottom of Figure 5, presents a health and status indicator for the project.  In Figure 5, five metrics are tracked, schedule variance, time variance, cost variance, size growth, and defects discovery and removal.  SEER Control allows you to track size growth and actual defect metrics. Size growth can indicate growth in requirements and can be an indicator of why a project may be off track. The profile of defects reported and removed is compared against the estimated time phased defects.

In Defects Tracking, the analyst will see the estimated defects reported and actual defects reported.  When reported defects are lagging the estimated defects, that could indicate that not enough testing is being performed, especially if the actual defects removed are tracking with the estimated defects removed.  Conversely, if the actual defects removed lag the estimated, but defects reported tracks with the estimated, then you may not have enough programming resources to make fixes.  If actual defects reported and removed follow the general profile of the estimated, but are higher or lower, then the baseline project estimate may be over or underestimated.   SEER Control also tracks the Time Variance (TV). The TV is the cumulative difference in schedule months between earned value and the baseline plan up to the date of the latest snapshot. When a rollup element is selected, the time variance is equal to the worst time variance of its subordinate programs. Positive values are favorable, negative values are unfavorable.  SEER Control also tracks the Time Performance Index (TPI).  The TPI is the time efficiency achieved from the beginning of development to the date of the latest snapshot. A performance index greater than one is favorable. A performance index less than one is unfavorable. The Time Performance Index (TPI) is the ratio of the elapsed time from the Actual Start Date to the baseline planned date and the elapsed time from the Actual Start Date to the snapshot date.

Other metrics can be tracked.  In addition to the health and status indicator using the red, yellow, green indicators, this automated application re-baselines the program estimate to present a revised cost and schedule prediction.

Figure 5, Understanding and Tracking Defects and Other Metrics

At the heart of the PPMC vision is the desire to forecast the final project outcome based on performance to date.  One of the primary goals of PPMC is to provide adequate supporting documentation (charts and reports) to support the software project management process and to satisfy stakeholder needs.

Conclusion

Using earned value to plan and manage software intensive projects can prevent expensive failures.  Earned value should be based on the foundation of establishing the requirements, developing a reliable baseline estimate for cost and schedule, selecting effective software metrics, applying Performance-Based Earned Value (PBEV), and using analytic processes to project cost and schedule based on actual performance.

Related posts:

1. Galorath Article “applying Earned Value Management To Software Intensive Programs Part 1 The new Galorath paper on performance based earned value went...
2. Galorath Article “Applying Earned Value Management To Software Intensive Programs Part 2 For paper with figures see Applying Earned Value Management To...
3. Applying Earned Value Management to Software Intensive Programs Part 3 For paper with figures see Applying Earned Value Management To...

For paper with figures see Applying Earned Value Management To Software Intensive Programs Final

Establishing a Process for Requirements Definition and Developing the Technical, Cost and Schedule Baselines

A software program life cycle cost estimate is the most knowledgeable statement one can make at a particular point in time regarding effort/cost, schedule, staffing, risk, and reliability.

However, the most important business decisions about a software project are often made at the time of minimum knowledge and maximum uncertainty.   Cost estimators recognize that the estimate is not a point, but rather a well formed estimate defined by a probability distribution.

A well defined process is critical to defining the requirements and completing the initial cost and schedule estimate.� The proper use of PBEV provides for integration of project technical scope, schedule, and cost objectives; and the establishment of a baseline plan for performance measurement.  Additionally, the use of an analytic tool to project likely cost and schedule based on actual performance provides for realistic projections of future performance.  Success of the project can be aided by defining the best objectives, by planning resources and costs which are directly related to those objectives, by measuring accomplishments objectively against the plan, by identifying performance trends and problems as early as possible, and by taking timely corrective actions.

A CMMI tutorial recognizes that people, process, and technology are major determinants of product cost, schedule, and quality.  We all realize the importance of having a motivated, quality work force but even our finest people can’t perform at their best when the process is not understood or not operating at its best. Figure 1, People, Process, Technology are Keys, presents this concept.

Figure 1, People, Process, Technology are Keys

In the book, “Software Sizing, Estimation and Risk Management” (Dan Galorath and Michael Evans, 2007) a ten step process is presented for program requirements generations and estimation.  Figure 2, 10 Step Software Process, outlines the ten steps.

Figure 2, 10 Step Software Process

While the Galorath process includes ten steps, other process may include more or less steps (e.g. the GAO Cost Guide includes a 12 steps process).  Note specifically the importance of step 4, estimating and validating the software size metric.  The key here is to establish an auditable, repeatable set of steps to establish the requirements and develop the baseline estimate of cost and schedule.  This is the key to articulating an accurate requirement and establishing a reliable baseline for cost and schedule.

This article was originally published in the Software Tech News, Volume 12, No. 1, April 2009.  The web site for more information about this publication is www.softwaretechnews.com

Related posts:

1. Galorath Article “applying Earned Value Management To Software Intensive Programs Part 1 The new Galorath paper on performance based earned value went...
2. Applying Earned Value Management to Software Intensive Programs Part 4 For paper with figures see Applying Earned Value Management To...
3. Applying Earned Value Management to Software Intensive Programs Part 3 For paper with figures see Applying Earned Value Management To...

The new Galorath paper on performance based earned value went live on the DACS site today.� It is so important to have viable estimates as the basis of plans for earned value to be valuable.� For paper with figures see Applying Earned Value Management To Software Intensive Programs Final� The paper’s introduction follows:

By Robert P Hunt (Galorath Incorporated), Paul J. Solomon (Performance-Based Earned Value), and Dan Galorath (Galorath Incorporated)

Often, traditional earned value approaches do not deal sufficiently with the idiosyncrasies of software intensive programs.  However, successful management of software intensive programs can be achieved by focusing on establishing the requirements, developing a reliable baseline estimate for cost and schedule, selecting effective software metrics, applying Performance-Based Earned Value® (PBEV), and using analytic processes to project cost and schedule based on actual performance.

Introduction

The Department of Defense estimates that software now accounts for 40% of all research, development, test and evaluation (RDT&E) spending[1].  Software intensive projects that achieve their original cost and schedule projections are rare.  Many information technology projects have been declared a disaster area by commercial and government managers.  These projects have been too costly, too late, and often don’t work right.  Applying appropriate technical and management techniques can significantly improve the current situation.

Inaccurate estimates can threaten project success causing poor project implementations, the shortcutting critical processes, and emergency staffing to recover schedule.   The lack of well defined project requirement and specifications may result in significant growth in cost and schedule.   Symptoms of this growth may include constantly changing project goals, frustration, customer dissatisfaction, cost overruns, missed schedules, and the failure of a project to meet its objectives.

PMI published an analysis of several government defense and intelligence agency large-scale acquisition programs that experienced significant cost and schedule growth.  This analysis shows that several critical factors need to be addressed in the pre-acquisition phase of the acquisition cycle.  The principal causes of growth on these large-scale programs can be traced to several causes related to overzealous advocacy, immature technology, lack of corporate technology roadmaps, requirements instability, ineffective acquisition strategy, unrealistic program baselines, inadequate systems engineering, and work-force issues.[2]

This paper will discuss some key element associated with:

• Establishing a process for requirements definition and developing the cost and schedule baseline
• Developing a reliable cost and schedule baseline,
• Identifying critical software management metrics,
• Applying Performance-Based Earned Value (PBEV), and
• Using an analytic process (such as SEER Control; formerly called Parametric Project Monitoring and Control (PPMC)) to project cost and schedule based on actual performance.

[2]PMI Project Management Journal, March 2008; “Best Project Management and Systems Engineering Practices in the Preacquisition Phase for Federal Intelligence and Defense Agencies” by Steven R. Meier

This article was originally published in the Software Tech News, Volume 12, No. 1, April 2009.  The web site for more information about this publication is www.softwaretechnews.com

Related posts:

1. Galorath Article “Applying Earned Value Management To Software Intensive Programs Part 2 For paper with figures see Applying Earned Value Management To...
2. Applying Earned Value Management to Software Intensive Programs Part 4 For paper with figures see Applying Earned Value Management To...
3. Applying Earned Value Management to Software Intensive Programs Part 3 For paper with figures see Applying Earned Value Management To...