Complex IT Project Management: 16 Steps to Success
|
| < Day Day Up > |
|
3.4 How to Determine If it is Going to Work
Having a sixth sense about such things would be great, but prescience is in short supply in this world. On the plus side, you can and must take a couple of steps to ensure that the technologists have a sound game plan. These steps are listed in Exhibit 5.
Exhibit 5: Vetting the Technology Plan
|
3.4.1 Listing Target State Elements
As the design emerges from scope analysis and the requirements definition processes, you must generate and maintain a target state document. It should list each major deliverable and, at least, the key requirements of each deliverable. You should not get too detailed; I prefer simplicity. Your target state chart is not intended to replace in-depth design documentation, but should be similar to a project billboard you use to keep people focused on the main goals. Take a moment to review Exhibit 6, which is a diluted version of one we created for a project during which we installed many technologies in a new building before moving in thousands of users.
Exhibit 6: Sample Target State Chart
| Deliverable | Description/Functionality |
|---|---|
| Telephony | IP Telephone |
| Applications | Desktop build v. 2.9, both "fat" and "thin" |
| Home and shared directories | Storage area network (SAN) |
| Application backup/archive | Daily backup of SAN using robotic tape unit |
| Disaster recovery | Data replicated to off-site SAN |
| LAN printing | IP-based, multiple LAN printers per floor |
| Video conferencing | IP-based, to the desktop |
| Mainframe printing | Print jobs rerouted to IP-LAN printers |
| Mainframe access | Client emulation via off-site gateways |
| Wireless LAN | Available Day Two[a] |
|
[a]Day Two designates any deliverable that may be delayed. | |
|
| < Day Day Up > |
|