After establishing sound requirements, as described in Part 4, utilize each requirement as part of your work breakdown structure (WBS). A WBS essentially breaks down each requirement, or deliverable, into easier-to-manage components in which enables the project manager to develop a schedule and budget for each piece. With a complete WBS, the project team can begin to determine the order in which each requirement must be developed, allowing a schedule to take shape. Sprints and milestones will need to be established to determine delivery dates in which source code will be delivered with increased functionality each step of the way.

After the sprint schedule is completed and approved by the project’s development team, the project manager can begin to allocate resources. This is determined by how many man hours are needed for each portion of development and therefore, the sprints they comprise.

With sprints defined, it is time to estimate the cost to complete the project. There are many methods to provide an estimate to the product sponsor; however, it is critical to estimate appropriately, ensuring there are sufficient funds built into the budget.

Begin by providing each engineer with all the information necessary to create an estimate of time needed to complete each sprint. Each engineer will be responsible for individually estimating each work item in the project without input from the rest of the team. After each estimate is complete, convene a meeting to review the individual estimates. There are various methods to utilize from here; however, the most common method is taking the average of each work item from each individual from the group. These work item averages are then summed for an overall project budget. If anyone in the group is opposed to the amount for an individual work item, allow the individual to present their opinion. If the majority of the group is persuaded to change the work item estimate, so be it.

Once the estimate is finalized, it is the project manager’s responsibility to keep all product stakeholders apprised of the project’s status. The WBS can be converted into various burndown charts to keep the development apprised of progress and make sure the project manager has visibility to all portions of the system under development. Burndown charts are not the best way to keep non-engineering stakeholders up-to-date; however, the use of status reports keep everyone connected. Status reporting proves valuable in showing the amount of billable time spent on a project and resources utilized.

A sound status report will report time spent on the project, broken down into subsections, for example: meetings, documentation, research, development, testing, and project management.

Each status report should briefly describe what was accomplished since the previous status report, listing all activities from the week. Additional components of the status report should include planned activities for the following week, as well as any comments and test results. Finally, address any open issues that continue to linger and present any questions that came up during development which could slow progress, if not addressed by project stakeholders.

 

With scheduling and organizational best practices,
project schedules, scope, and budget should remain on target.