15.8 Example: SouthPointe Lessons Learned

< Day Day Up >

One of the key drivers for the SouthPointe project was to implement state-of-the-art technology in the new campus. The rationale behind this vision was to demonstrate how the newest generation of voice, video, and data communications and processing platforms could be rolled out and supported with off-the-shelf products, using in-house expertise. The intended benefit of deploying these tools was to make the workforce more mobile and productive by making data and applications globally accessible in a high performance, but secure, manner. These values became more compelling as a result of the World Trade Center disaster on September 11, 2001, which sadly occurred during the planning stage of the project.

Although we originally intended to deploy 16 technologies, by project's end, 3 were not deployed. We omitted the wireless local area network (LAN), thin client computing, and Internet Protocol (IP) desktop video conferencing. These deployments were deferred for the following reasons.

15.8.1 Wireless LAN

The current generation of this technology supported a throughput of 400 kilobytes per second, a bandwidth that compares quite unfavorably with campus-wide, 100-megabyte-per-second connectivity from data jacks to the switched gigE backbone.
Current technology was not considered adequately "hack proof," given the sensitivity of data routinely transmitted across the network.
Customer demand was not adequate to offset these potential product liabilities. We did complete the data-cabling infrastructure to prepare for future deployment of the technology. It still holds great promise in future iterations.

15.8.2 IP-Based Video Conferencing

The proof of concept process validated the utility of this product on a campus-wide basis; however, it was determined that the product presented interoperability challenges with existing desktop video conferencing products currently in use elsewhere, most notably with the critical function of call origination.
Because current users moving to the campus are high profile, it was deemed prudent to install compatible legacy systems for these known users at the new site and defer deployment of the IP-based product until such time that product maturity advancements make that more appropriate for universal deployment, and user demand reaches critical mass.

15.8.3 Thin Client Computing

Due to a variety of technical and product integration issues, the engineering team was unable to meet a twice-extended go/no go decision date on the rollout of the ambitious new distributed computing model intended to provide numerous user productivity and operational maintenance benefits.
Some targeted beneficiaries were disinclined to adapt the proprietary portion of their legacy environment, which included business critical applications, to the proposed new model. The key objection was a very limited prerollout test window due to their preexisting business schedule that could not be changed. The project had equally hard but incompatible dates, so there was no opportunity to mutually define agreeable milestone dates.

15.8.4 Analysis

Threads common to these postponed deliverables are instructive enough to merit a closer look. Whereas the potential benefits of each requirement were significant enablers of project goals, both of the following conditions contributed to the decisions, made independently for each deliverable, to postpone their deployments:

The project schedule could not accommodate the longer than anticipated timeframes required to resolve issues regarding product maturity or interoperability with legacy systems and processes.
User demand for each deliverable was lower than originally believed. This fact put in question the business value to be received in return for the continued, significant investment in each of the technologies as part of the SouthPointe project. This conclusion is particularly compelling because from an overall corporate perspective, the project was driven as much by real estate requirements as it was by the decision to implement technological innovation.

It is clear that beneficiary management should have been included in the planning conversations far earlier than was done to give them adequate time to evaluate the proposed products and make a commitment to support their implementation, or to request the products not be deployed on their behalf. Regarding the product maturity and fit issues, the project office could have benefited from a more proactive stance on pressing for a go/no go decision on each of the ultimately postponed deliverables.

Because each of the three technologies had relatively long development cycles, the project office elected to be patient with the process. In retrospect, the engineering team and project office, together, could have addressed feasibility of each deliverable within the context of overall project objectives and constraints sooner than was actually the case. Put simply, applying a triage-type approach to these technologies would likely have lead to quicker exclusions from scope of this particular project. This would have allowed the redirection of resource to other aspects of the project or back to the corporation for other pressing needs.

< Day Day Up >