Here are each of the 10 reasons:

1 Scope creep: Often the result of not having a clearly defined scope and/or not tracking and declaring changes to scope.

2 Poor input to estimate: This refers to poor quality requirements or objectives, leaving the estimate open to risk and scope variation. The estimate is “built on sand” but the estimator does not factor for this or clearly express the uncertainty as a 3-point estimate.

3 Failure to clearly define the initial scope: Items may be missed out or there may be a failure to declare assumptions. This will make the project vulnerable to scope creep or conflict later in the project as all parties argue over what is in scope and what is out of scope.

4 Unrealistic expectations and assumptions: Optimistic assumptions that it will go right this time. Claiming benefit from improvements before they have been demonstrated. Overruling the estimate.

5 Failure to declare, track and reduce risk and uncertainties. The project may then be vulnerable to unnecessary risk.

6 Lack of internal peer review: Failing to benefit from peers‟ experience. A review is a simple and cost effective way to improve estimate “Quality”

7 Lack of estimation experience: Estimates generated by a person who may not have experience in estimating or in the subject being estimated.

8 Failure to consider environmental factors: Undeclared and untracked elements of the environment can change – having unexpected and “dramatic” effects for examples, loss of key individuals, change of supplier, a more complex organisation, etc.

9 Failure in the estimation tool/process: The tool or process may be unable to deliver the desired accuracy. It is essential to measure and declare the estimate tolerance of any tools used.

10 Lack of estimation process/technique: Failing to apply a systematic estimation tool, method or processes. Without this, it is hard to defend the estimate.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.

The post Reasons For Estimation Failure appeared first on Project Planning & Estimation.

Recent batches of Apple rumors state that IOS 7, the new iPhone / iPad operating system is late and Apple may have to ship the newest hardware devices without IOS 7.  Apple’s solution…. Take staff off the Macintosh operating system development and put them on IOS 7. 

 Basic software productivity laws (see law 3 below) state that adding people to a late project makes it later.  This was first observed by Frederick Brooks and documented in his book “The Mythical Man month.” And taking people without domain knowledge just makes things worse.

 Now there is some chance this might help.  so long as their staff doesn’t increase to the point of Brooks Law comes into play. Additionally, absorbing people into the IOS project from outside will cause the IOS core team to slow down as entropy kicks in.  We have developed a set of productivity laws that cover these phenomena.  Some are based on Brooks Law while others are of our own discovery.

Software Productivity Laws:

LAW 1 – Smaller teams are more efficient: The smaller the team the higher the productivity of each individual person.

LAW 2 – SOME schedule compression can be bought: Adding people to a project, to a point, decreases the time and increases the cost.

LAW 3 – Every project has a minimum time: There is an incremental person that consumes more energy than he/she produces. Team size beyond this point decreases productivity and increases time. (aka Brooks’ Law–”Adding staff to a late software project makes it later.”)

LAW 4 – Productivity is scalable: Projects of larger software size can use larger teams without violating LAW 3.

LAW 5 – Complexity limits staffing: As complexity increases, the number of people that can effectively work on the project and the rate at which they can be added decreases.

LAW 6 – Staffing can be optimized: There exists an optimal staffing function (shape) that is effectively modeled by the Rayleigh function. Flat (level load) staffing is rarely optimal.

LAW 7 – Projects that get behind, stay behind: It is extremely difficult to bring a project that is behind schedule back on plan.

LAW 8 – Work expands to fill the available volume: It is possible to allow too much time to complete a project (aka Parkinson’s Law).

LAW 9 – Better technology yields higher productivity: More capable teams, better tools, and advanced, stable processes yield higher productivity.

LAW 10 – No “silver bullets”: There is no methodology, tool, or process improvement strategy out there that yields revolutionary improvements in project efficiency.

So what should Apple do?  Without visibility I cannot tell for sure.  But they should ensure they don’t fall into the Productivity trap.

Some of the general tips include:

1. Get the best from well-managed people…people can drive productivity 10 to 1
2. Make development process more effective (probably not practical at this point in the game)
3. Eliminate rework
4. Reuse proven products, processes, and production settings
5. Measure productivity…But be aware of the Hawthorne effect
6. Staff aggressively but not so aggressively that Brooks law comes into play.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.

