We are excited to announce a new addition to the services Galorath has to offer.  Dan Galorath (CEO and President of Galorath Incorporated) and Don Reifer (President of Reifer Consultants) have combined their collective seventy years of software development experience to offer:

Independent Risk Assessments

Risk Assessment Teams provide expert-level independent assessment services to determine root-causes of problems and recovery when faced with adversity at the enterprise, program or project level.  Dan Galorath and Don Reifer , along with the rest of the Galorath senior staff bring their extensive experience in a wide range of technical, management and costing specialties to remove subjectivity by using numbers in order to justify the needed change.  This proven methodology uncovers both risks and remedies using a variety of approaches to yield results in even the most troubled organizations and projects.

The Galorath/Reifer Risk Assessment independently determines risk in a structured and systematic manner.  Using purpose built checklists, they interact with the stakeholders to gather the facts to reveal the true issues, not the perceived issues.  Subsequent root cause analysis uses available metrics and performance data to isolate and quantify the issues from which they develop a custom action plan to fix the causes of the problem, not the symptoms.  Using this approach, they have been able steer troubled organizations and projects back on track.  Results from the Independent Risk Assessments have yielded millions in award fees, contract renewals and extensions.

Areas of Expertise

• Enterprise Management
• Systems Engineering and Architecture
• Hardware and Software Engineering
• Independent Cost and Schedule Estimation
• Metrics and Measurement
• Root Cause Discovery and Analysis

Related posts:

1. Galorath / DCG IT Estimation For Business Value and Project Success Clinic Here are the slides from the Galorath / David Consulting...
2. Capers Jones, Gary Gack, Leon Kappleman, Dan Galorath Team Up To Improve IT From the consortium web site: Information Systems Risk Management Consortium...
3. Information Systems Risk Management Consortium: Capers Jones, Gary Gack, Leon Kappelman, Dan Galorath The consortium is the result of four of the industry’s...

I had the pleasure of meeting and working with Bob Lewis of Infoworld and CIO magazines recently.  In looking through his many excellent blogs I noticed this one today. It sumarizes a viable metrics program very well and is compatible with the goal, question, metric approach.  He calls it the 6 C's of effective metrics:

1. "Connected to Organizational Goals: Good metrics are connected to important goals. In fact, they begin as important goals, stated in English.
2. Consistent: Consistent metrics always go in one direction when the situation improves and the other direction when it deteriorates. If good doesn't always point in one direction and bad in the other, your metric will drive organizational dysfunction.
3. Calibrated: Calibration means you get the same value in the same situation no matter who records it. It also means the data are free from sample bias and other quality problems.
4. Complete: Anything you don't measure you don't get, so any useful system of measures must include all factors that are important to achieving the goal.
5. Communicated: The purpose of metrics is to drive behavior. If you don't communicate their purpose, they won't drive behavior.
6. Current: Goals change. Keep the old measures and you'll achieve your old goals, not your new ones."

 

Related posts:

1. 2 Kinds Of Metrics: Status & Trend and Effectiveness First the obvious: : Status / Trend Metrics: e.g. productivity,...
2. Forrester’s Five Essential Metrics for Managing IT A recent report by Craig Symons of Forrester identified 5...
3. Metrics and Estimation ROI I was speaking with Ton Dekker and others from Galorath...

The following is a summary by Galorath’s Chris Hutchings of the briefing  on January 6, 2012 by Mr. Frank Kendall (Undersecretary of Defense for Acquisition, Technology, and Logistics) regarding the Strategic Guidance given by the President, the Chairman of the Joint Chiefs of Staff (Gen. Dempsey) and the Defense Secretary (Mr. Panetta).

