I saw a demo today of our new labor rate calculator.  It takes in various labor rate drivers and computes a viable labor rate.   It even evaluates the cost of equipment, electricity, floor space, insurance, etc.

This is a great step forward in the “should cost” and will cost for product manufacturing.  Buying organizations can describe the problem and see what a fair labor rate for the region, country, machine, etc.  Mixed currencies are supported as well.

The following is a small example of the kinds of information that can be specified  In this case it is configured for manufacturing.

Related posts:

1. Coffee Maker Cost Estimation Using SEER for Manufacturing The department of Industrial Management & Systems Engineering at West...
2. SEER Estimate By Comparison Professional Released To All Users                 The SEER...
3. Estimating Best Practices The following are the bullet points from Dan’s paper on...

I stumbled across a working draft of an excellent document on my hard drive, produced, I believe, by a gentleman from Texas Instruments some years ago.  I thought this list of why we estimate cost and schedule was excellent and still relevant.

Why We Estimate Schedule & Cost

• To scope proposed tasks
• To explore alternative system concepts

design to cost/budget

• To explore alternative design concepts
• To explore alternative proposals for enhancements and upgrades
• To identify key design elements
• To identify key process parameters

prioritize needs vs wants

• To identify key assumptions
• To identify and quantify uncertainties
• To identify tasks and their relationships
• To assess schedule feasibility
• To identify, allocate and schedule resources
• To assess an organization’s ability to perform within targeted costs
• To evaluate the consequences of internal and external constraints
• To establish achievable objectives
• To establish a basis for quality service
• To establish commitments
• To bound the risk against customer needs
• To balance levels of risk against customer needs
• To provide a basis of successful risk management

build vs buy analysis

• To prepare successful proposals
• To evaluate proposals from competing bidders
• To establish baselines for project tracking

enhance/reuse vs redesign analysis

• To predict life-cycle costs
• To predict returns on investments
• To provide information for establishing business and investment strategies

Related posts:

1. Step One: Establish Estimate Scope and Purpose Establish Estimate Scope and Purpose Define and document expectations. When...
2. Step Seven: Estimate Validation and Review Step Seven: Estimate Validation and Review At this point in...
3. Design To Cost Metrics Can Help Increase Project Value While Reducing Cost An interesting paperBy Quentin Redman and George Stratton in the...

Embedded design integration is the integration of all efforts (hardware, software, etc.) within an system that is typically dedicated to perform one or a few functions. Typically there are real-time computing requirements involved in these types of designs. Integration costs can at times become a considerable portion of the overall cost on a project. The continuous introduction of newer technologies continue to drive up integration efforts.

Use of old factors that estimated Integration Assembly and Test ( IAT) as a function of overall top effort were weak before but now can produce dangerously low estimates. Part of the reason why IAT costs have classically been painful can be attributed to the fact that it is at this stage where the complicate blend of hardware to hardware or hardware to software comes to a point and must all meet specifications at once! What worked in recent simulations or in isolated tests now becomes painfully clear won’t work at a combined level. This invariably leads to the continuous waves of adjustments, partial redesigns, re-architecting, retests in a desperate effort to close in on the minimum requirements.

For estimation purposes, careful consideration has to be given to the work break down structure of the embedded systems being modeled to ensure adequate estimation of integration effort and risk are covered at all levels. For instance, just applying a 10-35% IAT factor at an enclosure level in order to capture integration of all board and SW underneath it might be okay for some simple systems but not newer technologies which bring along extra complexities. An example is where the design involves custom components (ASICs, FPGAs, etc) which in turn have embedded processors within their fabrics. In these System on a Chip (SOC) designs, it make sense to break out the cost of integrating the SW onto the chip itself. At the next level one could add another rollup to cover the integration of SW to the main board running a general purpose processor, etc.

Another example could be designs that involve multiple separate custom chips running on the board since there might be a significant effort to get these chips to work with each other.

In our SEER H hardware model, we break out these sections with a separate roll up to calculate the IAT. At this point, we take care to set the parameters that describe the complexity of the effort and the experience of the folks doing the work. If this type of design is done often, we would create a knowledgebase (default template) to capture and standardize the estimation approach. As can be seen, many designs can involve layers of IAT which in turn can drive up the final overall IAT numbers considerably beyond 35%.

Related posts:

