Software Development Project Management Guidelines

These guidelines are intended to combat the typical issues that arise in software development projects.

1. Identify a project point person: The Project Manager should identify a point person, preferably the project sponsor or a representative from that group. The project point person must agree before work begins that s/he will be available for the duration of the project to attend meetings, answer questions and review work, often with quick turnaround times in order to meet deadlines. The project point person needs to have decision-making authority on the project, including approval of budgets and check requests. If the project point person does not fulfill this obligation, this should be documented by the Project Manager as early as possible in the project, and a new project point person should be identified or the project put on hold.
2. Generate a specific requirements list: For each project, a clear set of requirements should be generated that can be translated into specific actionable items for the developer to work from. Often, it is the Project Manager’s job to generate these requirements and get approval of them by project sponsors. This list should consider required deadlines, design, functionality, nonfunctional requirements, delivery mechanisms and formats, and compatibility with other systems.
3. Scope out the developer’s work assignment before work begins: Based on the requirements, write a scope of work for the developer that presents a straightforward plan for achieving the requirements within the specified timeframe. The scope of work should include a pre-approved number of design iterations that the developer is expected to present. This document should be approved by project sponsors and should be the basis for any agreements with contractors, budget considerations, level-of-effort estimates and future change requests.
4. Set a definite start and end date for the project: Based on the scope of work and any LOE estimates generated from it, establish the anticipated start date and end date for the project. The end date takes into account the budgeted number of full-time days for development. The end date should be immovable; requirements should be changed to accommodate the end date, not the other way around. While working with the developer, check in and request submissions of completed work daily to ensure the developer stays on track.
5. Institute and enforce a change request process: During the development time, any new feature requests or changes to the pre-approved requirements list, including design changes, should be submitted as change requests. The change request should result in a change to the scope of work to ensure that the project can still be completed in the allotted timeframe; for example, a lower priority feature may be dropped or postponed in favor of a new request. Change requests that cannot be accommodated should be placed on the requirements list for the next iteration.
6. Each iteration should be treated as a new project: Once the end date arrives and the scope of work is completed for the project, a new requirements list should be generated, resulting in a second scope of work and end date set for the subsequent iteration. It should not be assumed that the same developer will complete subsequent iterations. It should not be assumed that the developer will be “on call” to make minor changes once the project has ended. All agreements of this sort need to be formally scoped, documented and agreed to by all parties before any subsequent work begins.