In this post I’ll dis­cuss why a scope is so nec­es­sary if soft­ware projects are to be a suc­cess. A scope is all about mak­ing choices and man­ag­ing expec­ta­tions. Besides that the same rules which apply to mile­stones apply here, after all the deter­mi­na­tion of a scope is a mile­stone in itself. But what are extra fac­tors we need to focus our atten­tion on?

Two Ques­tions Con­cern­ing Scope Determination

The com­plex­ity that accom­pa­nies scope deter­mi­na­tion is not the sub­ject itself, but the fact whether or not it is done in the first place. Projects deeply immersed in the process of actu­ally imple­ment­ing soft­ware in the absence of a scope are with­out a doubt head­ing on a col­li­sion course with disaster.

“By far the most impor­tant aspect of what NOT to do when deter­min­ing a scope is never fin­ish­ing the process.”

You have to ask your­self the fol­low­ing two ques­tions with respect to scope, both need to be answered affir­ma­tively before you can trust­fully ini­ti­ate an imple­men­ta­tion phase:

• Are all stake­hold­ers famil­iar with the scope?
• Has the scope been approved by at least the end user and sup­plier?

Ques­tion #1: Are All Stake­hold­ers Famil­iar With the Scope?

Let’s dis­cuss the first ques­tion: are all stake­hold­ers famil­iar with the scope. Again, it’s such a sim­ple idea but as often with sim­ple ideas, they’re read­ily over­looked. If the answer to this ques­tion is neg­a­tive you will have a sub­stan­tial risk the prod­uct won’t be able to meet all of the deci­sive demands each group imposes on it. Cases have been known where whole prod­ucts were shelved cost­ing mil­lions of dol­lars because the scope wasn’t com­mu­ni­cated pre­ma­turely to a judi­cial apartment.

Ques­tion #2: Has the Scope Been Approved By At Least the End User and Supplier?

The sec­ond ques­tion: “has the scope been approved by at least the end user and sup­plier” could be even more impor­tant. Some peo­ple make a great deal about a for­mal– and non-formal approval of scope. I don’t. One rea­son being that try­ing to get a for­mal approval can cause high lev­els of resis­tance. Although I under­stand the neces­sity in some cases of a writ­ten or spo­ken approval given by the per­son who’s been given the abil­ity to do so, it’s all the same to me. The project method­ol­ogy Prin­ceII says the role of (senior) end user is manda­tory and its this per­son which essen­tially has to give his or her approval about scope. Equally impor­tant is the sup­pli­ers role. Both roles can be per­formed by one or more indi­vid­u­als. The sup­pli­ers role is impor­tant because the knowl­edge it rep­re­sents plays a piv­otal role in esti­mat­ing the scope attain­abil­ity. It is not uncom­mon to have a scope approved with no sup­plier con­sul­ta­tion what­so­ever while some parts of the scope were badly phrased, cost way to much money or need a whole other direc­tion con­cern­ing the pro­posed tech­ni­cal solution.

I’ve had dis­cus­sions wether or not a scope is as impor­tant as I make it seem. If you find a con­struc­tive way in deal­ing with the pit­falls every project brings with it with­out using a scope I applaud you, because that’s a neat feat. For me work­ing with­out a scope is clos­ing your eyes to real­ity and offer­ing a weak prayer hop­ing every­thing will go as you would like it to be. More often than not it won’t, so ask your­self and the peo­ple you work with the two ques­tions in this sec­tion and be honest.

Related posts:

1. Soft­ware Project Trait #3: Roles
2. Soft­ware Project Trait #4: Milestones
3. Soft­ware Project Trait #1: Hall Stand
4. Soft­ware Project Trait #2: Generic Power
5. Soft­ware Project Foun­da­tion Necessities