B.4. Executing the Infrastructure Development Project
These tools are the responsibility of the Project Manager and are used for two major purposes: to keep the project moving along on schedule and to manage exceptions and issues. They are also excellent means of communication with the extended project team and the company at large.
B.4.1. Project Plan
The project plan reflects the individual activities (all these individual activities form what is called a work breakdown structure) that must be accomplished, when each activity is due, and when each is actually completed.
It may seem out of order to predetermine the length of any project before a project plan has been put together. You're right; it is premature to make a total commitment before this step has been taken. Setting up a target project length can now be used to impact the scope and resource requirements of the project, or the time line can be expanded based on these estimates. These changes should be reflected in an updated project charter and broadly communicated.
A word of caution: Be very wary of tackling a project that goes much beyond six or eight months. The risk of failure increases exponentially based on length of project. The project plan template is shown in Table B-8.
| Project Plan | |||||||
|---|---|---|---|---|---|---|---|
| Project Name: | Revision # | ||||||
| Planned Start: | Actual Start: | ||||||
| Task# | Priority | MilestoneTask | Assigned to | Est. hours | Due | Done | Comments |
| 1 | Analysis | ||||||
| 2 | Design | ||||||
| 3 | Construction | ||||||
| 3.1 | Build | ||||||
| 3.2 | Unit Test | ||||||
| 3.3 | System Test | ||||||
| 3.4 | User Test | ||||||
| 4 | Implementation | ||||||
| Assumed Resource Availability | |||||||
| Team Member | Role | Percentage of Time | Comments | ||||
| Project Manager | 100 | ||||||
| Analyst | |||||||
Note that the time line is based on planned and specified resource availability. Deviations from the assumptions will always have an impact on the project duration.
B.4.2. Weekly Status Report
The weekly status report is the primary means of communicating the current status of the project and for bringing issues to the attention of the project's executive sponsors and managers. Keep the status report as short as possible, but always make it clear. Highlight the weekly status and summarize the explanation at the top of every weekly report, as illustrated in Table B-9. This might be all that many people read!
| Weekly Status Report | |||||||
|---|---|---|---|---|---|---|---|
| Project Name: | Week Ending: | ||||||
| Status Key: Green = On-track Yellow = Caution Red = Critical | |||||||
| Status: (use color) Green/Yellow/Red | Explanation: | ||||||
| Task | Milestone | Responsible | Scheduled | Completed | Comments | ||
| (1) | (match project milestones) | ||||||
| (2) | |||||||
| (3) | |||||||
| (4) | |||||||
| (5) | |||||||
| (6) | |||||||
| Unplanned Activities | Responsible | Scheduled | Completed | Comments | |||
| Accomplishment(s) This Week | Responsible | Scheduled | Completed | Comments | |||
| Objective(s) Next Week | Owner | Due | Comments | ||||
| New This Week | |||||||
| Issue/chng | Item | Reported by | Description | Comments | |||
| Iss | |||||||
| chg | |||||||
| Open Issues List | |||||||
| Issue Item | Description | Status/Resolution | Date Resolved | ||||
This document should be prepared with a high-level perspective and the business and end-user community in mind. Technical details are best dealt with in more detail on a change or issue request and analysis document and the change or issue log.
B.4.3. Issue Log
The Issue Log, shown in Table B-10, is a list of all of the situations and roadblocks that unexpectedly arise to derail your project.
| ISSUE LOG | ||||||||
|---|---|---|---|---|---|---|---|---|
| Project Name: | Date: | |||||||
| Issue ID | Category Information Process Technology, People | Severity Critical, Serious, Medium, Low | Description | Reported by | Report Date | Owner | Resolution/Plan for Resolution | Close Date |
| 1 | ||||||||
| 2 | ||||||||
The owner, resolution/plan, and close date track how the resolution was resolved. Open issues should be kept visible until they have been resolved. Often issues cannot be resolved by the project team and must be referred to the program team or sponsor.
B.4.4. Change Log
The Change Request Log summarizes every request for a change to the agreed-upon scope of the project, much like a construction change order, as shown in Table B-11.
| CHANGE REQUEST LOG | ||||||||
|---|---|---|---|---|---|---|---|---|
| Project Name: | Date: | |||||||
| Change ID | Priority Critical, Serious, Medium, Low | Request By | Request Date | Description | Assign to | Assign Date | Status (open, in progress, closed) | Close Date |
| 1 | ||||||||
| 2 | ||||||||
If the change increases scope, either resources must be added or the schedule must be lengthened.