• While the specifics on how the defense strategic guidance will affect the Pentagon’s budget are not yet known, it is intended that there will be a reduction in the region of $487 billion over the next ten years
• The US will continue to meet its global responsibilities, albeit in manner more aligned to the current and emergent requirements and constrained budgets. Specifically, non-priority capabilities including ‘protracted, large scale operations’ will be reduced while investments will be made in technologies that provide ‘an agile and decisive edge against all threats,’ including Cyber Warfare and Intelligence, Surveillance and Reconnaissance.
• Technology supremacy is seen as an integral part of a progressive strategy and, as such, those within the industrial base that develop and support such technology are central to the success of the strategy
• A significant emphasis was placed on a requirement for continued operational readiness of a smaller, leaner force that is easily regenerated and mobilized to meet the following primary aims –
  • Strategic deterrence
  • Defeat threats from terrorist organizations, including al Qaeda. He highlighted the use of Special Forces in this area.
  • To react and defeat an immediate aggressor, while being able to ‘effectively inhibit the activities’ of a second aggressor
  • In line with the ‘better buying’ initiatives of Deputy Secretary of Defense (Carter), the strategy will include mechanisms to incentivize industry to become more efficient
  • Attention was drawn to two areas of specific risk to the success of the strategy, namely –
    • Industry must be, and act as, a part of the solution to the challenges that the Pentagon faces
    • Sequestration, a real threat to the aims of the strategy

Related posts:

1. Defense Acquisition Guidebook From DAU The Defense Acquisition University has released an update to its...
2. A Business Imperative for Change From the Taskforce on Defense Acquisition Law and Oversight This document analyses Government Acquisition Reform and was developed by...
3. Ash Carter Memo re: Efficiency & Productivity in Defense Spending — “Should Cost” vs. “Will Cost” The Ash Carter memo dictating 23 principal actions, “Implementation Directive...

I am working on a paper for NASA’s project manager conference.  In the course of this work I again reviewed the interesting work performed by Dr. Joe Hamaker while he was head of cost for NASA in establishing cost uncertainty before parametric models like SEER were used, and again after the system had been more finely modeled.

Like TRLs, CRLs are designed to communicate the quality of the product—its fitness for use. CRLs have been constructed to run the same 1 to 9 ordinal scale as TRLs, except we pay little attention to cost estimates at CRL 1-3.  In the case of CRLs, it is the quality of the cost product itself—the estimate’s fitness for use –that we are measuring

Joe equated cost readiness levels to technology readiness levels (TRL) to cost readiness levels and came up with the following:

Cost Readiness levels (CRL)

CRL 1, 2, 3: Not ready

CRL 4: Cost fit for very preliminary engineering decisions and very preliminary budget use (+/- 45%)

CRL 5: Cost fit for preliminary engineering decisions and preliminary budget use (+/-35%)

CRL 6: Cost fit for PDR engineering decisions and PDR budget use (+/- 25%)

CLR 7: Cost fit for firm engineering decisions and firm budget constraints (+/-15%)

CLR 8: Cost fit for very firm engineerin decisions and very firm budget commitments (+/-5%)

CLR 9:  Actual cost of completed project

Technology Readiness Level Definition

The goal of technology readiness level is to categorize hardware, software, or system concepts as to their maturity.  The following are definitions for TRL.  TRL 1 is barely a gleam in the engineering eye while TRL 9 is proven, operational technology.  The folllowing are definitions from NASA.

TRL 1 Basic principles observed and reported: Transition from scientific research to applied
research. Essential characteristics and behaviors of systems and architectures. Descriptive tools
are mathematical formulations or algorithms.
TRL 2 Technology concept and/or application formulated: Applied research. Theory and
scientific principles are focused on specific application area to define the concept. Characteristics
of the application are described. Analytical tools are developed for simulation or analysis of the
application.
TRL 3 Analytical and experimental critical function and/or characteristic proof-of-concept:
Proof of concept validation. Active Research and Development (R&D) is initiated with
analytical and laboratory studies. Demonstration of technical feasibility using breadboard or
brassboard implementations that are exercised with representative data.

TRL 4 Component/subsystem validation in laboratory environment: Standalone prototyping
implementation and test. Integration of technology elements. Experiments with full-scale
problems or data sets.

TRL 5 System/subsystem/component validation in relevant environment: Thorough testing
of prototyping in representative environment. Basic technology elements integrated with
reasonably realistic supporting elements. Prototyping implementations conform to target
environment and interfaces.