The post Apple IOS 7: Adding People To a Late Project Makes It Later appeared first on Project Planning & Estimation.

1. Technical Debt Due To Lack of Analysis: Analyze and fully understand the process you need to computerize.
2. Technical Debt Due To Lack of best Practices: Write code so that it is perfectly consistent with the best practices of the various technologies used.
3. Technical Debt Due to Lack of Rework Integration: Change existing code so that it’s seamlessly integrated with the newly created code. This also requires a perfect understanding of the existing code.
4. Technical Debt Due To Lack of A Test Suite: All the time and resources necessary to create a suite of automatic and integration tests for testing the various features of the written code one by one.
5. Technical Debt Due To Lack of Technical Documentation: All the time and resources necessary to write the technical support documentation for future changes.

And of course I must add:

6. Technical Debt Due to Resource Constraints: Too few or too many people on the project causing issues as well as inadequate schedules.

7. Technical Debt Due To Poor Planning: Either lack of planning or not re-planning when things change.
8. Technical Debt Due To People Being Human:  People are still human so there will be mistakes that don’t get caught.  That is just life with software.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.

The post Elminating Technical Debt: Easy? appeared first on Project Planning & Estimation.

PMI’s PMBOK states “cost estimates should be reviewed and refined during the course of the project to reflect additional detail as it becomes available and assumptions are tested.  The accuracy of a project estimate will increase as the project progresses through the project life cycle.  For example a project in the initiation phase may have a rough order of magnitude (ROM) estimate in the range of -25% to +75%.  Later in the project, as more information is known, definitive estimates could narrow the range of accuracy to -5% to +10%.  In some organizations, there are guidelines for when such refinements can be made and the degree fo confidence or accuracy that is expected”  In other words PMI remains silent on standard estimation points.

So.. Here is a proposed set of standard estimation points.  These gates are often tied to how an organization funds money for projects.  So they need to be tailored to the governance approaches being used:

Concept Level Estimate

Just a finger in the wind to see if the idea is worth exploring or is so expensive as to be impractical.

Business Case Estimate

Estimate in the decision making phase when a project has not yet been authorized, often as part of the business case analysis.

Project Charter and Plan Estimate

Estimate that goes along with a project definition or project statement and estimates scope, objectives and participants in a project as well at the primary roles and responsibilities.

Detailed Plan & Function Spec Estimate

Project planning level where the project team prepares th estimate of how it will move forward.  In Agile projects this may be the overall project estimate rather than individual sprint estimates.

Construction / Deployment Estimate

An estimate to complete of a project that is underway to help keep the project on schedule and cost.

Post Deployment Estimate

This estimate provides information for estimators and others to used such as lessons learned, actual data for calibration, etc.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.

The post Standard Estimating Gates appeared first on Project Planning & Estimation.

This includes the 10 step affordability process as well as amplification of several process steps.

I go back and forth on combining steps 1 and 2… 1. Identifying Key Performance Parameters and 2. identifying figures of merit for affordability trade-offs but continue to keep the separate just to highlight the importance of knowing what the definition of success or failure are in step 1.  In a few instances I used our SEER for IT model to illustrated trades between on-premises and cloud solutions.  The is a quick and powerful way to determine affordability.

When I attended the recent cloud computing conference in Banff someone pointed out it is not cloud computing, but just computing… that we need not make the distinction so sharply but basically choose the computing approach that best fits the situation…   I agree.  Cloud is here to stay.  It is not just a fad.  And it can be extremely useful when appropriately applied.

One thing I didn’t point out in the briefing is some specific Galorath experience.  For example, we hosted our SEER server on the Amazon cloud. Generally users host on their own internal servers for security reasons but this seemed like a good alternative.   The process went well and we were happy…  until we started performance benchmarking.  We found the Amazon cloud IN THIS CASE performed an order of magnitude slower than VPN across half the world to corporate servers.  Again this is just a single case… We could have tuned the Amazon Cloud or purchased more capacity.  We will report performance improvements when we do.  There are a myriad of options on the Amazon cloud.  I hope we don’t just have to pick them by trail and error.   We had an enterprise database running on the cloud, along with the application.  Still, the good news.. We just need to move onto another cloud or beef up our Amazon cloud capability.  Participants at this conference identified several that are more designed for rapid transaction processing.  This is a whole lot better than the old days:  buy a server(s); find out they aren’t fast enough; iterate.  Long live the cloud ad affordability analysis.

