Capers Jones, Gary Gack, Leon Kappleman, Dan Galorath Team Up To Improve IT

January 20, 2010 · Filed Under General, Project Management · Comment 

From the consortium web site: 

Information Systems Risk Management Consortium Charter

Written on January 28, 2010 at 4:25 pm, by adminThe consortium is the result of four of the industry’s leaders (Capers Jones, Gary Gack, Leon Kappelman, Dan Galorath) deciding to pool our expertise and form a consortium called the Information Systems Risk Management Consortium for the purpose of offering our combined talents to assist the information systems industry.  The process improvement results we’ve achieved with other diversified government and industry organizations and large distributed companies has convinced us we can help you accelerate your strategic initiatives while improving tactical performance with measurable results within a 6 to 18 month calendar window.

 Our experiences can help your teams identify and reduce the potential risks earlier in the project life cycle.  In most cases the problems and failures are avoidable if you know what to look for, what to do about them, have repeatable processes, appropriate practices, and utilize independent expertise like ours both before and after contracts are awarded.  Federal Government organizations and world-class companies often lack the necessary in-house expertise to ensure success in these high-risk, complex, multi-year initiatives.  Independent specialists with world-class experience and capabilities can provide the critical differentiator needed to manage successfully large high-risk projects.

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 or call us at +1 310 414-3222.

Related Posts Computer Generated




Estimating the Costs and Benefits of Software Process Improvement

January 12, 2010 · Filed Under Project Management, Software Estimating · 1 Comment 

I recall, some years ago, participating on a source selection for an improved software development environment.  My part was essentially to assess the costs (personnel, time, etc.)  and the benefits (increases in productivity when the new software development was deployed.

Interesting work and right up SEER’s alley.  I looked at improved development tools and  development practices and cost reduction versus the costs and temporary reduced productivity.

Watts Humphrey of SEI published a document on costs and benefits of software process improvement that is worth review.



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.

Related Posts Computer Generated




A Business Imperative for Change From the Taskforce on Defense Acquisition Law and Oversight

January 7, 2010 · Filed Under Project Management, Thoughts, business value · Comment 

This document analyses Government Acquisition Reform and was developed by a business task force including a who’s who of American technology business and government.  It is very relevant to those concerned with DoD acquisition costs.  I have included a few quotes and conclusions here to give the reader a flavor of the document.

“I reject the notion that we have to waste billions of taxpayer dollars to keep this nation secure.” —Barack Obama

1. Requirements need to be iterative

2. Government needs to bring back highly experienced personnel  

“Higher costs, whether based on low estimates or poor enterprise management, is unacceptable and harmful to the defense enterprise.”

 

“While the shortcomings of defense acquisition are manifold, the issue that has drawn by far the greatest criticism to date is the high cost, and cost growth, of the products it produces. Simply stated, we are on an unsustainable cost trajectory.” —John Young, former USD (AT&L)

 Adherence to program execution processes aimed at satisfying the needs of the war fighter is essential: with resources to address contingencies, with proven technology, and viable poor estimates of production volumes.  Programs should be funded when:

 1. the requirement is clear (And requirements should be iterative);

2) funding is adequate, including reserves, is available

3) the technology is proven

 4) the system concept is well-defined

 

 

 



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.

Related Posts Computer Generated




Software Engineering Body of Knowledge from IEEE

December 28, 2009 · Filed Under Project Management · Comment 

The 2004  Software Engineering Body of Knowledge is available at no cost from: http://www.computer.org/portal/web/swebok/htmlformat  While it doesn’t focus on estimation, planning and control, it is a valuable resource for software engineers.  There will be an expanded 2010 version coming out as 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.




10 Biggest IT Development Money Wasters

June 15, 2009 · Filed Under CEO, Project Management, Thoughts · Comment 

From Justin James and Techrepublic: IT Development Moneywasters

#1: Communication problems

#2: Process issues

#3: Refusal to go live and iterate (aka: insistence upon perfection)

#4: Penny wise, pound foolish

#5: Outsourcing missteps

#6: “The Longest Yard” (documentation and user training)

#7: Developers used as support staff

#8: Poor foundation for development

#9: Fail to know the business

#10: Neglect to calculate project ROI



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.

Related Posts Computer Generated




Estimation Plus Process and Measurement Rigor Yields More Successful Projects: SEER and Tracer

