Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Size of Workgroups

2 views
Skip to first unread message

Jeffrey Horn

unread,
Jul 8, 1992, 10:41:37 AM7/8/92
to
Suppose you were given the task of managing a software project. The project is
to write an inventory system. Inventory of what is irrelevant. There are
inventory numbers already in existance and you are to write a system which
keeps track of some attributes associated with each inventory number, where
the stock for that number is stored, and how much of it is on hand. The
inventory is at a central location and not widely distributed.

Assume that you have some powerful database system (ingres, oracle, sybase,
informix, etc.) and developement tools ( 4gls, compilers, debuggers,
desktop publishing, etc.). Assume also that you have 1 month to do the
project. You know nothing more, you will have to do interviews to get more
information on exactly what is needed. The project is to have complete
on-line and printed documentation. At the outset, how many analysts,
programmers, technical writers, managers, etc. would you put in charge of
a project like this. How would you break the work down and how much time
for each person would you allocate to each chunk.

Sorry if these are stupid questions. I am currently in the process of convincing
upper management that our computing group is understaffed, and I would like
data from outside my company about what quality software groups, whether in
software companies or other businesses, actually use to do quality work.

Any responses along these lines will be helpful!

Thanks,

Jeffrey Horn

David Wahl

unread,
Jul 8, 1992, 12:45:30 PM7/8/92
to
--
In article <1992Jul8.1...@schaefer.math.wisc.edu>,
ho...@schaefer.math.wisc.edu (Jeffrey Horn) writes:

|>Assume that you have some powerful database system (ingres, oracle, sybase,
|>informix, etc.) and developement tools ( 4gls, compilers, debuggers,
|>desktop publishing, etc.). Assume also that you have 1 month to do the
|>project. You know nothing more, you will have to do interviews to get more
|>information on exactly what is needed. The project is to have complete
|>on-line and printed documentation. At the outset, how many analysts,
|>programmers, technical writers, managers, etc. would you put in charge of
|>a project like this. How would you break the work down and how much time
|>for each person would you allocate to each chunk.

I think making the duration of the project only one month makes the scenario
unrealistic. The brief description of requirements coupled with the constraint
of finishing in 20 working days sounded to me like one programmer with a decent
database and 4GL could easily handle the job in a month, making analysts,
technical writers, managers and the rest just so much excess baggage.

On the other hand, if there is more to this you really can't do any kind of
estimate until there is a more precise description of the requirements (how
big, what kinds of reports, what kind of data entry, what platform(s), etc.).

Regards,
Dave Wahl
===================================================================
Digital Equipment Corporation
DIDDLY Development Team (CX02-1/7D)
301 Rockrimmon Blvd. S.
Colorado Springs, CO 80920-2080

Tel 719-548-2351
Email: wa...@hootus.enet.dec.com
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% The opinions expressed are my own, not Digital's. %
% "I suppose you would have to be very well educated to get that %
% kind of job." %
% "Extremely well educated. Typing, everything." %
% -- Donald Barthelme, "The Emerald" %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Scott L. McGregor

unread,
Jul 9, 1992, 2:31:39 PM7/9/92
to
In article <1992Jul8.1...@schaefer.math.wisc.edu>
ho...@schaefer.math.wisc.edu (Jeffrey Horn) writes:
> ... The project is
> to write an inventory system... Assume also that you have 1 month to do the

> project. You know nothing more, you will have to do interviews to get more
> information on exactly what is needed. The project is to have complete
> on-line and printed documentation.

> At the outset, how many analysts,
> programmers, technical writers, managers, etc. would you put in charge of
> a project like this. How would you break the work down and how much time
> for each person would you allocate to each chunk.

I would say that the right answer is one person, and that person does it all.
so no work breakdown, or management is necessary.

It would be especially good if the person you select is one of the users, this
reduces the amount of time necessary to do analysis and interviewing since the
user is likely to understand what is needed without much effort at those
things. Since you only have one month (on average 22 working days), cutting
down on the amount of interviews to do and analysis learning will be crucial,
moreover, you are also likely to reduce acceptance testing time too, since the
user will recognize whether it solves their problem or not faster--probably
even in development. You'll also want the user to write the documentation too,
since the amount of time it would take to convey all the necessary information
to a technical writer with no background in the problem area would probably
consume the whole month.

