3.11 Commence Validation Processes and Adjust as Required

 < Day Day Up > 



3.11 Commence Validation Processes and Adjust as Required

Exhibit 10 presents an appropriate validation procedure.

Exhibit 10: Technology Validation Process

start example

Validation Step

Rationale

Proof of concept (alpha test)

In laboratory environment, validate functionality and that components work together acceptably.

Stress test

Simulate production load via scripting, "packet flooding," or other relevant techniques.

UAT

Turn test environment over to beneficiary for testing. This is a dress rehearsal, and should be run in the production environment with adequate safeguards, or in isolation if testing in production is not feasible.

end example

The key thing to remember is you want to get into the production environment well in advance of cutover or rollout time, so you can discover and react to any problems that may crop up. In the previous load-balancing example, the incompatibility of the legacy load-balancing software with the new network switching was not anticipated. Because the user acceptance testing (UAT) ended up running late, we had very little time to react once the issue surfaced.

When planning this validation process, you need to look for potential failure points and have a remedy scheme prepared to the extent possible. If we revisit the load-balancing scheme one more time from this perspective, load balancing should have been identified as a test item. How? It should have been quite simple. During the test planning meetings, several documents, as presented in Exhibit 11, should be reviewed.

Exhibit 11: Test Plan Document Review

start example

Document

Contents

System architecture drawing

Shows hardware and software components and inter-connectivity.

System architecture description

Describes applications, tools, and services, and how they interact.

Draft runbook

Required for operations turnover. Indicates how services and application are started and stopped, how users log in, user functionality, backup and disaster recovery schema, and other connections (e.g., File Transfer Protocol [FTP]).

end example

A diagram, such as the one displayed in Exhibit 12 detailing system architecture, would clearly have identified load balancing, as would system documentation that lists each hardware component and identifies applications or services running on each platform.

Exhibit 12: Network Load-Balancing Configuration

start example

click to expand

end example

A draft runbook, which is normally required by operations, would also have flagged load balancing as a piece of system architecture requiring specific configuration, as well as an escalation list for support in the event of an outage. [4]

Again, as project manager it is not your job to write detailed test plans or come up with clever solutions to tricky problems. It is your job, however, to insist that such work is done. The best way to ensure compliance is to schedule meetings to review the plans. Network and operations personnel should be present in addition to implementers, software developers, etc. The intent is to focus the right eyes on the technology game plan so that any gaps or potential points of failure can be identified and resolved.

The last action item in this piece of the project is addressing risk, performance issues, or unfulfilled requirements. You can also expect that, once the user gets involved, new requirements will mysteriously arise. Although you may or may not know why new demands come to light at this stage of the game:

  • It could be the fault of the analysts who developed your requirements.

  • End users might have done a poor job of articulating their needs.

  • A new requirement may spring from a recent change in the business environment.

Hopefully, you can see why this process should be agreed to and scheduled well in advance of any production dates. Also, you should consider planning this in phases. In other words, have a first UAT in June, a follow-up in July, and so forth even though production turnup is not scheduled until October. You know things take time to get ironed out, so be realistic, and be sure your plan reflects that reality.

[4]See Chapter 11 for details on runbooks.



 < Day Day Up > 



Complex IT project management(c) 16 steps to success
Complex IT Project Management: 16 Steps to Success
ISBN: 0849319323
EAN: 2147483647
Year: 2004
Pages: 231
Authors: Peter Schulte

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net