1. How Hard Is A Hardware Model Estimating the effort, schedule, labor & materials, operations & support...
2. Estimating Systems Engineering…. The Upcoming Book.. and SEER I had the opportunity to review Dr. Ricardo Valerdi’s (MIT)...
3. CMMI and SEER Applicability: Estimation, Planning & Control Processes and SEER Integration Galorath’s Ton Dekker presented this paper covering SEI’s CMMI and...

Galorath’s Dr. Denton Tarbet has been studying the estimation and analysis of service oriented architectures for some time.  He provided this post regarding SOA.  For further information, please email us.

SOA is often considered to be a means to provide IT services at lower cost.  However, consideration should be given to what is meant by “cost” in the migration to an SOA for any organization.

For proper consideration of cost tradeoffs we consider the value to the customer, i.e. does the migration to SOA really provide a benefit to the stakeholders for the system? To consider that, first consider that SOA is not a process but it is an architecture. Relying on common understandings of architecture related to buildings, it is not sufficient to say the architecture is the blueprints, the drawings, the physical structure. What made many of Frank Lloyd Wright’s buildings so great was that he considered the architecture to include the total of the building within its specific environment.  As an example, Wright’s Fallingwater: http://www.greatbuildings.com/buildings/Fallingwater.html

With that concept in mind, an SOA approach must consider its environment, i.e. the customers and how the resulting services will be used.

Within SOA the concept of service should be based on customer value.  So the “service” in SOA isn’t really about technology, objects, interfaces, granularity, messaging, reuse, product stacks, standards, platforms, openness or almost anything else. It’s about mapping business processes to a software implementation that facilitates stakeholder outcomes and value.  To effect that end, we rely on a solid estimation from SEER-SEM and SEER for IT to develop the effort, schedule and risk to provide the basis for tradeoffs to provide the best Return on Investment (ROI).  See additional:

Common Misconceptions About Service-Oriented Architecture –  Crosstalk, Nov 2007

http://www.xml.com/pub/a/ws/2003/09/30/soa.html

SEER Support for Estimation of Effort and Schedule in a Service Orientated Architecture (SOA)

D Tarbet

SEER effort/schedule estimation suite is being applied to systems being developed within a Service Oriented Architecture (SOA) methodology. Service Oriented Architecture as a methodology for integrated systems is often advertised as a method to significantly reduce costs and risk of development, implementation, and maintenance of IT systems.  However, there are significant challenges in developing a valid estimate which provides both effort (and cost) and schedule confidence levels.  In order to understand how SEER is being applied, we will first define SOA as used in this discussion.

SOA is a way of designing systems composed of services that are invoked in a standard way.  As an architectural style, SOA is neither a system architecture nor a complete system. An SOA-based system is composed of the following:

1. Services that are reusable components that represent business or mission tasks, such as customer lookup, weather, sensor placement, account lookup, or credit card validation.
2. Service consumers that are clients for the functionality provided by the services, such as end-user applications, systems, or even other services.
3. SOA infrastructure that connects service consumers to services.

Typically SOA is considered for improving or reducing IT development costs.  However, the method has application to a wide range of situations.  Our applications have been the redeployment of existing complex ground systems from a traditional “mainframe” type application to an SOA infrastructure.  The goal of incorporating an SOA methodology is to expand the potential community of users for the system.  In developing estimates, we have encountered many of the typical problems referenced by the literature.  For example, in “How to Cost an SOA Project” and “How Service-Oriented Architecture (SOA) Impacts Your Infrastructure,” David Linthicum notes:

• The design and testing of SOA components must be more robust than a typical “single application” software component, and
• The infrastructure must be evaluated with the ability to accept a level of user that normally cannot be defined with the initial requirements for the application.

Design and testing of an SOA component must consider that the full range of application is not understood since the component may be utilized for a modification of the expected utilization in the future.  That potential for a wide range of users requires a more robust design and testing to ensure that the component will support the full range of users.

That range of users is precisely why the infrastructure is difficult to estimate at project conception.  Since an SOA project is designed to accept future users that are not defined at the start of the project, it is not possible to design the system with sufficient throughput and network capacity to accept all future users — therefore the design must plan for growth in the user community.  Typically SOA projects are being implemented in systems such as blade servers where the applications can be dynamically allocated to available blade capacity.  In a blade system additional processing capability can be easily added with additional blades operating under the dynamic allocation of the blade operating system within the blade center.