TRL 6 System/subsystem model or prototyping demonstration in a relevant end-to-end
environment (ground or space): Prototyping implementations on full-scale realistic problems.
Partially integrated with existing systems. Limited documentation available. Engineering
feasibility fully demonstrated in actual system application.

TRL 7 System prototyping demonstration in an operational environment
(ground or space): System prototyping demonstration in operational environment. System is at
or near scale of the operational system, with most functions available for demonstration and test.
Well integrated with collateral and ancillary systems. Limited documentation available.

TRL 8 Actual system completed and “mission qualified” through test and demonstration in
an operational environment (ground or space): End of system development. Fully integrated
with operational hardware and software systems. Most user documentation, training
documentation, and maintenance documentation completed. All functionality tested in simulated
and operational scenarios. Verification and Validation (V&V) completed.

TRL 9 Actual system “mission proven” through successful mission operations (ground or
space): Fully integrated with operational hardware/software systems. Actual system has been
thoroughly demonstrated and tested in its operational environment. All documentation
completed. Successful operational experience. Sustaining engineering support in place.

Part 2 of the CRL blog will be published soon.

Related posts:

1. CECIM: A Capability Improvement Model For Cost Engineering Being a major fan of repeatable process for cost and...
2. Oh Glorious Day.. Weapons System Decisions To Be Made Based On Total Life Cycle Costs The October 13 2008 issue of Federal Times has a...
3. NPD 1000.5 NASA Cost-Risk Directive Just about hot off the presses (January 2009) is NASA’s...

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

Galorath’s Ton Dekker presented this paper covering SEI’s CMMI and how SEER supports the processes for estimation and planning, monitoring and control, and how to make estimation part of the CMMI success criteria.

• Estimation & Planning
• Monitoring & Control
• Measurement & Analysis
• Quantitative Project Management
• Risk Management

Related posts:

1. Many Observed Incorrect Implementations of CMMI High Maturity At the CMMI conference a number of difficulties with high...
2. Dan’s 2 Papers At CMMI Conference In Denver Nov 18 & 19 Dan will be giving two papers at the CMMI conference...
3. Peaceful Coexistence of Agile Development and CMMI In the SEI paper “CMMI or Agile: Why Not Embrace...

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

ITMPI produces valuable content covering software and IT.  They have just released a series of articles on setting up and managing a project office.

According to Wikipedia: The Project Management Office (PMO) in a business or professional enterprise is the department or group that:

• Defines and maintains the standards of process, generally related to project management, within the organization
• Strives to standardize and introduce economies of repetition in the execution of projects
• Is the source of documentation, guidance and metrics on the practice of project management and execution

Sam Schroeder, PMP, outlines experiences with implementating and managing a project office.

Kathy Hood describes setting up a project office from scratch.

Mariya Breyter, PMP, experiences implementing a PMO at a global company

Related posts:

1. Forrester’s Five Essential Metrics for Managing IT A recent report by Craig Symons of Forrester identified 5...
2. DoD Affordability: Implementing Directive For Ash Carter Initiative A lot of people are interested in DoD’s initiative for...

People are the most important asset in an engineering environment.  SEER models the productivity of teams well.

And drilling down,  there is a way to look at individual productivity based on how “into” their job they are.  People that are disengaged have about 45% less individual productivity than those that are nominally engaged in the job.  Worse yet, only about 1 in 10 disengaged people can ever get the the engaged level.

It is possible to improve the level of engagement with some employees, some of the time.  We will be briefing more detail on this at our New York event this week and and plan on offering help in evaluating employee engagement as well as what can be done to improve engagement in the near future.

Related posts:

1. Software Staff Size Still Impacts Productivity: Brooks Law Lives! When drawing conclusions from data it is important to analyse...
2. List of Documents On Software Productivity This is a work in process list of documents covering...
3. Using the SEER Effective Technology for Productivity Assessment and Benchmarking While I prefer to use productivity (which consolidates everything about the...