When the sub­ject of mile­stones was dis­cussed I talked about a return to lin­ear­ity for var­i­ous pur­poses. This seems to be in direct con­trast with this sub­ject, which is all about work­ing with iter­a­tions. But the two can live together with­out being mutu­ally exclu­sive. Before I answer the ques­tion how to accom­plish such a thing, first let me explain some­thing about the sound­ness of iter­a­tions? When I deal with iter­a­tions I specif­i­cally mean soft­ware project phase-iterations. Project Phases con­sist of a set of activ­i­ties. Project Phase iter­a­tions are iter­a­tions where the same kind of activ­i­ties are per­formed mul­ti­ple times before the phase ends and the fol­low­ing phase begins. So you can imme­di­ately see the lin­ear­ity co-existing with phase iter­a­tions. You can have sev­eral phases start­ing lin­early while the activ­i­ties within a phase hap­pen mul­ti­ple times. Confused…?

Scope Creep

Ask your­self the fol­low­ing question:

“What do I do with cer­tain issues imper­a­tive for pro­duc­tion when we’ve deter­mined a scope long ago?”

That’s not so much a ques­tion as a fact of soft­ware projects who’ve been given their own name “scope creep”. When on a soft­ware project, devis­ing a project plan, deter­min­ing a scope, or what­ever, the thing to inter­nal­ize is another old adage: “plan for the worst, hope for the best”. It’s not the other way round. Unfor­tu­nately project phases are com­monly packed tighter together than peo­ple in the econ­omy class of Ryan Air.

“Soft­ware Project Plans paint unre­al­is­tic suc­cess sto­ries where, with­out any form of feed­back,  appar­ently in one iter­a­tion (= no iter­a­tion) a project phase can switch from one to another.”

Some­one once told me the fol­low­ing when I com­mented on the mess we were in because of a totally unre­al­is­tic dead­line. “Oh, but that was for “com­mer­cial pur­poses”.” I asked the per­son in ques­tion how “com­mer­cial” it was not only to stress the whole team because of a dead­line they couldn’t for the love of God ever reach while dis­ap­point­ing the cus­tomer because of the lack of integrity we now had to show for not keep­ing our end of the bar­gain? That whole project just sucked big time, I have no other words for it. The argu­ment about being com­mer­cial was typ­i­cal for the whole atti­tude con­cern­ing soft­ware projects I con­sider so very wrong. Remem­ber I men­tioned ear­lier some­thing about being shot in the foot before run­ning a marathon. That’s how I felt. “Never again” that’s what I thought. We’ll see what the future brings.

What We Need Is Com­mon Sense.

“Com­mon sense dic­tates that things are never ever per­fect and never will be.”

If it’s no dif­fer­ent for soft­ware projects, and it sure isn’t, it would mean we need the com­mon sense of work­ing with iter­a­tions. With iter­a­tions as buffers we guard our­selves against the idio­syn­crasies of soft­ware projects. We give our­selves time to deal with them with­out being rushed because we know there’s time.

• Maybe you’ll need time nec­es­sary for deal­ing with addi­tional require­ments for a con­cept soft­ware design to get an agreed on scope between client and supplier.
• Or it could have been for pro­cess­ing addi­tional func­tion­al­ity in a new design after an accep­tance test or incor­po­rate time to solve bugs found dur­ing this spe­cific kind of test.

Maybe it’ll be nec­es­sary dur­ing all of these exam­ples. We need to iter­ate dur­ing phases, to dis­cuss project mem­bers’ feed­back and be able to deal with it. I know, it sounds like com­mon sense all over again, but to use another one-liner “com­mon sense is not com­mon knowl­edge”. So called “com­mer­cial” argu­ments like in the exam­ple above many times have sound the death-knell for com­mon sense.

“When it comes to soft­ware projects I don’t get sur­prised often any­more with what peo­ple say or think or do, but one of the things that keeps amaz­ing me is the seem­ingly sheer unwill­ing­ness to learn from ones mistakes.”

After the amaze­ment comes the real­iza­tion that even stu­pid­ity has it’s advan­tages. For the indi­vid­ual there must some­thing to be gained from it. We often find our­selves stand­ing on cross­roads of what Stephen Covey beau­ti­fully calls the “high and low road”. Let’s take the one chal­leng­ing us the most. It’s obvi­ous which one that is.

Cone Of Uncertainty