Estimation of the components is being accomplished within SEER for Software with considerations for the more robust design and testing required.   However, for the infrastructure we have incorporated the use of SEER for Information Technology (SEER  for IT) which includes a comprehensive modeling capability to define and estimate the infrastructure.  SEER for IT infrastructure allows the modeling of the system elements such as the systems analysis, design trade-offs, selection and implementation of the computing servers, the networks required, database schema design, and database implementation.

In our applications we have developed both an infrastructure model and the software model for the application components. In the case of the infrastructure model we have incorporated vendor data and user experience in defining costs of components, lead times to acquire, acquisition planning and costing, installation including cabling of networks, network installation, operations, and maintenance of vendor supplied systems.  The SEER for Software model for the applications components should account for the additional design and testing effort required for SOA projects.  In our applications, we incorporated the parameters for “Reusability Level Required” and the “Software Impacted by Reuse.” We considered the SOA applications components in our specific applications to support a limited solution space so we set the Reusability Level to:

• Least  set to Hi-
• Likely set to Hi
• Most set to Hi+

Which is a setting for software to be reused within a single application area.  That definition applied to our application and resulted in a 12 to 13% increase in cost over a typical application development.  If the SOA component were expected to be more widely applied, we would set that parameter correspondingly higher.  For most applications, we would expect to set the amount of the software to be reused within that SOA component to 100%.

The application of this method has provided our client with useful estimation information from which to develop budget requirements for both cost and schedule based on a confidence level analysis rather than a single point estimate.  An interesting side benefit to the infrastructure modeling has been the requirement for a detailed understanding of the infrastructure as designed in order to define the inputs to the infrastructure model.

Related posts:

1. Software as a Service vs. Service Oriented Architecture vs. Cloud Computing I have seen a lot of confusion as to the...
2. Some Gottchas of Estimating Service Oriented Architecture Systems (SOA) As Fredrick Brooks said “there are no silver bullets.” Unfortunately...
3. Old MIT Lincoln Lab SEER Writeup SEER for Software, Hardware, ICs, Operations & Support When MIT Lincoln Labs was doing their RSSP project they...

The following are the bullet points from Dan’s paper on estimating best practices.  Using these best practices can increase project success dramatically.

• Decide Why You Want An Estimate
• Map Estimation Goals To Estimate Process Maturity & Develop Plan To Achieve The Maturity
• Have A Documented, Repeatable Estimation Process
• Evaluate Total Ownership Cost; Not Just Development
• Estimate A Range And Pick A Point For The Plan
• Re-estimate The Program When It Changes
• Avoid Death Marches: Programs With Unachievable Schedules Are Likely To Fail And Drain Morale

• Keep A History: Start An Enterprise Database NOW
• Business Case: Evaluate ROI In Addition To Costs
• Convert Expert Spreadsheets Into A Common Language
• Make The Estimating Process As Simple As Possible; But No Simpler
• Be Proactive: The Process Is Important, The Tools Go Along With The Process
• Get Buy-in From Program Managers
• Hold People Accountable: Center Of Excellence Can Prepare Estimate But Program Managers Must Own Them
• Tie The Estimate To The Plan
• Track Progress Vs. Estimate Throughout The Life Cycle
• Estimate Schedule As Well As Effort (Cost) For Complete Picture
• Tie The Business Case Into The Estimating Process
• Attack Non-productive Rework As Part Of The Process
• Have clear definitions: What does complete mean.  What activities are included and excluded (E.g. development only or total ownership; help desk included or excluded, etc.)   Which labor categories are included and excluded in the estimate (e.g. are managers included?  Help desk? Etc.)
• Don’t ignore IT infrastructure and IT services costs
• Tracking defect sources can go along with the process

Related posts:

1. GAO Cost Estimating and Assessment Guide Released Congratulations to the GAO team for releasing the “Cost Estimating...
2. Estimating United Conference Papers Available On the Web Follow this link to see some of the estimating united...
3. Risk / Uncertainty In SEER and Project Management The question was asked “what probability should I estimate at” ...

Dr. Ricardo Valerdi of MIT sent me a pre-publication copy of his upcoming IEEE article. Here is the abstract:

“Engineering cannot wait until all phenomena are explained. Engineers may work effectively, often for centuries, with heuristics. This paper provides thirty one heuristics that have been inspired by the development and application of a systems engineering cost estimation model. The objective of this paper is to present such heuristics in a simple manner so that they can benefit systems engineering researchers and practitioners that develop, calibrate, and use cost models.”

