Opportunity To Participate in Software Success Survey
While I have been publishing the Standish Chaos survey results, Galorath’s Lee Fischman has longed for a complimentary software and IT success survey where the results are open and auditable. In that regard, Lee has now made his survey available to the software community.
Lee will provide detailed results and analysis (sans attribution… your individual inputs will remain private) to every participant. And he will publish summary results more widely.
I recommend you fill out this software and IT Success survey while you are thinking about it.
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.
Have We Lost Our Ability to Estimate Software Size
I really enjoyed Galorath’s David DeWitt’s article “Have We Lost Our Ability to Estimate Software Size, AKA I’ve Been Slimed”, posted below:
David DeWitt,
“I’ve Been Slimed!” – Dr. Peter Venkman, Ghost Buster
I can clearly remember that day I arrived at work – towards the end of the year 2003 – it was easily before 6am. I was leading a small team tasked with prototyping a test environment for a NASA proposal. I stood there amazed as I watched my two programmers demonstrate a completely reengineered satellite simulation environment. Wait – let me be clear – within only a few days – they rewrote close to 30,000 lines of FORTRAN and another 4,000 lines of assembly code. How did they do it? They called it “goop.” “The hand cleaner?” I asked – rather befuddled. No, they were referring a new development language by LabVIEW (National Instruments) called “GOOP” – short for Graphical Object Oriented Programming.
That was the day I decided to stop being a programmer. I was, at my ‘age,” no longer really interested in keeping up with the latest programming paradigms (and vernacular – such as “paradigm”). I decided to abandon the past and embrace my role as a program manager. But now, looking back I wish I would have asked a few more questions.
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.
Evidence Based Scheduling
Joel on Software (Joel Spolsky) sent an email recently discussing the release of a major update to one of his products. He pointed out they shipped two weeks early. He stated some of the features got dropped but they still made their ship date. Even if Standish might call this a challenged project I believe it was well run and successful.
Joel’s use of evidenced based scheduling, which estimates every root level task and looks at performance versus estimates, combined with Monte Carlo analysis to predict project completion. Evidence based scheduling original topic well worth a read.
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.
Stomping Out Software Rework
There are two definitions of rework in software projects…the good and the bad:
Rework, The Good: redesign, reimplementation, retest of preexisting software during enhancement.
Rework, The Bad: having to redo the same work multiple times due to errors or lack of review. Rework is doing the same thing over again, excluding refactoring which is done to make software more maintainable.
Galorath has been working hard at reducing the bad rework over the past year. This process has involved more detailed reviews of user interface and other critical items during requirements and design. For example, today I sat in a review of an enhanced dialog box for a major SEER function. The review, and the associated changes took 4 people an hour each. This is the 2nd review. The first setup the details of the requirements. Some would say that is a lot of time to spend on a single dialog box (even a critical one). But the dialog box is better (yes we have criteria for better) than it was as the review started. So two wins: 1) there will not be rework when the dialog box is deployed and 2) the users will get a better experience, reduced technical support and easier training.
The 8 hours total of review will pay back many times over.
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.
Poor Estimation: Major Root Cause of Project Failure
I find it interesting how many people just go forward without a clue as to what is involved in developing and operating an IT system. I spent the week at the birthplace of root cause analysis. What a pleasure to hear leaders state “amazing” that they could get visibility into the cost, schedule, risk and reliability of a system. And to hear them identify their current estimating difficulties as a root cause of project failure. Here are a few typical scenarios:
1. Don’t estimate at all: We will go forward and do good things…and tell you when we are done.
2. Estimate based on simple guessing: We think we can do it for x in y time. But why? How is it repeatable? How can we improve?
3. Estimates reduced by mandate: Decent estimates that are politically incorrect, often reduced considerably to meet an impossible deadline or cost.
When the estimate is bad, the associated plan (you do have a plan, don’t you?) is doomed from the start. Expectations are not met, shortcuts are taken attempting to make up the time, business value is lost as projects are late or canceled.
I also have to shake my head when I see programs that use earned value to track but do not have a viable baseline to track from.
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.
The Value of Lessons Learned In Improving Estimates
The latest issue of the IEEE transactions on software engineering has an article discussing the value of lessons learned in improving software estimates. I have been on the run and unable to read the entire article yet (I will update this once the article has been absorbed). But the conclusion seems to say lessons learned reviews do not help.
While this sounds like heresy, I believe they are comparing such reviews to personal experience. I would have to conclude myself that personal experience is better than someone else’s lessons learned. But so what?
Lessons learned are an important part of a viable process and essential for larger organizations.
Here is the abstract:
Inaccurate estimates of software development effort is a frequently reported cause of IT-project failures. We report results from a study that investigated the effect of introducing lessons-learned sessions on estimation accuracy and the assessment of uncertainty. Twenty software professionals were randomly allocated to a Learning group or a Control group and instructed to estimate and complete the same five development tasks. Those in the Learning group but not those in the Control group were instructed to spend at least 30 minutes on identifying, analyzing, and summarizing their effort estimation and uncertainty assessment experience after completing each task. We found that the estimation accuracy and the realism of the uncertainty assessment were not better in the Learning group than in the Control group. A follow-up study with 83 software professionals was completed to better understand this lack of improvement from lessons-learned sessions. The follow-up study found that receiving feedback about other software professionals’ estimation performance led to more realistic uncertainty assessments than receiving the same feedback of one’s own estimates. Lessons-learned sessions, not only in estimation contexts, have to be carefully designed to avoid wasting resources on learning processes that stimulate rather than reduce learning biases.
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.
Defense Acquisition Guidebook From DAU
The Defense Acquisition University has released an update to its guidebook covering acquisition. Cost estimating and analysis are part of this on-line resource as chapter 3, “Affordability and life-cycle resource estimates. The announcement follows:
For DAU Alumni Association Members: Because of significant policy revisions associated with the re-issuance of DoD Instruction 5000.02 in December 2008, a complete review and revision of the Defense Acquisition Guidebook (DAG) has taken place. The revised DAG (including implementation guidance resulting from the Weapon System Acquisition Reform Act of 2009) will be finished and on-line several months from now. While that task is being completed, an Interim DAG has been created and posted to the following website (https://acc.dau.mil/dag).
The Interim DAG has the same business practice and policy content as the final will have, but with fewer internal and external navigation options. The objective is to provide acquisition professionals with the information needed to manage programs while the DAG is made more user friendly.
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.
US Government IT Spending Dashboard
The new government CIO has started a site showing the federal budget. If you are interested in IT spending within the US government take a look at this site: “US Government IT Spending Dashboard.”
The dashboards include project portfolio management, visualization and includes analysis. Information encompassing many items such as:
- New Versus Upgrade Versus Maintenance
- Specific IT Spending By Category
- Trends in spending by category
From the site’s background:
The IT Dashboard provides the public with an online window into the details of Federal information technology investments and provides users with the ability to track the progress of investments over time. The IT Dashboard displays data received from agency reports to the Office of Management and Budget (OMB), including general information on over 7,000 Federal IT investments and detailed data for nearly 800 of those investments that agencies classify as “major.” The performance data used to track the 800 major IT investments is based on milestone information displayed in agency reports to OMB called “Exhibit 300s.” Agency CIOs are responsible for evaluating and updating select data on a monthly basis, which is accomplished through interfaces provided on the website.
Check out the IT Spending and Trend videos on the FAQ page for examples of how to use this resource.
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
