| < Day Day Up > |
|
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
|
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 > |
|