PS the above graphic is a summary of a trade done between an on-premises and a cloud solution. While this shows a substantial cost reduction from the cloud THIS DOES NOT IMPLY ALL CLOUD SOLUTIONS ARE CHEAPER.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.

The post Making The Best Decisions in IT and Cloud: Affordability Processes Applied to Cloud Computing appeared first on Project Planning & Estimation.

My talk touched on the analysis of the business case for cloud computing and pointed out that sometimes cost savings are attributed to the cloud when they are really do to factors such as development environment.  The point was that each cloud development needs to estimate costs and business value and make the right decision for the business.

I have several more comprehensive briefings on cloud costing available if requested.  And have included the summary of Cloud costs, benefits and ROI.

My key points were:

• Use an estimation process to identify costs, schedule, risk and benefits
• Make decisions based on value to business
• Attribute costs and cost savings to their root causes rather than just lumping them all to “cloud”

It is exciting to see the evolution of cloud computing.. And sometimes disturbing when organizations cast their distributed applications as cloud applications just to get on the cloud bandwagon.

Banff…. Doesn’t get much more beautiful than this..

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.

The post Cloud Matters Canadian Cloud Council…. Costs & Benefits of Cloud appeared first on Project Planning & Estimation.

“While about 10 percent of developers cited no time savings in using cloud environments, an almost equal amount said they had experienced more than 30 percent time savings. About 38 percent cited savings in the 11 to 20 percent range.”

Obviously if we just take the same tools, practices and environment and put it in the cloud nothing magic happens… Perhaps response time is a bit slower. Looking at the impact of response time we see a potential 6% increase in schedule due to immediate response to a developer and an 18% increase in effort if every action has a terrible (3+ second) response:

So why should the cloud reduce development time?

1. Better environment (e.g. force.com)
2. Better development Tools (e.g force.com)
3. Mobile making more work hours in a day (development during off-hours)
4. Hawthorne Effect (People respond to being measured…or in this case estimate reductions because they hope there are some)

A Galorath study of salesforce.com’s force.com showed an over 40% decrease in development time.  But this was attributed to the availability of reusable components and the powerful development language, not the fact that it was cloud based.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.

The post Evidence of Cloud Development Saving Development Time appeared first on Project Planning & Estimation.

The goal of a Delphi is to come to consensus among various expert stakeholders (generally engineering personnel) as to an estimate.  Of course Delphi techniques can be used for other items as well.

Unfortunately, coming to consensus often yields compromises that blur risk and uncertainty.  Using SEER and Galorath estimation processes can make Delphi more powerful, more accurate, and more able to quantify risk and uncertainty by estimating key characteristics (SEER inputs) and their range.  Then using SEER to prepare the actual cost, schedule, risk, reliability estimate.

To summarize the Delphi process:

1. Choose a team representing every engineering group involved
2. Establish groundrules, assumptions, WBS and key drivers
3. Individual evaluation of WBS items, groundrules and assumptions, and key performance parameters
4. Group Estimation session for consensus. Iterative steps to gain consensus on key performance parameters (key SEER inputs) and the estimates. Then resolve differences with benchmarks and corporate history.
5. Review results. The project manager reviews the final task list with the estimation team.
6. Capture lessons learned

Delphi approaches are valuable for several reasons, the most important being the process step that defines groundrules and assumptions. Also being able to reconcile divergence in experts’ answers as real program risks are important.

Customers with critical programs can use the SEER inputs as the focus of the various Delphi approaches. And due to the ability to input a range, not just a single point, this approach allows the ability to capture and quantify uncertainty, factoring it into the estimate.

When the Delphi captures groundrules and assumptions and WBS together those may be created inside SEER. This provides both the basis for the next phase as well as ensures capturing those important items for future estimates and analysis. Usually in this case SEER is projected on a screen so all can view the work in progress. Then rather than just capture effort and schedule (which have been found to be more highly variant) for the WBS item(s) participants capture their beliefs of the key input parameters. This allows information to be saved and benchmarked as well as used for estimation. Thus the estimation process continues to improve.

