[GNU-COBOL] Project Management

["Glen Colbert" <gcolbert@uswest.net>]

I received a lot of very positive and interested replies to a couple of
postings that I made earlier today.  These replies have given me reason to
pause and consider how this project is being managed/implemented.

I remember working in a shop several years ago that had a cartoon on the
wall which related to problems that we were experiencing in support of a
major credit card company.  The cartoon was of a programming team leader
telling the programmers to start writing code while he went upstairs and
found out what management wanted the code to do.  My comments here are not
intended as criticism to anyone, merely to point out that one of the real
world problems in our industry in general is our tendency as technically
oriented people to solve problems before they are clearly understood and
described.

It seems that most of the people involved with this project are students.
As a person with a lot of experience in this field, I want to point out to
each and every one of you that there is a more significant opportunity here
for you than just the development and implementation of a tool that (I
believe) is desperately needed.  This is, possibly, the best chance that you
will have for the next five to ten years to experience project management
and control.  While it may be difficult to believe, project management is as
important a skill as the ability to solve and implement technical solutions.
I can attest that project management skills will be one of the first things
that you will need to demonstrate before being promoted to a senior analyst
position.  Participating in the project management of this project will look
MUCH better to future employers than writing libraries or defining grammars.

I would propose that, for the short term, we all put our technical hats away
and work toward helping Laura clearly define the scope and objectives of the
GNU Cobol project.  With a clear scope and set of objectives, we can write
specifications for the project.  Philosophical and design arguments which
WILL arise through the development need to be made against the
specifications (as opposed to against each other's personalities).  Projects
of this size generally require the development of both functional and
technical specifications.  The functional specifications should include
issues of usage and implementation (how a program is compiled, porting
specifications, tools used, etc.)  The technical specifications outline how
different modules interact with each other and with the OS.  These
specifications need to be to the detail of the grammar.  If we can come up
with a good collaborative approach to defining the specifications for the
compiler, the specifications should also provide the bulk of the information
that is required for product documentation (only formatting changes should
be needed).

It seems to me that we are trying to write functional specifications and
code before we have clearly designed the scope and objectives (don't take
this personally).  We need to all clearly agree on what we are trying to
accomplish before spending a lot of effort that may be criticized and
discarded.  It is much easier to write it right the first time.  (Chad
quoted someone named Brooks who said that you need to plan on writing it
twice.  In the real world, nobody will pay for doing it twice.  Instead,
they implement crappy systems that we all make a lot of money supporting
later on).  It can be done right the first time.  I've seen it.  The
critical factor is in investing in the design before coding to the code.

I believe that, to succeed, we must desperately avoid the urge to start
coding while Laura goes upstairs to figure out what we are supposed to be
doing.

At the very least, we need to treat this as a small project and define clear
and measurable milestones and dependencies.  This could be in the form of a
gannt chart on the home page.

I am more than willing to help in this planning effort.  I would be pleased
to participate as a facilitator to the project planning 'team.'  I think,
however, that this is a valuable experience for any student on the
development team and should not be passed up.  This is your first - best
chance for promotion.  I would encourage you to not pass it up.

Glen


--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to gnu-cobol@acm.cs.umr.edu with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@acm.cs.umr.edu.