conliffe@caen.engin.umich.edu (Darryl C. Conliffe) (06/13/88)
I would like suggestions and/or reports on how others accomplish the following: having convinced management that an iterative approach to a software design project is appropriate, how do you report progress on same? Since you are not proceding linearly through a series of measurable milestones, what *DO* you use to indicate that the development is "on schedule"? This seems to be a corollary of the question "why aren't you coding yet?", but it also represents management's valid need to know if the appropriate resources are allocated to a job and that the plan of attack is correct. Finally, when employing Structured Analysis and while still working out the layout and definition of your "bubbles", how do you project how long it will take? (This is a new system and the design tools and approach have not been used before on ANY project, no no "history" is available.) -- ___________________ Darryl C. Conliffe conliffe@caen.engin.umich.edu (313) 721-6069 -------------------
csm@garnet.berkeley.edu (06/15/88)
In article <917@blue.engin.umich.edu> conliffe@caen.engin.umich.edu (Darryl C. Conliffe) writes: >the following: having convinced management that an iterative >approach to a software design project is appropriate, how do you >report progress on same? >...how do you project how long it will take? > Darryl C. Conliffe conliffe@caen.engin.umich.edu (313) 721-6069 If management cannot judge from the prototype itself how you are progressing, they sure as hell are not in any position to judge from a (possibly fudged) PERT chart. Arrange periodic hands-on demonstrations (but no more frequently than every two weeks). You must have the following guarantees from the powers that be: 1) Hardware and Software for the project will be delivered to you on schedule or the project will be extended on a day for day basis. If you are not responsible for procurement and/or installation make sure that delays in this process are documented and added linearly to expected delivery date. 2) End-user time will be available. You must be able to get personnel when you need them. Remember, verbal assurances from a middle manager are going to be forgotten when you say you need two secretaries and a supervisor this Friday, all day. The middle manager has someone checking his/her department's progress, too. Ok, how long will it take? For each manager involved in initial meetings add one month. For each manager who says "data flow analysis" add another month. For each unique end-user type add one month. For each unknown software package to be employed add two months. For each unknown hardware device add two months. For each 100 miles between developer and installation add one month. For each type of communication channel add one month. If an IBM mainframe shop is involved and you are working on a non-IBM system add 6 months. If an IBM mainframe shop is involved and you are working on an IBM system add 9 months. Round up to the nearest half-year. --Brad Sherman By the way, ALL software projects are done by iterative prototyping. Some companies call their prototypes "releases", that's all.
pete@wor-mein.UUCP (Pete Turner) (06/15/88)
In article <10941@agate.BERKELEY.EDU> csm@garnet.berkeley.edu writes: >You must have the following guarantees from the powers that be: > 1) Hardware and Software for the project will be delivered >to you on schedule or the project will be extended on a day >for day basis. If you are not responsible for procurement >and/or installation make sure that delays in this process are >documented and added linearly to expected delivery date. Has any engineer out there EVER been able to get "the powers that be" to sign up to slip a project schedule in this fashion? This sounds completely unrealistic to me, even if it does make sense. Pete
csm@garnet.berkeley.edu (06/17/88)
In article <1377@wor-mein.UUCP> pete@wor-mein.UUCP (Pete Turner) writes: >In article <10941@agate.BERKELEY.EDU> bks@ALFA.berkeley.edu writes: >>You must have the following guarantees from the powers that be: >> 1) Hardware and Software for the project will be delivered >>to you on schedule or the project will be extended on a day >>for day basis. If you are not responsible for procurement >>and/or installation make sure that delays in this process are >>documented and added linearly to expected delivery date. >>Brad >Has any engineer out there EVER been able to get "the powers that be" to >sign up to slip a project schedule in this fashion? >This sounds completely unrealistic to me, even if it does make sense. >Pete If you can point to a history of delivering good products on-time (it is possible), you can begin to make the rules. If you are in the position of setting schedules for project delivery, you have to decide whether to tell the people with the $$$ the truth or what they want to hear. I was predicating my statements on the former, although I admit the latter will get you more first-time business. One thing we should all learn about negotiations from the Reagan DoD budgets is that if you need 50 demand 150. Then howl like a banshee as you grudgingly settle for 133. --Brad Sherman
david@geac.UUCP (David Haynes) (06/18/88)
In article <917@blue.engin.umich.edu> conliffe@caen.engin.umich.edu (Darryl C. Conliffe) writes: >I would like suggestions and/or reports on how others accomplish >the following: having convinced management that an iterative >approach to a software design project is appropriate, how do you >report progress on same? One tool I have used from time-to-time is a system I call todo. When a pert chart has been made for the project, the tasks are then fired off to the appropriate personnel as todo items. The person receiving the todo item has the option of accepting, refusing or delegating the item. If the item is accepted, the acceptor places a personal priority on the item and the initiator of the message is notified. If the message is delegated, the new person has the option for accepting, refusing or delegating. However, since the todo item has been delegated, the originator is also notified of the delegation. Now, when an item is pending (or almost pending) the person who accepted the item is notified of its prescence. As the task is completed, the acceptor releases the todo item, which is date stamped and returned to the originator of the item. Tracking projects then becomes a much easier task. All this was implemented using unix mail and a special todo daemon. An enhancement I would like to add at some point would allow for percentage complete and problem tracking, but, it isn't what I get paid for, so it may take some time. -david- p.s. I also believe in prototyping and iterative design cycles, I am an empiricist (sp?) at heart. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- David Haynes Just another road Geac Computers International Inc. kill on the highway UUCP: uunet!mnetor!geac!david -or- david@geac.UUCP of life.
david@geac.UUCP (David Haynes) (06/19/88)
In article <1377@wor-mein.UUCP> pete@wor-mein.UUCP (Pete Turner) writes: >In article <10941@agate.BERKELEY.EDU> csm@garnet.berkeley.edu writes: >>You must have the following guarantees from the powers that be: >> 1) Hardware and Software for the project will be delivered >>to you on schedule or the project will be extended on a day >>for day basis. If you are not responsible for procurement >>and/or installation make sure that delays in this process are >>documented and added linearly to expected delivery date. > >Has any engineer out there EVER been able to get "the powers that be" to >sign up to slip a project schedule in this fashion? > >This sounds completely unrealistic to me, even if it does make sense. > > >Pete There is an old tried and true method for attaining the correct response (on your part) from the powers that be. It goes like this: M E M O R A N D U M To: Powers That Be From: Mindless Worker Lackie Drone Subject: Slippage in Schedule Dear PTB: Since we have not yet recieved our Frobotz 1200 which is required at this time to continue work according to the Project Plan dated 19th June, we are now faced with a potential slippage in the schedule provided at that date. #ifdef KNOW_WHEN_FROBOTZ_IS_DUE Since the Frobotz is now estimated to arrive in three weeks, please adjust the schedule provided in the Project Plan to reflect a new completion date of xxth May 19xx. We are currently looking at re-scheduling some less other work to fill in this unexpected gap in our planned schedule. #else Since we have received no word on when the Frobotz is to arrive, we appear to have two options on how to proceed: 1) If we can determine the date of expected arrival of the Frobotz 1200 we will attempt to re-schedule for its arrival and will inform you of the new scheduled completion date based upon this new information. 2) We can re-work the schedule to push the requirement for the Frobotz further down the schedule. We estimate that this rescheduling effort will take one month and involve a series of meetings with other managers in order to co-ordinate our new delivery schedules with thier personnel and resources. Naturally, we will automatically incur a slippage of one month for this re-planning effort. #endif In the first ifdef, you are practicing an ancient and honorable business tradition of covering your ass. You have informed management that a slippage is occuring and you have said you are trying your best, and you have made the manager both aware of the problem and responsible for its solution. In the second ifdef, you are making the manager make a choice -- what they get paid for. Either s/he has to find out the expected arrival date of the Frobotz *and* accept that the project will slip *or* s/he will have to fund a re-planning effort with the fact that the project is slipping being broadcast throughout the company as you have the "meetings with the managers of other departments". This is (potentially) of great embarassment to the PTB and is to be avoided at all costs. Notice that if the second plan is adopted, you get some time to determine what affect the non-arrival of the Frobotz will have on the project. This works for some managers -- others just refuse to make the decision. So what? You have done your corporate duty by pointing out the slippage and may now go back to trying to build the project. -david- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- David Haynes Just another road Geac Computers International Inc. kill on the highway UUCP: uunet!mnetor!geac!david -or- david@geac.UUCP of life.
cl@datlog.co.uk (Charles Lambert) (06/30/88)
In article <1378@wor-mein.UUCP> pete@wor-mein.UUCP (Pete Turner) writes: > >any suggestion that the schedule >must slip will be either ignored or thrown right back in the face of the >suggestee, > >The usual solution was to pressure all developers to work 80+ hour weeks at >no extra pay and then refuse to discuss comp time because the next project >schedule can't be slipped (hence their previousness). I think you've found the only answer to this (alarmingly widespread) kind of management machismo - make them previous! Only a high turnover of staff due to discontent and nervous breakdowns will eventually penetrate the skull of the corporate Gengis Khan. Tragically, there are too many eager young hawks who buy the lie that working 80+ hours without "grasping" for compensation shows you're "a professional"; what it really shows is that you're "cannon fodder". Fortunately, there are some employers who recognise their staff as valuable assets rather than recalcitrant pack-animals. Enough! I can feel my arms beginning to wave... Charlie