With such a short deadline, you are in danger of not getting a good result, and
theres not much you can do to accelerate it because no possible reduction in
staffing or learning is possible.

In general, communications between people add substantially to a project's
duration, so when you need to complete something quickly it is important to
keep the staffing down. A good rule of thumb I've noted is that you should not
put more people on a project than the sum of the *calendar* months. So, a one
month calendar project can only be a one worker-month project. But a one year
calendar project can actually handle a twelve worker-year staffing level, which
can include coverage for a tech writer, manager, analyst, and several
programmers.

> I am currently in the process of convincing
> upper management that our computing group is understaffed, and I would like
> data from outside my company about what quality software groups, whether in
> software companies or other businesses, actually use to do quality work.
>
> Any responses along these lines will be helpful!

I don't know if one month projects are really typical for you, if so, I am
afraid the above argues against your position. On the other hand, if you
really do mainly one-two YEAR programs, there is evidence that you COULD
support a heavier loading, but there's no NEED to do so from a management
perspective--such loading would be dependent upon the particualar project and
skills of the people working on it.

However, I have noted that many MIS organizations and development groups do
often seem overworked. But this is not merely due to understaffing, but also
due to underestimating the amount of work to be done. This often happens
because they apply gross estimates of work durations without checks. For
example, recently I've seen a situation, it basically went like this:

A: We want you to write a new version of this reference manual for the new
version of the product. The manual should take 6 man weeks to write.

B: Six weeks is 240 hours. There are 1200 pages in the existing reference
manual. That is 5 pages/hour, not counting overhead for company meetings,
reading company mail, etc. That's not just writing 5 pages in an hour, but
also editing them, having them reviewed, making the changes, checking them
again. At roughly 500 words per page, thats 2500 words/hour or roughly 41 words
per minute, or one about one character every 1 1/2 seconds. Fourty words per
minute is a decent typing speed alone, but researching and composition should
take some time too, don't you think?

A: But the existing manual already exists, you don't need to rewrite every
word. Or even retype it.

B: That's true, but is the current manual correct? We both know it is not,
some of the work to do is to correct things that already are wrong. And there
are the new changes to consider, how do they obsolete the old manual?
Even if you leave off the typing, do you only want to spend 12/minutes per page
verifying correctness? Or look at it this way: There are 600 functions,
messages, and types in the manual. Do you want to spend less than 1/2 hour
perfunction to verify each existing one is correct, fix ones that are not, and
add all the new ones.

A: I see, what you are saying is that while the user manual took 6 weeks, the
reference manual has to take more because it is bigger and more complex.
If we assume that we should spend about two hours per page for
/research/writing/verification and everything, and that other tasks take up 50%
of a workers time, then this project is really:

2 work hrs/page * 2 elapsed hours/work hour * 1200 pages = 4800 elapsed hours,

Wow, divided by 40 hours / week thats still 120 elapsed hours. That's too
long. How are we ever going to get it done in 6 weeks?

B: It would seem you would need to have 20 people working on it.

A: But we don't have 20 people to spare.

B: Then you must compromise on the quality of checking and time to write, or
you must change the delivery date. Or cover less in the manual. You should
have thought about what the implications of so many functions meant in terms of
test and documentation time originally.

Scott McGregor

Hor Shoon Chan (Mr)

unread,
Jul 9, 1992, 8:59:33 PM7/9/92
to
In article <54...@athertn.Atherton.COM> mcgr...@netcom.com writes:
>In article <1992Jul8.1...@schaefer.math.wisc.edu>
>ho...@schaefer.math.wisc.edu (Jeffrey Horn) writes:
>> ... The project is
>> to write an inventory system... Assume also that you have 1 month to do the
>> project. You know nothing more, you will have to do interviews to get more
>> information on exactly what is needed. The project is to have complete
>> on-line and printed documentation.
>
> (stuff deleted)


Unfortunately, documentation is usually neglected in most software
projects. If the project can move along, who cares about the
documentation. Managements' support and attitude toward documentation
(in most cases) really doesn't help either. Many see documentation
as a by-product of the software development, not part-and parcel of
the final product.

It is no surprise that software documentation has been labelled the
armpit of the software industry.

Hor Shoon Chan, National University of S'pore

0 new messages