This article is an extract of the Software R&D Best Practices training, it presents how the project manager should handle a software solution project planning and rollout.
Project planning
The project planning preparation is divided in 3 sub-projects.
- Plan the pre-study phase.
- Plan the project from study to delivery
- Plan the maintenance phase
The pre-study phase must be planned itself in an autonomous way because the project may finish if there’s no agreement on the scope, duration, cost and quality are found between the provider and the customer.
The maintenance phase is planned after the customer accepetance meeting (ie the final payment but eventually the warranty). It’s a recurrent activity phase with mini-projects to be planned on a continuous flow basis up to the maintenance phase end that depends on product life time (or contract guarantee) duration and scope
The remaining project phases, from study to delivery will be planned during the pre-study and finalized at it’s end because without a completed and validated solution requirements document, the project manager does not have enough stable information to produce a realistic project plan.
Project planning steps
The project planning can be done with following steps:
- Define project work breakdown
- Estimate project tasks workload
- Assign resources to tasks : check/ask for resources availability
- Identify project risks
- Determine project risks & events buffer
- Determine project milestones
- Iterate on scope, milestones, cost and quality with customer, manager, team and quality assurance officer
These steps should be done in the proposed order in a Gantt chart like this one:
Project workload estimation
The project workload estimation (cost and duration) should be based on implementation workload (development, integration, unit tests and software documentation writing) done in the build phase.
The study workload, test workload (including test preparation, test runs and issues fixes), delivery workload and project management workloads are deduced from the implementation workload.
The implementation workload is deduced from solution requirements document (contains use cases, logical architecture, integration flows, business rules, software documentation to be delivered and other non business requirements)
The development workload can be estimated with an in-house method or standard method like Functional Points or COCOMO.
An estimation table about how to spread the total workload from the implementation workload in the build phase is provided in the Software R&D Best Practices training.