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 over-budget.
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 costly.
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 draft.
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 written.