Once the Delphi of the estimating inputs is completed experts can review both the likely effort and schedule as well as the risk and determine the criticality of the project and thus the probability required for the final estimate.

What-ifs can be performed to evaluate project alternatives or contingencies quickly and reliably.

Additionally, SEER’s Estimate By Comparison allows the ability to express size or any other SEER parameter in terms of both its relative weighting and to express uncertainty among experts. Estimate by Comparison is also used as a method of achieving agreement (of the range or the single point) by having the experts in the room together and eliciting agreement while viewing the choices together once the first passes are completed individually.

Finally, being able to see the estimate results, benchmark against industry and the organization itself complete the picture. The best thinking of the experts and comparison with reality.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.

The post The Value of Combining Delphi and SEER appeared first on Project Planning & Estimation.

The goal is “deliver better value to the taxpayer and Warfighter by improving the way the Department does business.”

1. Achieve Affordable Programs

• Mandate affordability as a requirement
• Institute a system of investment planning to derive affordability caps
• Enforce affordability caps

2. Control Costs Throughout the Product Lifecycle

• Implement “should cost” based management
• Eliminate redundancy within warfighter portfolios
• Institute a system to measure the cost performance of programs and institutions and to assess the effectiveness of acquisition policies
• Build stronger partnerships with the requirements community to control costs
• Increase the incorporation of defense exportability features in initial designs

3. Incentivize Productivity & Innovation in Industry and Government

• Align profitability more tightly with Department goals
• Employ appropriate contract types
• Increase use of Fixed Price Incentive contracts in Low Rate Initial Production
• Better define value in “best value” competitions
• When Lowest Price Technically Acceptable (LPTA) is used, define Technically Acceptable to ensure needed quality
• Institute a superior supplier incentive program
• Increase effective use of Performance-Based Logistics
• Reduce backlog of DCAA Audits without compromising effectiveness
• Expand programs to leverage industry’s IR&D

4. Eliminate Unproductive Processes and Bureaucracy

• Reduce frequency of OSD level reviews
• Re-emphasize AE, PEO and PM responsibility and accountability
• Eliminate requirements imposed on industry where costs outweigh benefits
• Reduce cycle times while ensuring sound investment decisions

5. Promote Effective Competition

• Emphasize competition strategies and creating and maintaining competitive environments
• Enforce open system architectures and effectively manage technical data rights
• Increase small business roles and opportunities
• Use the Technology Development phase for true risk reduction

6. Improve Tradecraft in Acquisition of Services

• Assign senior managers for acquisition of services
• Adopt uniform services market segmentation
• Improve requirements definition/prevent requirements creep
• Increase use of market research
• Increase small business participation
• Strengthen contract management outside the normal acquisition chain — installations, etc.
• Expand use of requirements review boards and tripwires

7. Improve the Professionalism of the Total Acquisition Workforce

• Establish higher standards for key leadership positions
• Establish stronger professional qualification requirements for all acquisition specialties
• Increase the recognition of excellence in acquisition management
• Continue to increase the cost consciousness of the acquisition workforce – change the culture

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.

The post Better Buying Power 2.0 Initiative: Better value to the warfighter and taxpayer appeared first on Project Planning & Estimation.

“formalized application of modeling to support system requirements, design, analysis, verification, and validation, beginning in the conceptual design phase and continuing throughout development and later life cycle phases”

• First, for software, Our work with Rational RSx was successful… That it: it extracts information from use case models, then uses that to run SEER for Software.  This functionality is available as a product today.
• Our uses system models from IBM Rhapsody to generate  costs for hardware intensive systems as well as other kinds of systems
• Our newest research, in concert with University of Arizona and University of South Australia, goes further in using system models to generate cost models.

The attached briefing Model Based Systems Engineering (MBSE) Cost Modeling  is a simple introductions to the research and some of the successes.  We will be exploring this more deeply and documenting some of our findings here.

Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page, call us at +1 310 414-3222 or click a button below to ask sales questions, sign up for our free library or schedule a demo.

The post Estimating Cost From Model Based Systems Engineering (MBSE) Models appeared first on Project Planning & Estimation.