I enjoyed the article (as I do with pretty much everything Ricardo produces).  Such simple truths. A few heuristics quoted from the paper follow:

“Don’t assume the original statement of the problem is necessarily the best, or even the right one.”

“Let the available data drive the application boundaries of the model.”

“Design the rating scale according to the phenomenon being modeled.”

The full article is available, as provided by Ricardo here: “Heuristics for Systems Engineering Cost Estimation.”

Related posts:

1. Estimating Systems Engineering…. The Upcoming Book.. and SEER I had the opportunity to review Dr. Ricardo Valerdi’s (MIT)...
2. CECIM: A Capability Improvement Model For Cost Engineering Being a major fan of repeatable process for cost and...
3. Make or Break: Why Accurate Cost Estimation Is Key A recent articlefrom executivebrief.com sent to me By Dr. Ricardo...

From Galorath’s Dr. Denton Tarbet:

CMMIis a model that can be applied to effect a change in the way an organization (or company) performs on specific projects. The Levels of CMMI:

1. Process unpredictable, poorly controlled and reactive
2. Process characterized for projects and is often reactive
3. Process characterized for the organization.
4. Process measured and statistically controlled
5. Emphasis on continuous improvement in the process with a goal of more fully meeting the cost/performance objectives of the organization.

Key activities for CMMI Level 4 include:

1. Set the organizational Process Performance goals and establish a Quantitative Project Management methods to ensure processes are measured and statistically controlled.
2. Select processes that support the organizational goals. If as in most companies goals include developing products on time and on budget in order to increase customer satisfaction and improve profits
   1. You need a valid estimating process that provides a confidence based project plan
   2. You need to measure cost and schedule at team task level
   3. Predict future project performance (actual estimate based on past performance not a belief that the project performance will improve with no external action)
   4. Take optimal corrective actions early
3. Develop organizational baselines that can be used to monitor project predictions based on past performance and enforce corrective action when baselines are breached, ie establish the upper and lower control limits that force project corrective action.
4. Use a predictive model such as a Performance Based Earned Value Model to predict the project future performance
5. Take corrective action to mitigate risks, improve performance, prevent issues, and optimize project performance.

The question regarding level 4 and the application of SEER models for Process Performance Modeling has been addressed in the SEER for Software suite with the addition of Project Monitoring & Control (PMC) option. PMC is a primary tool in support of step 2, 3, and 4 above. In a paper presented at the June 2009 ISPA conference, Optimized Project Management of Systems and Software Projects we discussed the concepts of developing an estimate using a parametric model such as SEER SEM so that the project has a confidence based project plan that can be. We demonstrated the use of the PMC option to SEER SEM as a tool to analyze project metrics indicating performance against project plan. PMC is a key tool for the Key Process Area Quantitive Project Management (QPM) providing a method to support statistically controlling the project by using the process metrics to analyze and predict future project performance as a function of past project performance. When the predicted performance is not within an acceptable tolerance, process modifications should be made.

At that point we then use SEER-SEM to provide a quantitative assessment of the process alternatives possible to improve project performance. We have used the SEER-SEM tool in that mode for more than 5 years in support of a major DoD program providing on going assessment of project performance and recommendations of best process improvements from among the alternatives considered.

Applying a parametric model, reflecting the organizations processes, you can develop an executable project plan to a defined confidence level  Continued use of the SEER parametric model’s PMC capability will provide a basis for an Organizational Process Performance (OPP) analysis process and the Quantitative Project Management QPM) approach to provide the statistical control of the project.

Related posts:

1. Manufacturing Revolution, Product Development, And Cost Analysis Jim Ryan of Computer Aid pointed out, during the SEER...
2. Peaceful Coexistence of Agile Development and CMMI In the SEI paper “CMMI or Agile: Why Not Embrace...
3. Many Observed Incorrect Implementations of CMMI High Maturity At the CMMI conference a number of difficulties with high...

Brooks Law is that there is an incremental person, when added to a software project, that makes it require more, not less time. And adding people to a late software project makes it later.

 I have been spouting Brooks Law for over 20 years for software projects.  You know the drill.  An important project is late.  So the first inclination is to add more people, or put in a red team, or something to speed it up.  Unfortunately when Brooks Law comes into play, those additional people make the project fall further behind.  What happens is that for each additional person, there is some energy lost as they need to communicate with others.  At some point the project has all the people it can handle.  And adding people makes the project later. Even if the project could absorb more people, the reduction in productivity as the in-place team has to communicate with the  additional staff on the late project causes the late project to get later.

