Dan’s 2 Papers At CMMI Conference In Denver Nov 18 & 19
Dan will be giving two papers at the CMMI conference in Denver and will be available for consultation during the Tuesday and Wednesday Nov 18 and 19.
1. Improving Project Planning and Control: A 10-Step Process Within CMMI or other Process Orientations Click Here
2. CMMI’s Role in Reducing Total Cost of Ownership: Measuring and Managing New and Legacy Software Click Here
Effectiveness Measurement At Galorath Still Focusing On the Positive
I was in an ISO review today at Galorath Inc. I saw customer satisfaction scores that were through the roof (in a good way.) I saw compliments (from the ISO compliments file) that were flattering. I asked about the complaints file (also an ISO requirement) I was told we had no complaints since the past review. I personally appreciate the compliments but learn more from complaints. When pressed I found nothing was reported as complaints. But there certainly had been some areas where we could have done better.
Process improvement is about finding where things could be better, not about painting rosy pictures. We are in the business and even we like to concentrate on the good and minimize the bad.
We are probably better than most in this regard. Process improvement and improvements in customer satisfaction is important. And to achieve these we have to identify and stress where we can do better.
The Mistake of Measuring Everything
I recently participated in a seminar with Larry Dribin of Pearl Street Group. Larry did a beautiful job with a talk called something like “You Get What You measure” Afterwards I added the corollary “If you measure everything you get nothing”
I have seen a number of organizations that just start measuring everything. They figure they will do something with the measurements sometime. Measurement becomes a burden with no ROI. And people can’t respond by doing the best job on what they are measured against. Read more
Correction to DACS Article and Apology To Capers
In a recent article published in the DACS journal I incorrectly gave credit to Herb Krasner for work done by Capers Jones. My apologies to Capers and Herb. The DACS article will be corrected electronically in the next few days to give Capers credit.
This BLOG will contain the corrected article ASAP as well.
Update: the reference should have read:
Jones, Capers; Software Quality - a Survey of the State of the Art; Software Productivity Research LLC, Narragansett, RI; 2008; (data updated annually).
Development Teams Using Note Cards: 20th Century Here Today
Lee Fischman, Galorath Guru attended the PMI conference last week. He sent an email during the confernce concerned about note cards as a project management approach. Lee sent the following for publication:
“These Agile teams that use note cards claim all sorts of wonderful
benefits from them, like seeing the entire project’s status on a wall,
and solid ownership of tasks. In fact, case tracking systems like JIRA
and Fogbugz do all that too, plus lots more such as sorting, metrics,
etc. I guess one reason people like note cards is that they are so
tangible. But using them reminds me of people who print out their
emails - soooo 19th century. Note cards are even worse, because they
are hand-written. Agile proponent Alistair Cockburn called these
“Information Radiators” but there doesn’t seem to be strong theoretical
support for the idea of using note cards over online systems. It’s not
that the entire Agile community feels like they have to do these things
by hand, because Rally, VersionOne, XPlanner and other vendors do offer popular tools to automate project management. Apparently other people agree with the notion that note cards are, uh, not optimal”
Bad Assumptions Invalidate Business Value and ROI Analysis
I recent email announced “ROI estimates in business fail primarily because managers give too much attention to the “payout” odds and too little attention to measuring and managing “probability” odds. A good risk and sensitivity analysis of the assumptions behind the predictions allows you to do both. ”
This is so true. Inappropriate or unlikely assumptions looking for payout based on the absurd (such as assuming that saving 1 minute per day of employees filling in their time card has a huge savings in a year) and a myriad of other traps cause business value and ROI to be appropriately produced using sound business case analysis.
In the same vein, absurd assumptions can cause cost and schedule estimates to be low. SEER evaluates the viability of assumptions, helping produce estimates that can actually be deployed.
Audits Improve Processes
I know not many people like an audit. Brings up thoughts of people trying to show you made a mistake.
But I just received a notice of our upcoming ISO 9001:2000 audit and I am thrilled. While we deal with processes each day, it is productive to take some time and ensure we are doing out best and to look for ways to do things later.
Part of proper management is reducing waste, seeing things that are done that don’t add value and eliminating them.
Another part of such an audit is seeing where people are doing well and making sure the whole company uses that best practice.
Initially the goal is just to have a process, even if it isnt the best. Then to refine the process(es) to reflect best practices.
At yesterday;s best practice seminar someone discussed waste, and looking to eliminate waste within the organization. I look at some of the simplest things many organizations do that are waste and can be eliminated… Pens handed out at conferences (do we think people don’t show up with writing implements, or that the cheap pens are going to win any gratitude.) Whether you are dealing with CMMI, ISO 9000, ITIL, or whatever process approach.. look for ways to eliminate waste. And remember “the enemy of the best is the good”
2 Kinds Of Metrics: Status & Trend and Effectiveness
First the obvious:
: Status / Trend Metrics: e.g. productivity, defects removal rate, cost, schedule
Most important for improvement: Effectiveness ( 5 max)
“What we are doing that we should not do” e.g. number of delivered critical defects
“What we are not doing that we should do” e.g. number of defects that got past inspections
- These metrics may change over time as we improve
- These are the most important for improvement
1990 IEEE Article On Measurement
I forgot about this article published on IEEE in 1990.. sizing, metrics, measurement.. lessons learned and forecasting the future… The Ada programming language may be only a memory but some things never change. Viewing the article requires electronic access to the IEEE library. I loook forward to comparing these lessons learned with the 2008 lessons learned briefing from Galorath (Bob Hunt Author)
| Ada sizing, metrics and measures-learning from the past andforecasting the future Galorath, D.D. McRitchie, K. Rampton, J.C. Galorath Associates Inc., Marina del Rey, CA; This paper appears in: Instrumentation and Measurement Technology Conference, 1990. IMTC-90. Conference Record., 7th IEEE |
 |
|
|
| Abstract It is noted that Ada has met with mixed successes owing to both differences in the technology applied to the program and differences in line counting and productivity measurement. The authors discuss the various technologies attributed to Ada and demonstrate methods of Ada size and productivity measurement that are appropriate for Ada and consistent with past data |
|
|
|
http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel2/105/2373/00066027.pdf?arnumber=66027
COTS Components in Software Development Are Not Without Effort or Risk
I have lost count of how many project that used COTS (commercial off the shelf software) components thinking they were saving huge development expense where the COTS itself was the cause of project failure.
I recall, some time ago when a super object oriented database was going to save the day, cutting development cost dramatically and exceeding requirements. Only problem is that software didn’t work. And the developer didn’t have source to fix it. And the design was wrong. And On and on.
In a less dramatic sense I look at the seemingly risk free use of COTS components of a small magnitude. For example we used a package that was an excel like plug-in one time for our custom calcs. The vendor went out of business and we lost support. We had to redevelop (this time we used real Excel) but it cost months of development work, and changes to user configurations, and technical support challenges.
And people often forget about testing of the COTS components. They will impact test effort (if you assume they just work you are likely in for a sifnificant project surprise)
Then there is the IT support of a deployed system. Your users dont care if the software is COTS, not developed by you. They want support for the system with its whole mission.
And just the cost of choosing the right (hopefully) COTS software. SEER for Software captures all these costs and risks.
Northrop published a case study showing of SEER-SEM and its COTS abilities: ”the results were remarkable”
SEER for Software’s COTS functionality provides estimates of the effort to choose, use, and deploy COTS software.
