15.2. Controlling the Project
The purpose of project management is to ensure that the project stays on track and delivers the intended result. The project manager plays the key role in this activity. This individual will be responsible for tracking, overseeing, and communicating each step in the infrastructure development phase. As always, communication is a key responsibility of the project manager: communicating actual status, and identifying and escalating issues or changes that occur during any of the four development steps.
15.2.1. The Steps of an IT Development Project
The steps of every IT development project include gathering requirements, analysis and design, and construction (build and test). As we saw in Chapters 11 through 14, most of the work on developing each component falls to the IT team. But the level of responsibility varies by both component and project stage. This necessitates clear communication and understanding on the part of the whole team, especially during the handoff steps we identified for each component.
Requirements: Generally, an IT analyst works closely with the business team members to develop a clear understanding of what is needed from the business point of view.
Analysis and Design: The analyst compiles and translates these specifications for the IT designer. Next the IT designer works with the analysis document to create documents (design specs) that specify exactly what needs to be constructed during the development step. During design, the business members of the team generally clarify requirements and resolve contradictions.
Construction: An IT programmer works with the design document to build the data structures, code, and technical platform. The critical involvement of the business team comes at the end of this step when the system and its components need to be tested to ensure that they really do what the business team needs.
Every infrastructure development project must include these steps. It is not a requirement that different individuals from IT perform different steps. Small organizations are unlikely to staff all these specialized resources. However, the skill sets required are very different from step to step. Many projects fail when a programmer tries to do business analysis (and vice versa, of course). Be sure you have access to all the different skills you need for the project.
15.2.2. Project Management Tools
In addition to the project charter document that is created during project launch, the project manager will use four more documents to track the project and communicate the current situation to the project team, program team, and sponsor.
Project Plan
The project plan is an actual schedule for what needs to be done and when it is expected to be finished. There are some very sophisticated tools available that automate time-line development and resource management. These tools, such as Microsoft Project, are detailed and very complete. They can also track task dependencies (a task that cannot start until another is finished) and resource constraints that have significant impact on the project schedule. For very complex projects with lots of resources and lots of dependencies, an automated tool can be a tremendous timesaver. For smaller, less-complicated projects, it is perfectly fine to use a spreadsheet like the one shown in Table 15-2.
| Project Plan | |||||||
|---|---|---|---|---|---|---|---|
| Project Name: | Revision # | ||||||
| Planned Start: | Actual Start: | ||||||
| Task# | Priority | Milestone Task | 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 | Implement | ||||||
| Assumed Resource Availability | |||||||
| Team Member | Role | Percentage of Time | Comments | ||||
| Joe | Project Manager | 100 | |||||
| Susan | Analyst | 60 | |||||
The project plan helps set realistic objectives about when the project can be completed given current resources. It is also valuable for tracking the addition of new requirements and testing how they will impact the overall schedule. An actual project plan will contain a much lower level of detail about the work that needs to be done. Each major task should be broken down into steps that take only a few days. Otherwise, it is impossible to estimate resource requirements with any accuracy.
Weekly Status Report
The weekly status report is a critical document, and I do recommend that you complete it weekly! Remember, we are doing small projects; a weekly report keeps the team focused on progress being made and highlights issues so they can be addressed quickly. A monthly status report for a six-month project leaves too much time for things to get off-course between checkpoints. Table 15-3 shows a sample template for the weekly status report.
| 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 | ||||
Communication is the key purpose of the status report; that means they must be read. Keeping the document to a length of no more than one page should ensure that everyone has time to at least glance over it. Put a colored Status Flag and brief summary at the top of the report so that with a quick glance everyone should at least know how the project is doing. (This works best if the “flag” is the name of the color for those who print in black and white.)
Issues (or project changes) that are identified over the course of the week are listed under “New This Week” and are added to the Issue Log or Change Log as well. A running list is kept of all open issues. Unresolved issues have significant potential for derailing the project, so it's best to keep open issues in front of everyone at all times.
Issue Log
The issue log is where the project manager tracks problems that arise. These are problems that if not addressed will threaten the success of the overall project. An example of the format for an Issue Log is shown in Table 15-4.
| 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 issue log is another important document for the project manager. It makes clear how many potential roadblocks have been encountered and information that might prove useful if the issues cause the project schedule to slip. In addition, the project log can be used as part of the overall development project review. If too many unexpected issues arise, there may be some basic problem with the company's readiness for, or basic approach to, CRM. In addition to keeping track of what the problems are, the project manager tracks information about assignment and resolution.
Change Log
The change log is the third important tool for managing the project. It is where any changes to the original scope are tracked. Obviously, this document is critical: It is just like a construction change order. If the change request is approved and will impact schedule, cost, or scope, the project will take more time, cost more, or change in scope. It's important that changes are well understood and widely communicated so expectations are kept in synch with plans. A sample change request log is shown in Table 15-5.
| 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 | ||||||||
The change request log tracks requests for additions or deletions to the project. Once approved, a change will be assigned to a project resource (and the project schedule and other project documents will be modified to reflect that the change has been approved). The estimated completion time is added to (or subtracted from) the schedule. When a change is completed or cancelled, it is marked closed.
Beyond the Project Team
The preceding project management documents are primarily aimed at those who are closely connected to the project on a daily basis – the project team. But we know there are lots of other individuals who have a strong need to know what's going on with the project. These include but aren't limited to the company's executive staff, project sponsor, steering committee members, and future users and their management.
When should these reports go out? They should go out as often as necessary. That's correct; there is no one right answer. How frequently they should be distributed depends on who the audience is (very hands-on or largely arms-length) and how the project is doing, as explained in Table 15-6.
| Management Style | Status | ||
|---|---|---|---|
| Green | Yellow | Red | |
| Hands-on style | Biweekly | Weekly | Daily |
| Arms-length style | Monthly | Biweekly | Weekly |
What should be said? The content depends largely on how often the information is being distributed (which, of course, depends on management style and status). The minimum content is the project status and status summary (first four lines of Table 15-3); the maximum content is to send everything to the extended team that is sent to the project team (at least in a summary form), as shown in Table 15-7.
| Management Style | Frequency | |||
|---|---|---|---|---|
| Monthly | Biweekly | Weekly | Daily | |
| All management styles | Everything (with a summary) | Full status report | Status, status summary | Status update and brief summary |
Frequency is important to this decision because the bare minimum information may not be enough if it's distributed only monthly and the full detail is way too much for a daily distribution.
How should the message be communicated? Again, know your audience. Who learns by reading, by hearing, by doing? Many companies have a fairly consistent culture around communication and learning, everything in writing or always by voice mail. If your company has just one preferred style, then you are probably safe picking just that one. But if your company has no such learning culture, or you want to be extra sure of communicating with certain critical extended team members, you might want to have a version for all the learning styles. The guidelines for how to choose the communication method that best supports each learning style are given in Table 15-8.
| Management Style | Learning Style | ||
|---|---|---|---|
| Reading | Hearing | Doing | |
| All management styles | E-mail, hard-copy report | Voice mail, face to face, status meetings | Demos, requests for barrier removal |
A word of caution: Some media are appropriate only for short messages. Ten-minute voice-mail messages are not a good thing.
Finally, you can never get it perfect. Always make it easy for people to get additional information and detail. The best way is to keep everything on an internal project web site that is well organized and well publicized. This is the backstop for all your communication plans.