Using this information we can determine where Brooks Law might kick in at any point in the project and can compute the minimum time – the point at which people have been added at the maximum rate that is still productive, and hence a minimum staffing time and numbers of staff.  We can also determine the inefficiencies of overstaffing and the schedule penalty / cost improvement from using an optimal effort schedule as well. This is one of the core models within SEER for Software (SEER-SEM).

Although I have generally discussed this phenomenon in software projects, the same applies to hardware, IT or other engineering projects.  And even on assembly projects.

I recall working at a cannery one evening.  This was a facility that canned food for the needy.  We had a great turnout, probably over a hundred people anxious to help.  As the peaches came down the conveyor belt, the main job was to cut off any bad parts.  Each person, wanting to help, picked up all the peaches they could and cut something off.  I am sure the net pounds of peaches canned was well below what it would have been with the right number of people on the line.

And hardware development projects have nearly the same issues as software projects.  Add too many people too early and there will be wasted energy.  The project can take longer.

The opposite is also true, to a point.  Assuming a project is planned with a longer schedule and fewer people from the start: Fewer people on a project can extend the schedule but fewer communication paths cause the total effort to be less.

The basic issue of Brooks Law can be expressed in the equation:

n(n − 1) / 2

This equation computes how many different  communication paths exist between team members. Thus the larger the team, the more time people spend communicating rather than making progress.  So adding people to a project that is already late increases those communication paths and takes more of the time of those who should be making progress.

Figure 2 illustrates that there is a minimum time for any software project to be completed (it can be shipped sooner but to be really ready to ship this minimum time comes into play.)  Additionally, some cost maybe saved by a planned longer schedule (but not many projects in the US are willing to wait longer… In general, Europe is much more appreciative of the lower cost opportunities.) up to the optimal effort point where the cost begins to rise again.

PS: Use caution when some claim Brooks law is no longer valid. Proper application of Brooks law should look at individual teams working on individual programs, not an entire large system all at once.

References:

Excellent Knol on Brooks law.

“The Mythical Man Month” is a classic in software engineering, written by Frederick Brooks and describes Brooks Law in detail.

Wikipedia, The Mythical Man Month

Software Sizing, Estimation and Risk Management: when Performance Is Measured Performance Improves“  by D. Galorath and M. Evans.

Related posts:

1. MIT Interns Bust Brooks Law? Interesting article on slash dot discussing how a startup hired...
2. Software Staff Size Still Impacts Productivity: Brooks Law Lives! When drawing conclusions from data it is important to analyse...
3. Eating the IT Elephant: Moving From Greenfield to Brownfield Development The book “Eating the IT Elephant“ discusses the issues of moving...

I recently saw a presentation by Bernie Fox of Rand regarding guidelines and metrics for assessing space system cost estimates.  Very interesting presentation (if you are interested in space systems)

The paper includes:

•  Average costs and ranges for space vehicles, subsystems, and components for crosschecks.. Powerful
• Common issues in estimating the cost of space programs
• A space system specific portions of Military Handbook 881b (MIL-HDBK-881b)
• The National Reconnaissance Office WBS for more detailed breakdowns
• Cost / Risk Analysis

If you are involved in space systems you should look at this document

Related posts:

1. Standard WBS For Space System Cost Estimating The NRO cost group provided a Work Breakdown Structure (WBS)...
2. Lessons Learned On Major Engineering Program: Viable Cost Estimates Needed Recently one of our analysts attended a “lessons learned” presentation...
3. New SEER Labor Rate Calculator: A Leap Forward in “Should Cost” & “Will Cost” I saw a demo today of our new labor rate...

Follow this link to see some of the estimating united papers.� it was a great conference, full of useful information. Talks encompassing cost estimating (cost estimation), value engineering, product design, software, and more.

And thanks again to all the speakers and attendees as well as the hospitality of the Manchester United Football (soccer) club. And the Galorath staff whose diligent efforts made this a great success. Presentations will be available for all to download for the next few months, then will be available as part of the Galorath corporate library.

Galorath Conducts 5th Worldwide Conference on Project Estimation: Estimating United

