Frank Vogelezang Pricing Vs Costing & Proof That IT Systems Can Be Estimated
Frank Vogelezang of Ordina‘s presentation at the Galorath conference in the Netherlands yielded numerous interesting and well prepared presentations by customers and partners. The presentation included here: Estimating & Pricing of Application Management covered the processes for estimating what the problem will cost and the separate processes for pricing what will be charged to the customer.
Estimation Vs Pricing
Estimation was described as an engineering discipline while pricing was described as a commercial discipline that leads to a structure optimized to win the deal with an offering that meets customer acceptance criteria.
SEER Validation of the COMPLETE SYSTEM
The part I found even more interesting was the SEER validation included within the paper. This validation compared the IT total system cost, including software development estimated by SEER-SEM, IT infrastructure (hardware, bandwidth, etc.) and IT services estimated by SEER-IT, and other (pass through) items estimated via manual processes. The results were good even before any calibration, and even better after they calibrated with some of their history.
One Size Fits All Models Versus SEER
Frank pointed out the risks of using simple cost estimating relationships for estimating and defined the reasons why they choose SEER including:
- The estimating model needs to have a breakdown structure that can accommodate different cost-drivers
- Requirements for a supporting tool: Ability to facilitate a breakdown with different cost-drivers Based on experience data
- Possibility of calibrating the data with own experience
- SEER for IT as the basis for the model Six types of knowledge bases (out of 12)
- SEER for Software for Application Development calculations
WBS In SEER IT Infrastructure, IT Services, Software Development
Results before calibration (at a 50%) probability were slightly higher than actuals. With calibration they were within a few percent. And again, this was the entire system estimate including software, hardware, services, and other costs.Be sure to check out Frank’s blog http://www.ThePriceofIT.blogspot.com for more insights from him on a variety of relevant topics.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Galorath / DCG IT Estimation For Business Value and Project Success Clinic
Here are the slides from the Galorath / David Consulting Group estimating clinic held in New York City. There were interesting discussions encompassing dealing with impossible demands, understanding risk and risk management, sizing, and a number of other topics. Note: The Galorath slides and the DCG slides are combined in the one PDF file.
Concepts of IT providing business value to the organization were also discussed in detail.
Thanks to all who attended and especially to Mike Harris and David Herren for their insights.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Computing the Value of Incomplete Software
IBM’s Murray Canter published an interesting article in the communications of the ACM covering calculating and improving the ROI in software systems. Murray shows how to compute the “investment value” of incomplete software and illustrates why it does have value showing how to compute the net present value and the return on investment of this in process work, using Monte Carlo simulation. Murray states two axioms:
- Costs and benefits occur over time, so their present values are found through NPV equations
- The future values of costs and benefits are random variables, described as a statistical distribution
I should note this requires a subscription to ACM digital content.
Its abstract states:
“Constrained by limited budgets, most enterprises find it essential to apply unprecedented business discipline to the business function of software and system delivery (SSD) across entire software and system life cycles. For this reason, the CIO, CTO, or VP of software or systems development may be under increased scrutiny from the corporate chief finance office (CFO). When conversing with the CFO, money talks, so only one of two sorts of conversations can take place: software and systems as cost center or software and systems as value-creation center.”
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Measurement and Providing Value to the Business ISMA Keynote 2011
Here is a copy of my keynote talk at the 2011 ISMA measurement conference, Measurement and Management and Business Value. The real point is the IT and measurement personnel have the information, knowledge and skill set to provide value to the business, far beyond the costs generate. But the information needs to be communicated in terms leaders can understand rather than the techie language we all think and speak in… AND if IT starts showing how it contributes to the business and becomes a profit center instead of a cost center IT will get more money to apply to more valuable things.
UPDATE: Someone also asked for a reference communicating the language of management. I believe this publication on business case analysis to be helpful in that regard.
PS In my talk I referred to software and measurement people as geeks. To many the term geek is a source of pride. One person in the talk was offended by being called a geek. My sincere apologies. However modern vernacular often defines a geek as a lover of technology, a software developer or someone with an intense love of mathematics. I consider myself a geek. And my friend Paul Glen makes his living by “leading geeks.”
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Establishing the ROI on Software Through Examination of Total Ownership Costs
I get so excited when an organization does a true business case and evaluates cost versus benefits of a software / IT system along with the risks. . Part of the key is thinking and analysing and communicating like a C llevel person rather than like a technical person. Here is a link to the PowerPoint I did a webinar on this topic during July 2011 Establishing the ROI on Software Through Examination of Total Ownership Costs. The full recorded webinar is available on the ITMPI site as well.
One might say that business case analysis is finance 101 and I would agree… Sometimes uncommon success is achieved by doing common things uncommonly well.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
Galorath Keynote ISPA March 2011
Today my conference presentation involved understanding and estimating value in software and IT systems as well as total ownership costs. It still amazes me how so many software and IT leaders do not want to think in terms of Return on Investment but just want to build things that seem to be good ideas. If we would build what has the most value IT could become a profit center. Key points were:
- Estimation is a key portion of business decision making
- Value must be considered in addition to cost
- Data doesn’t have to be perfect to be useful
- Estimators taking some responsibility for business value analysis can make a major improvement in business
I have included entire PowerPoint presentation here.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
$500 Billion IT Debt For Deferred Maintenance
Gartner Group has reported that the IT Debt is about $ 500 Billion, the cost of deferred maintenance with that number heading toward $1 Trillion over the next 5 years.
Gartner’s Andy Kyte defines IT Debt as “the cost of clearing the backlog of maintenance that would be required to bring the corporate applications portfolio to a fully supported current release state.”
In its most simple form IT Debt could mean upgrading software from Windows XP to Win 7. In enterprise IT Debt could involve upgrades in ERP, business intelligence software or middleware.
The maintenance backlog has built up as a result of tight tech budgets over the last decade, cost-cutting measures or simply because the enterprise did not feel compelled to upgrade its application portfolio.
“Over the last decade, CIOs have frequently seen IT budgets held tight or even reduced. The bulk of the budget cut has fallen disproportionately on maintenance activities — the upgrades that keep the application portfolio up-to-date and fully supported. There is little problem if this is done in one year or even in two years, but year after year of deferred maintenance means that the application portfolio risks would be getting dangerously out of date,” said Andy Kyte.
The Gartner analysts said IT leaders should produce an annual report on the status of the application portfolio detailing the portfolio status, including:
- Number of applications in use
- Number of applications acquired
- Number of applications decommissioned
- Current and projected costs of operating, sustaining or improving
Technical Debt From An Application Viewpoint
Cast Software, makers of a very interesting static analysis tool, define technical debt a bit differently.
Technical Debt in an application is the cost of fixing the problems in that application that put the business at serious risk. Technical Debt includes only those problems that are highly likely to cause severe business disruption; it does not include all problems, just the most serious ones.
Based on this definition, they estimate that the Technical Debt of an average-sized application of 374,000 lines of code is $1,055,000.
Note: Technical debt chart from Ronald E. Jeffries
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
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 or call us at +1 310 414-3222.
Data Center Consolidation: Avoiding Surprises and Returning Business Value
We see many organizations, papers, vendors, etc. discussing data center consolidation. Wonderful projections and claims are being provided by vendors. But many Data Center Consolidation decisions are not being made on solid, objective cost analysis. Studies show that about 21% use consultants, and about 17% use ROI calculators from vendors. Hopefully these analyses provide accurate costs and savings.
But there is another way…
-
Repeatable, credible & risk oriented
-
Documented analysis using sound estimation process
-
Application of SEER-IT for cost, schedule, risk analysis
Galorath’s approach is to first model the as-is approach in a fully justified approach, then to estimate the to-be approach. Full risk analysis is performed as well, ensuring you understand the range of probabilities.
If you are interested in a viable estimate including cost, headcount, schedule, and risk of data center consolidation, contact Galorath. Everything from software assets to hardware assets, facility assets, and real estate assets are analyzed. People, power and other analyses are included. Additionally, the cost of shutting down the legacy must be included in a complete analysis. These could be substantial.
The following example shows nearly $100 million in savings over 7 years at a cost of $33 million.
To discuss this analysis or to get started on data center consolidation analysis, contact Galorath, worldwide.
Thank you for reading “Dan on Estimating”, if you would like more information about Galorath’s estimation models, please visit our contact page or call us at +1 310 414-3222.
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 or call us at +1 310 414-3222.
Project Prediction Infographic