A very famous model of deal­ing with uncer­tainty is Barry Boehm’s “Cone of uncer­tainty” [Fig­ure 1]. Although the model is an accu­rate rep­re­sen­ta­tion how a project relates to cer­tain mile­stones, I would like to take the oppor­tu­nity to show you how iter­a­tions con­tribute to low­er­ing uncer­tainty both sim­ply and effec­tively. Boehm’s model dates from 1981 and although a lot has changed in the soft­ware indus­try since then the essence of the model still stands. One thing I dis­agree with is that he intro­duces a total of five mile­stones deal­ing with design­ing before com­menc­ing on the actual imple­men­ta­tion of soft­ware. I find it not the best way intro­duc­ing that many design mile­stones, because it actively encour­ages employ­ees to con­stantly come up with new way’s to expand a project’s scope. It’s a breed­ing ground for procrastination.

If you look at the other fig­ure [Fig­ure 2] you’ll see that by con­se­quently incor­po­rat­ing iter­a­tions the amount of uncer­tainty is effec­tively reduced to man­age­able pro­por­tions. We do this by pur­su­ing agree­ment dur­ing our meet­ings and let­ting it be ensued with con­struc­tive follow-up e.g. actions. An impor­tant dis­tinc­tion when deal­ing with iter­a­tions is that you or the one respon­si­ble for plan­ning allo­cate time before the iter­a­tions have to occur, not after. This way of think­ing about iter­a­tions pre­sup­poses a dif­fer­ent mind­set in the way we deal with chal­lenges dur­ing our projects. Even if you have the cer­tainty you’ll be able to deal with inevitable prob­lems when they arrive, after all you have the skill set, the tools and the expe­ri­ence to do so, will you have the time nec­es­sary for intervention?

There are always two sides when deal­ing with the chal­lenges we have to face: tools and time. It’s true we have to know how to deal with some­thing but we also need to have what I’ve called ear­lier, the “breath­ing space” to remain focused on where the main issues are. Else you’ll not only have prob­lems but also the build­ing up of stress, which cre­ates even big­ger prob­lems, and before you know it, what began as a minor chal­lenge has gained momen­tum beyond your capa­bil­i­ties. That’s when it’s too late. So for rep­e­ti­tions’ sake, plan space for iter­a­tions before prob­lems are here not after. There’s no such thing as plan­ning after some­thing has hap­pened, that’s a con­tra­dic­tio in ter­minis, a para­dox in itself.

“In life there are a lot of things you won’t be able to con­trol, tak­ing action to be pre­pared for prob­lems com­ing your way is some­thing you CAN con­trol, cer­tainly dur­ing soft­ware projects.”

4 Cru­cial Iter­a­tions For Every Soft­ware Project

Now we can under­stand why project phases and project phas­ing are cru­cial ele­ments of soft­ware projects, because it gives us a con­cise way to know when to iter­ate. The fol­low­ing iter­a­tions should always be part of your project phases:

• Design iter­a­tions between soft­ware designer and soft­ware developer
• Design iter­a­tions between soft­ware designer and client
• Devel­op­ment iter­a­tions with sys­tem test­ing (a test exe­cuted by the sup­plier to deliver a func­tional viable appli­ca­tion within scope)
• Devel­op­ment iter­a­tions with accep­tance test­ing (a test exe­cuted by the client/end user to gain enough thrust in the soft­ware to be used dur­ing production)

You can see var­i­ous roles men­tioned ear­lier being linked with phases, mile­stones and iter­a­tions. That’s because they are nec­es­sary for the via­bil­ity of the iter­ated phase and the project as a whole. It’s dur­ing these iter­a­tions that the roles are being brought together to play their respec­tive parts. We can now also appre­ci­ate the sound­ness of project phases far more with the real­iza­tion that it sup­plies us with immense effec­tive tool­ing to han­dle project chal­lenges and the abil­ity to struc­ture and pri­or­i­tize work. Phases sup­port us with the three key ele­ments of the project ecosystem:

• mak­ing choices
• tak­ing follow-up action
• man­ag­ing expectations.

Related posts:

1. Soft­ware Project Trait #5: Scope
2. Soft­ware Project Trait #6: Meetings
3. Soft­ware Project Trait #2: Generic Power
4. Soft­ware Project Trait #4: Milestones
5. Soft­ware Project Trait #1: Hall Stand