On March 19th, 2009, Galorath conducted its 5th annual worldwide conference on project estimating. The conference title, Estimating United, was fitting both for its venue and content. The venue was Old Trafford, Manchester, United Kingdom, home of the world famous Manchester United Football Team. The content included presentations in two tracks from a variety of world class company participants, all united in their efforts to improve project estimation practices. Presentations covered a variety of topics in the area of project estimation, planning and control.

In recognition of their contributions to project estimation, two awards were presented at this year’s conference — one to Charles Symonds for his outstanding work and contributions in the field of software estimation and the second to Alan Jones of BAE Systems for his continued efforts to provide both a platform of knowledge for less experienced cost engineers and for his dedication to the Association of Cost Engineers activities to bring to our profession a “tiered approach to accreditation.” They join past recipients of this award which include Raj Roy, Cranfield University; David Reuss, Rolls Royce; and John Henson, AgustaWestland.

The 2nd SEER conference of the 2009 series will be held in El Segundo, CA on October 8th and 9th, 2009.

Presentations

Life Cycle Costing Capability in an International Organisation for Armament Cooperation

OCCAR-EA is an International organisation with full legal personality since 2001. It was created to co-ordinate, control and implement co-operative armament programmes that are assigned to it by the Member States. Today OCCAR is managing 7 Programmes with a total portfolio of 44 billions Euros. OCCAR is clearly tasked from its Convention to identify Cost Effective options to the nations both during Development and Production and for the In Service Phase of a Programme.  In this frame, OCCAR-EA has developed a Life Cycle Costing capability within the general approach of Through Life Management.  This allows the identification of common and cost effective solutions and informs the decision makers on these opportunities. The presentation will show the steps followed to set up this capability and will point out the specifics linked to an international Agency, a snapshot of the process in place, and the types of studies that have been performed.

Chairman’s Welcome and Opening Remarks

Carl Dalton introduces the day’s events, runs through the timings and housekeeping and introduces the Galorath team and the presenters.

The Value of Cost Estimating for Cost Management

Costs are determined in the very early stages of the Product Creation Process. Not using this fact, but only to focus on ‘solving technical puzzles’ or stressing Time-to-Market is a missed opportunity that in the end makes the business less competitive. In many companies Cost estimation can be a very valuable tool for purchasing in determining the “should cost” if only used in this way however cost estimation becomes a “purchasing tool” only.Changing to Target Costing means: Define the Customer Value before development starts, and derive the Target Cost from this. Then start studies to address the economic feasibility of new products, using cost estimation and cost driver analysis. This way cost estimation becomes a strategic decision support tool with less need to repair costs later on.Goof will address the following during his presentation:

• How we used to address costs (not)
• Change to Target Costing
• Role of Cost Estimation for target costing
• Some Examples of Cost Reduction achievements using Cost Estimation

Procurement Costs – Transparency and Assurance

Procured Equipment, Material and Services represents over two thirds of the initial cost of a military air platform and the resulting through life support activity. In the current climate of partnering and price transparency linked to a business environment increasingly focussed on ethical conduct, commercial parametric estimating models can provide confidence for both supplier and customer through open cost modelling based on industry standards of performance.This presentation will outline the current activity at BAE Systems – Military Air Solutions aimed at achieving these goals.

Understanding the Mysteries of MOD Support Costs

The costs incurred during the service life of equipment are a significant proportion of the whole life cost. However, these costs are not well understood and there are inconsistencies within the MOD as to how these are collected, collated and used. These costs are also used within the analysis at Dstl to inform high level Balance of Investment (BOI) decisions and it is therefore imperative that these costs are included as accurately as possible. The Support Costs study, funded by Director Equipment Plans (DEP), was commissioned to address this problem.The presentation will cover how the project team tackled the problem and explore some of the conclusions from the work.

Embedding Galorath’s Estimating Tools into a Project & Programme Management Suite

In this presentation we will show how the Galorath estimating tools have been integrated into Ninth Wave’s Project & Programme Management (PPM) suite.In most PPM products estimates for projects are entered manually and there is no audit trail provided for senior managers to see how the estimate was derived. Ninth Wave has enhanced its PPM suite to be able to generate an estimate automatically into a project by using the Galorath products in a “black box” fashion.The key benefits of this integrated approach are:

• estimating best practice is embedded into project management across the organisation
• drill-down capability to understand key inputs and drivers for an estimate
• ability to model different scenarios with just a couple of mouse clicks
• audit trail provided for all steps associated with generating an estimate

