Sometimes I tend to focus too much on the project itself; how to handle things, how to plan and deal with everyday interruption. I look and an interruption I think: where the heck that it came from? Well, the answer my friend is: from the outside.

After running a certain project for a long while project managers can get a fixation with just there project: ¦meanwhile back here in the asylum¦

My good new years wake up is a discussion from IT people from some financial institutions. They talked about their IT maturity as an integral entity: projects, support, customers, etc. It is actually the ole Capability Maturity Model CMM) of the SEI. You now: 5 levels of maturity, ranging from completely undefined to totally in control, proactive IT. Doesnt that simply sound good?

Of course I know about the CMM and other quality models¦ but like I said, one just simply forgets once in a while. However, in the article they mention that people in the highest maturity level

¦spent 18 percent less and utilized 36 percent fewer resources than the other 90 percent - all the time contributing higher service levels to their organization.

Wow.

I guess I just have to start reading up on this again and get it to use.

BTW the biggest unsolved problem …

..was rationalizing IT services offered to the business units. Service rationalization gives companies insight into the total cost of offering services to help them make better investment decisions.

Seems sometimes like a luxury problem to me.

For the subject of numbers around software projects Level 4 of the Capability Maturity Model (CMM) is da bomb: software as a Quantitatively Managed process.

A quantitatively managed process is a defined (capability level 3) process that is controlled using statistical and other quantitative techniques. Quantitative objectives for quality and process performance are established and used as criteria in managing the process.  (CMMI)

Wow. Project Number Fetishist Heaven! I thought I check it out for some nice entries to put on this site. Well, I got more than I bargained for¦ thats just too much¦ but it is great fun¦

Fun? you ask.

Well in some weird way¦ Think of all those students that after years of university can do all those quantitative managed things, just to find out that for them as a novice it is useless. They need experience to do all those numbers.

He, it says so in the CMMI description self:

One essential element of quantitative management is having confidence in estimates (i.e., being able to predict the extent to which the project can fulfill its quality and process-performance objectives). The subprocesses that will be statistically managed are chosen based on identified needs for predictable performance.  (CMMI)

Great. You have learned all this stuff, and you will be ^%^%^ by an old frustrated programmer that provides you with bogus over the top estimates. Should be frustrating

And¦

Another essential element of quantitative management is understanding the nature and extent of the variation experienced in process performance, and recognizing when the projects actual performance may not be adequate to achieve the projects quality and process-performance objectives. (CMMI)

You see that your budget is going down the drain, but you need real experience to know the difference between real panic or just normal project behavior (BTW thats normal behavior).

Yeah, numbers are a funny thing¦ they provide you with an aura of precision, but you need sooooo much interpretation to give them the proper meaning. Like they say: you have lies, more lies and statistics¦ or something like that :-).

One of the subscribers of my newsletter brought one old rule of thumb to my attention (thanks Terry!). I almost forgot this one.

It is known as the 1:10:100 Rule: the cost to fix a defect increases exponentially the later in the development lifecycle that it is identified.

Photography by Absolutwade.

• A defect caught in requirements phase costs a factor of 1 (1x) to fix.
• A defect caught in construction costs 10 times as much as in requirements.
• A defect caught in production costs up to 100 times as much as in requirements.

In this context it makes sense to define the test scripts as early as possible, during the requirements definition.

Or, as Terry put it into a mail to me:

Most companies currently decompose requirements into test cases for system testing during the construction phase. If they would simply move this same effort forward to the requirements development and physical design phases, they could save a lot of money!

However, I am wondering how current techniques, and tools are affecting this. The costs of creating testable applications (proof of concepts, prototypes etc) to use as feedback mechanisms are dropping, so I wonder if the 1:10:100 factors are still holding true.

Of course for large complex systems it will still hold, but for smaller business apps, I am not sure. But incorporating the test cases already with the requirements definition is always a good idea. End of course, making a change in a design documens is most of the time cheaper than changing a running system. But if those numbers are still exponential?

I wonder.

Most development projects spend effort in creating specifications: functional, technical, detailed, global. Putting the designs in writing takes a lot of work, and it will not be used in the end result; specifications are supporting artifacts.

So, the question if specifications are worth the effort is legit. Jeff Sutherland quotes some research in this area in his article Future of Scrum: Support for Parallel Pipelining of Sprints in Complex Projects

Two metrics are mentioned: the productivity of the development group and the defect rate. In a tongue-and-cheek definition, the productivity is the amount of features / lines-of-code build in a given time frame, and the defect rate is the number of bugs found per amount of features / lines-of-code.

The article of Sutherland mentions that there is a strong relationship between the completeness of the formal specification and the productivity. The better the sense of the developers is of the desired end product from a functional perspective, the faster the program.

The other way round with completeness of design specifications and the defect rate. The relationship between them is found very weak. So, writing more detailed designs before programming doesnt reduce the amount of bugs.

Leaving us with the question what can we do about defect rate and productivity. In the mentioned article the following options are provided for lowing the defect rate: early prototypes, design reviews and testing at code check in. Increased productivity is reached by early prototyping and daily builds of the software.