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.

Related posts:

1. A Good Cost Estimate: The Foundation for the Art & Science of Pricing I thought this was an interesting article “A Good Cost...
2. The Total Ownership Cost of IT Systems It is interesting to see how the much of the...
3. Estimating Systems Engineering…. The Upcoming Book.. and SEER I had the opportunity to review Dr. Ricardo Valerdi’s (MIT)...

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.

Related posts:

1. Galorath / Reifer Team To Provide Large Project Success Via Risk Assessments We are excited to announce a new addition to the...
2. Another View of Project Success From Dr. Dobbs While the Standish Group’s surveys are the most widely known...
3. The Business Value Of IT Book I opened my copy of this book, The Business Value of...

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.”

Related posts:

1. Computing the Business Value of IT While I am a strong proponent of examining the business...
2. Software as a Service vs. Service Oriented Architecture vs. Cloud Computing I have seen a lot of confusion as to the...
3. The Cost of Cloud in the Sky Computing Part 1 Looking at ways to increase IT infrastructure without worrying about...

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.”

Related posts:

1. Galorath Keynote ISPA March 2011 Today my conference presentation involved understanding and estimating value in...
2. Issues in Software Measurement & Estimation ISMA 2010 Measurement is a wonderful thing.  However measurement without standards and...
3. Communicating with Management Via Measurement This is the abstract for my keynot talk at the...

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.

Related posts:

1. Government IT Project Woes and Estimating Total Ownership Costs A recent government report showed 81% of budget or $57...
2. Reducing Software Maintenance and Total Ownership Costs Over 75% of the costs of software are in software...
3. Software Measurement and Total Ownership Costs… Dan’s Presentation at the NYC SPIN I had the opportunity to present at the New York...

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.

Related posts:

1. Measurement and Providing Value to the Business ISMA Keynote 2011 Here is a copy of my keynote talk at the...
2. Galorath / DCG IT Estimation For Business Value and Project Success Clinic Here are the slides from the Galorath / David Consulting...
3. Dan Galorath Presentation at SEER / Tracer Seminar In Tysons Corner October 2009 It was exciting to participate in a seminar with Computer...

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

Related posts:

1. ScrumMaster and Techical Debt Technical debt can be reduced by ensuring “done” is a...
2. Estimating Software Maintenance SEER for Software, uses sophisticated software total ownership model modeling including...
3. Software Maintenance: Costly And Controllable It always amazes me when I hear someone say they...

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...

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.

Related posts:

1. Data Driven Estimating Part 1: How Data Feeds The Estimation Modeling Paradigm at Galorath / SEER Lee Fischman’s article on data driven estimating follows: Summary Galorath...
2. Software Estimating: Sources and Uses of Data and Data Driven Estimates Intro These days software estimation vendors are competing to have the...
3. The Business Value of IT In Tough Times I was looking at the Harvard Business Reviews book on...

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” ...