Software Sizing – the weakest link of estimating?

Charles Symons presents data on the performance of the software industry which in certain respects is dreadful. Evidence will be shown suggesting that this poor performance is at least partly due to weaknesses in performance measurements and in estimating. By “estimating”, we mean:

• initial estimation of the product size,
• methods for estimating project effort and duration from the initial size,
• processes by which estimating is integrated with project management,

where the first of these elements is the weakest link (though the third is also often weak).

The talk will then trace the development of methods of sizing software from using SLOC, to Albrecht’s idea of sizing functionality (now the IFPUG method), to the COSMIC method. Charles will briefly compare these methods and show how the COSMIC method overcomes weaknesses of earlier approaches.

What’s New and “Dan Galorath on Estimating”

What’s new and what’s coming in SEER will be featured.Additionally Dan will discuss selections from his blog. Dan will discuss selections from metrics, effectiveness measurement, the real costs of a variety of undertakings, what is ITIL versus ISO 9000, the risk of IT projects, what the assets of failed banks really are worth, and lots more. He weighs in on a wealth of topics both timeless and contemporary.

Computer-aided Business Case Assessment in Engineering Design Education

In all engineering initiatives the only acceptable basis for launching a product development programme is one in which low risk and high return-on-investment in the shortest possible timeline is secured. Up to 80% of the life-cycle cost of most high valued-added engineered products is incurred during the conceptual design phase, and, by the time completion of the design and development stage occurs 95% of the product cost is fixed and most of the development cost is spent. The University of Bristol, Department of Aerospace Engineering, and, the Department of Engineering Mathematics via its Engineering Design degree programme offer many examples of group project orientated education for undergraduates. The major student group projects for academic year 2008/09 include: (1) Airbus UK project “250-passenger Transport Aircraft Optimised for Multi-stop, Long-range Operations; (2) Arup project “Elevated Transport and Entertainment Ride System”; (3) Motorola project “Water Powered Pico Generator for a Mobile Phone Base Station”; (4) Hewlett-Packard project “Personal Carbon Footprint System”; (5) GE Aviation project “Automation of Pitch Control of a Propeller Engine; and, (6) Babcock project “Design Optimisation of a Nuclear Flask ‘Grab’ System”. A review of business case results from the aforementioned student group project work using the Galorath SEER-H cost estimation software will be presented.

Decisions, (Multi-Criterion, Subjective, unbounded), Decisions

The primary objective of this paper is to introduce two alternative methods, Absolute and Empirical Referencing, used to minimize the subjectivity surrounding some of the more crucial processes associated with project management and analysis. The Estimate by Comparison solution developed by Galorath Incorporated will be used as the vehicle to illustrate comparative sizing for the purposes of Parametric Estimation along with a few other more contemporary applications.

Estimation in ERP Environments

• Organisations have ambitious plans when purchasing ERP
• More than 75% believe in quick wins and grand return of investment
• In practice one will go a long way of learning
• 30% – 70% cost reduction is possible
• Therefore one needs a strong strategy in standardisation, developing
• Kknowing the pitfalls and monitoring the principal cost drivers are essential
• Benchmarking and estimating the projects and their environments will bring success
• Example insurance company:
  • Starting up with conventional planning and estimating
  • Gathering facts and figures
  • Switching to ERP environment planning
  • Building up company specific planning data
  • Creating private knowledge base

The 12 Sins of Estimation

Sin is a term used mainly in a religious context to describe an act that violates a moral code of conduct or the state of having committed such a violation. In monotheistic religions, the code of conduct is determined by God. Colloquially, any thought, word, or act considered immoral, harmful, or alternative might be termed “sinful”. Knowingly, and unknowingly, we as estimation experts commit sins in the area of Estimation, leading to harmful effects on the project management, tracking and control. With the premise that not doing wrong things is a way to do the right, the presentation highlights the common sins committed by experts in the field of estimation.Taking into account the current practical realities of business, the presentation explains how we can improve the process of estimation, and how to gather the critical mass required to make change happen in an organization.

Related posts:

1. Marvelous User Conference: Estimating United at Manchester United We had a marvelous users conference at the Manchester United...
2. SEER Estimating United Conference At Manchester United Stadium, UK I had the opportunity to review the agenda for the SEER...
3. Estimating Best Practices The following are the bullet points from Dan’s paper on...