It has been rewarding working with the Computer Aid  (CAI) people, the people who sponsor the ITMPI in tying together best practice approaches (SEER for Estimating, Planning and Control and Computer Aid’s Tracer for metrics, reporting and root level management).  I am always inspired when I hear the  CAI people explain their process and success in fixed price software development and maintenance.  They do it by a number of methods and processes.  But the one that always makes me the most excited is their Tracer software.  Tracer allows root level tracking of tasks and progress, providing near real time feedback regarding project health and status and individual task performance.  I think it is wonderful that they have made their solution available to the industry at large.   It is much like the factory floor real time feedback in manufacturing, applied to software.  From CAI’s web site is the following description which describes estimating effort, cost, and process tracking.:

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 or call us at +1 310 414-3222.

Related Posts Computer Generated




Government IT Projects: Opportunity For More Success

May 8, 2009 · Filed Under Estimating, Project Management, Thoughts · Comment 

I heard of a wonderful blog on Zdnet regarding additional oversight and transparency in Government IT projects costs, schedule: S.920 the Information Technology (IT) Investment Oversight Enhancement and Waste Prevention Act of 2009. 

The bill is targeted to prevent issues:

1. cost overruns and schedule slippage from the estimates established at the time the program is initially approved

2. Number of requirements and business objectives at the time the program is approved that are not met by the delivered products

3. Number of critical defects and serious defects in delivered information technology.

The bill requires specific items be available on project performance including:

  • Cost, schedule, and performance using Earned value (ANSI-EIA-748-B)
  • Project Trends
  • commencement of the project;
  • Variance from cost, schedule or performance & rationale
  • Number of times projects are re-baselined

  This can really help, if done correctly. ” When Performance Is Measured Performance Improves, When Performance Is Measured and Reported the Rate of Performance Increases”



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.

Related Posts Computer Generated




Final Version of the GAO Cost Guide

It appears that this is the final version of the GAO cost estimating guide which provides guidance on preparing viable cost estimates both early in the process and throughout the life cycle. Congratulations to the team.  This is a great contribution to the industry and can, if used as intended create more successful projects.  I especially appreciate the focus on preparing a viable estimate of cost, schedule, etc. then applying earned value management (EVM) to that. So often, in the past we have seen a chasm between those that generated estimates and the EVM people.  These are two sides of the same coin.  The introduction follows:

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 or call us at +1 310 414-3222.

Related Posts Computer Generated




CMMI Challenges Being Addressed: Process Is As Process Does

November 18, 2008 · Filed Under Project Management · 1 Comment 

SEI people are battling the “Process for process sake” syndrome. CMMI is really trying to invoke a set of best practices. The level is not the goal.

When CMM (CMMI’s predecessor) was first developed the Government promised that the CMM level would not be used to judge organization in contract award. This was forgotten almost immediately.

DCMA released a study in 2007 that found for ACAT-1 (Really big programs) CMMI level was:

  • About 83% mostly adhere to CMMI processes
  • About 44% somewhat adhere to processes

Another study found that the 6 major reasons for program failure were:

  1. Business practices
  2. Culture
  3. External influences: I what it now
  4. Enabling Infrastructure
  5. Joint Integrated Processes
  6. Acquisition Reform (loss of system engineering capability within government)

NOTE engineering processes were not a root cause of program failure



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.

Related Posts Computer Generated




Many Observed Incorrect Implementations of CMMI High Maturity

November 18, 2008 · Filed Under Project Management · Comment 

At the CMMI conference a number of difficulties with high maturity, CMMI levels 4 & 5 quantified management. Some included incorrect use of standard statistical techniques for example:

  • Too few data points
  • Updating control charts too infrequently
  • Bad formulas in control level calculations
  • Trying to statistically manage inappropriately
  • Using aggregated data
  • Presenting baselines as stable when they were not
  • Lack of quantification of quality and process performance objectives
  • Lack of management use of information
  • Using trivial cases to show CMMI levels 4 & 5

They also discussed how many organizations just wanted a number.. that they didnt really have a commitment to process.  And how that is (finally) changing.

I was thrilled to hear that practice is changing.  Over the years we have been disturbed by the trend to get a small project or organization certified, then do business as usual throughout the company.. that is process not being used.

This is the reason SEER for Software provides approximate CMMI level as an output rather than an input.  When CMM first came out people asked for knowledge bases or parameters the woudl change the estimate just based on the CMM level.  We actually built some draft knowledge bases based on the characteristics of organizations with higher maturity but never released them because we realized that organization CMM or CMMI level does not generally impact the individual projects on a per sey basis.  We realized that people, process and technology inputs to SEER actually predict the effort, schedule and effective CMMI level best.

SEER estimates any CMMI level well.  It used the root causes of improvement (people, process, technology, reuse, etc.) to generate such estimates.  The other reason this is so powerful is because management and other stakeholders can see and understand the specifics of why their estimates change.



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.

Related Posts Computer Generated




Next Page »