“A thou­sand mile jour­ney starts with the first step.”

Dur­ing projects it’s cru­cial we set goals. We not only set a goal to be attained for the project as a whole, or indi­vid­u­ally with respect to roles, but we set mile­stones. Some project takes years to fin­ish and when peo­ple are on that band­wagon from the start it’s easy to get lost in the conun­drum of day to day liv­ing and lose your drive. So we have to chunk things down to man­age­able bits and cel­e­brate when we’ve attained the goals we set out for these bits. Because of the generic char­ac­ter of project phases I’ve come up with four which are listed below, they are:

• Scope deter­mi­na­tion
• Pro­to­type delivery
• Pro­to­type acceptance
• Soft­ware usage

Keep­ing the Momen­tum Going

While I don’t want to go in to the details of what hap­pens dur­ing these mile­stones because a whole set op posts is devoted to them, I do want to open up another issue, which is about the fol­low­ing. Using mile­stones is about keep­ing the momen­tum going. If that’s true it pre­sup­poses a lin­ear­ity, because mile­stones are unique in so that they only hap­pen once. You can’t deliver the same pro­to­type twice just as you can’t accept the same pro­to­type twice.

“Why it’s so impor­tant to be lin­ear with respect to your mile­stones is that you have to reach them in sub­se­quent order.”

Again, I agree it doesn’t have to be that way, but it takes an extremely pro­fes­sional orga­ni­za­tion where each player can per­form par­al­lel tasks and seam­lessly let it fit in with the tasks of their team mem­bers with­out wast­ing time and being inef­fi­cient. I’ve as yet never come across one. I sure hope some­day I have the priv­i­lege to do so. Till then I pro­fess a return to lin­ear­ity when it comes to mile­stones, which is, always start with deter­min­ing your scope.

Five Rea­sons Why Peo­ple Don’t Deter­mine a Scope Dur­ing a Soft­ware Project

I have wit­nessed count­less times peo­ple wouldn’t do this for the fol­low­ing reasons:

• Pure and stu­pid ignorance
• Because they thought they didn’t have the time
• Because they thought they didn’t hav the money
• Because they  just didn’t feel like it
• Because they didn’t think it was important.

For what­ever rea­son they did it, it doesn’t mat­ter. I have no expe­ri­ence with projects who faired well with­out a scope, I have painful ones where  a scope was absent with dis­as­trous results. Dis­as­trous for the project and its peo­ple, both men­tally and, in the end, phys­i­cally. More on scope later on. The same goes for pro­to­type deliv­ery and accep­tance. You can’t accept some­thing never deliv­ered. It’s sounds as sim­ple as that but yet again, what hap­pens in prac­tice tells us a dif­fer­ent story. Half fin­ished prod­ucts invested with bugs being force­fully accepted by a user group who never even asked for it. Does that hap­pen? All the time. Will this work? No! Will peo­ple be happy? No! Then why do we do it? Read this post on cog­ni­tive dis­so­nance!

Soft­ware Projects Are About Fin­ish­ing a Job After It Has Started

Think­ing lin­early is not only sen­si­ble because of the dif­fi­culty in per­form­ing par­al­lel activ­i­ties, it’s about fin­ish­ing the job when you’ve started it. For many years I’ve rid­den bikes. I went into the French hill­side and rid­den trough the coun­try­side plough­ing on uphill for miles and miles. For the group I’ve been rid­ing with those years, it’s dis­hon­or­able to quit on an ascent. Every­body would make sure you felt it if such a thing hap­pened. You will be the laugh­ing stock for years to come. No mat­ter what hap­pened, how fast your heart would be beat­ing, almost jump­ing out of your chest, no mat­ter how blurry your vision would be, keep on ped­dling. That was the num­ber one rule for all of us. I remem­ber one ascent two miles long, but it was 20% or more all the way. It was so steep at points that pedes­tri­ans almost went as fast as we did going up. I died a thou­sands deaths on that hill but nei­ther I nor the friends I was with quit that day and we felt so proud.

“A lot of times when things get tough peo­ple quit and they make up sto­ries which place respon­si­bil­ity out­side them­selves.”

Even though it’s so much more ful­fill­ing to fin­ish some­thing you had to put effort into and had to step out­side your com­fort zone for. That’s where the growth starts.So instead of thinking:

“This scope thing is too hard a nut to crack, because I’m all about avoid­ing conflict.”

think

“I know in the end the best thing for my cus­tomer and myself will be to do this right now, so we don’t have to face the prob­lems of a project’s scope bloated all out of pro­por­tion in the future.”

The Mir­ror

Don’t kid your­self, if you take a hard look at what’s nec­es­sary in per­form­ing your job, you know when what road needs to be taken. If you look in the mir­ror it’s often very hard to BS your­self, so don’t. You’ll be a bet­ter per­son because of it. I often tell the fol­low­ing to peo­ple who are frus­trated because seem­ingly there isn’t enough appre­ci­a­tion for a job well done, only nag­ging about the things that could have been better.

“Besides the fact that they can take the pride from within them­selves, that no mat­ter which way you turn it, and even if it doesn’t always looks that way, truth, integrity, pro­fes­sion­al­ism and hon­esty, those char­ac­ter traits will be rewarded because they are ever­last­ing.”

Besides all this there’s exten­sive evi­dence orig­i­nat­ing out of goal-setting the­ory that posit­ing clearly defined dif­fi­cult goals (e.g. mile­stones) stim­u­lates pro­duc­tiv­ity in solv­ing sim­ple tasks (arith­metic tasks for instance ver­sus man­age­r­ial tasks). The nature of soft­ware engi­neer­ing has direct link­ages with solv­ing arith­metic tasks. From this can be con­cluded that a soft­ware design can be an extremely impor­tant device with which to stim­u­late soft­ware developer’s pro­duc­tiv­ity. So evi­dently it’s not only the “man­agers” job to stim­u­lates his sub­jects. A soft­ware design is cru­cial dur­ing each of these mile­stones so take an active role in steer­ing the project towards the attain­ment of her goal. Now let’s take a closer look at the impor­tance of a project’s scope.

Related posts:

1. Soft­ware Project Trait #3: Roles
2. Soft­ware Project Trait #2: Generic Power
3. Soft­ware Project Trait #1: Hall Stand
4. Soft­ware Design Prepa­ra­tion & Execution
5. Func­tional Spec­i­fi­ca­tions: the Soft­ware Project Ecosystem