Cloud Matters Canadian Cloud Council…. Costs & Benefits of Cloud
I had the privilege of presenting at the Canadian Cloud Council conference in Banff Canada. It was exciting to see and hear all the wonderful things people are doing or planning to do with cloud computing.
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.
New SEER Labor Rate Calculator: A Leap Forward in “Should Cost” & “Will Cost”
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.
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.
Why We Estimate Schedule & Cost
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
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.
Embedded Designs Integration Cost Challenges
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%.
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.
Evaluating the Benefits of Service Oriented Architecture: SEER in support of SOA Implementation Decisions
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
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.
Estimating Best Practices
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
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.
Heuristics for Systems Engineering Cost Estimation
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.”
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.
Considerations for CMMI Level 4 for Systems/Software product development and deployment
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:
- Process unpredictable, poorly controlled and reactive
- Process characterized for projects and is often reactive
- Process characterized for the organization.
- Process measured and statistically controlled
- 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:
- Set the organizational Process Performance goals and establish a Quantitative Project Management methods to ensure processes are measured and statistically controlled.
- 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
- You need a valid estimating process that provides a confidence based project plan
- You need to measure cost and schedule at team task level
- Predict future project performance (actual estimate based on past performance not a belief that the project performance will improve with no external action)
- Take optimal corrective actions early
- 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.
- Use a predictive model such as a Performance Based Earned Value Model to predict the project future performance
- 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.
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.
Brooks Law Is Applicable To Many Collaborative People Activities
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.
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.
Guidelines and Metrics for Assessing Space System Cost Estimates
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 Read more
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.
Project Prediction Infographic
