My Approach to Projects

This section describes how I approach projects. I'll use my most exciting accomplishment, a Downloadable Fix application I designed for TriZetto as an example. In order to protect the proprietary information on the site, I'm using samples from different sources.

Step 1: What do we have?
The first step is to review existing data and web information to see what we have to work with. In the case of the Downloadable Fix Application, we had html pages that I manually copied each week, from an Intranet web site to the Customer Service site. I manually formatted each line in the report so it was easy to read by customers. We also had fix files that were being burned to CDs by Technical Support and mailed to customers. An individual had a report that was two feet wide and three feet high describing the objects that were contained in each fix. He requested we make this information available to customers. The report, in itself, wasn't suitable for the web.

» Sample New Process (another project)

Step 2: What's the best web solution?
The answer was to combine all of the fix information into an automated web site that would be user friendly. It needed to provide customers with all of the information they needed in one location on the web. I reviewed the information and realized the original report I was manually copying should be a data feed from it's original application. To view the objects within a fix, customers should be able to click on the first column- the fix number. From there the customer could click again and see all the previous fixes that contained the same object (this concept was added later based on feedback from one of the VPs, in a review). This would help them ensure they were updating their systems with the right sequence of fixes. The last column would have a link to download the fix executable file, so the customer wouldn't have to wait for a CD, and Technical Support could focus on more meaningful tasks. They considered this job to be the worst assignment of all, and used it to break in new people.

» Demo of Downloadable Fixes

Step 3: Create an HTML mock-up to sell the idea.
I created an HTML mock-up with links to possible data feeds, first I reviewed it with the head of Product Development (my second level at the time). He was thrilled. Next I took the demo to the team who packaged fixes, and Technical Support. Both departments took ownership immediately, and the project was in motion.

Step 4: Get the data into a single source.
The data originally resided in three separate locations: an Access database (fix descriptions), a ship directory on a server (fix files), and a Sybase database (content of the fix- object names). We wanted all CSO data to be in a secure SQL database for public access. Moving the fix files and object data was no problem. We simply created a new database for fixes and copied the descriptions into SQL, and started housing fix files on the web server. The challenge came with the Access fix descriptions. In discussing this with QA, we realized script could be run to create XML and import the data into SQL. An individual in QA wrote the original script, I took over and re-wrote it as we moved forward with new releases and requirements.

Step 5: Make the data compatible for the web display.
Each department numbered releases differently. At this time, I created a data mapping diagram and determined data types, and definitions for each field. I used VBScript to add in periods to packaging object data and take them out of the QA data:

     If mid(release,2,1)="." then
          finalrelease=left(release,1) + mid(release,3,2) + right(release,2)
     End If

- allowing compatibility from a relational database where applicable.

» Sample of a Data Mapping Diagram (another project)

I define field names, data types, and defintions for each table as follows:

Field Name	Data Type & Size	Definition
id	int 4	auto-generated number
release	varchar 25	4.01.01

Step 6: Approval from Senior Management.
As a team, we took our final product to meetings with the VPs. The VPs were really pleased and we were almost ready for release. They had a few new requirements to add.

Step 7: Test for usability.
The final step was to go to my co-workers and have them test the site for usability. To do this, I stood behind a few people without saying anything and watched as they figured out what to do. This experience allowed me to clarify instructions on the site pages for the customers.

Step 8: Final documentation.
I pulled together the former business process, the new automated process, data mapping, definitions, a copy of the XML, script to create and insert XML data into SQL, and procedures for the site. It also included business rules that dictated constraints on our design. An example of a business rule was to create a six day delay before the general customer base could download a fix. This allowed for the need to make changes to the fixes if any problems were identified. I coded the pages to read the original date and if the current date was < 6 days the download would appear as, "Not Available."

Conclusion
From the original design, I added a help pop-up display for customers, impact statements that displayed in a printable format, and eventually limited access to customers who purchased an extended maintenance agreement instead of upgrading to our latest version of Facets. You can see more success stories on my resume.

» Resume