How to get what you want from software developers
The development of a software program begins by asking many questions. Applications as
dissimilar as games, in-house accounting systems, and e-commerce sites all have at
least one thing in common: a need to satisfy user needs and expectations. The time
during which the basic feature requirements of the software are defined is often called
the Discovery Period.
The major deliverable at the end of the Discovery Period is the Functional
Specification. It is the blueprint of the project and defines the project's scope.
Whether you are working with a third-party developer or an in-house development staff,
one thing is certain: if you don't carefully manage and referee the Discovery Period,
the Functional Specification will be off-target, dooming the project to be late and
It is the role of the project manager to pull the Discovery Period together. Although
the project manager isn't expected to know all of the answers, he or she is expected to
ask the correct questions or to put other people into the mix who can.
The major anxiety that plagues management during the Discovery Period is the sense that
nothing is going on. The Discovery Period is quite elusive and difficult to get a
handle on because it consists mainly of fact-finding. It seems like all talk and no
action. A developer who wishes to go off and work on his or her own may not regularly
report back on the thinking that takes place between discussions. No designs are likely
to be attempted and no programming undertaken until the Functional Specifications have
been approved. After several weeks of this, there is the nagging impression that the
Discovery Period is too long and that a project is already doomed to be delayed and
If you are serving as project manager you can combat these dangerous impressions by
instituting a few simple practices.
Hold regularly scheduled standing meetings to discuss all major features and
functions of the proposed software. The purpose of these meetings is for the client to
explain the requirements the software must meet and to make decisions limiting the
features to a reasonable set that can be completed within the allotted time frame.
Require certain members of the developer and client teams to participate. Make sure
there are decision-makers in these meetings so that something can get done. For a
six-month project, these meetings will typically take place two or three times a week
during a four- to six-week Discovery Period.
Create an agenda for the standing meetings so that participants know which
topics will be covered.
Prior to each standing meeting, and with the help of team members, develop a
preliminary list of feature requirements and assumptions that can be used for
discussion. You should also moderate the discussions to keep them focused and relevant
to the task at hand.
Do your homework. It is the job of the client organization to clearly define and
inform the developer of its needs. Every feature of the program will require some
homework on the part of the client. Make homework assignments at the conclusion of each
standing meeting and give deadlines. You will wrangle the answers to these assignments
by working with team members.
Arrange for smaller discussions between meetings with developer and client team
members on highly specific topics requiring additional detail.
Require the developer to report in writing on the results of each standing
meeting within 24 hours. This will confirm the decisions that were made.
Recommend a weekly meeting, at the developer's site if feasible, between the
most technically knowledgeable members of the client team and the developer's technical
team. The purpose is to provide access to members of the client team who have
information that will help the software engineers. This will undoubtedly result in more
homework, which is good. It will also make the developer's efforts more clearly visible
than they would otherwise be without these meetings.
The client should actively participate in drafting of the Functional
Specifications. This will take a little more time up front but result in a solid
specification that will have few surprises when it comes time to review the final
Publicize the results of these activities to management through emails, regular
status reports, and informal channels to assure them that the project is moving forward
at a healthy pace.
These are some of the simple techniques that a project manager can use to keep a
development effort on track in its early stages, even before one line of code has been