Technical Brief | Exploring Web Marketing and Project Management

A programming plan is an internal document used by the project team, based upon the described functionality in the project specification. One might not wish to confuse the client with highly detailed references to database middleware in the project specification, but these facts are important to all of the programmers working on the Web site. A programming plan can be drafted as an internal tool to fill the gaps between the project specification, which must be signed off and understood by the client, and the information necessary to convey to the programmers. For example, it may be necessary that the ASP programmers not use cookies to facilitate the operation of an online store because of incompatibility with earlier forms of Netscape browsers. The client needs to know that the Web site will be cross-platform; however, discussion of "cookies" may mean nothing to them besides confusion.

On another front, the programming plan is important because if any of the work has been subcontracted and does not meet the requirements, this is the document to which the contracting Web firm can refer, should the subcontractor be called upon to make corrections.

A testing plan is a formalized document that discusses the testing of the functionality of the Web site. People testing a Web site are charged with two objectives:

Try to break it by using unexpected input, making sure that all error messages work as they should.
Make sure that the site functions as expected.

So, when testing a search page that has the ability to search on several different parameters or only one, using an AND, LIKE, or OR criteria, some test criteria may be to test using numbers or the first letter of a matching word. It's best to use people who have not worked on the site and have very little knowledge of the way it is "supposed" to work. Otherwise, it's very easy to overlook problems due to a programmer's bias. It is similar to a writer trying to edit his or her own work. One cannot see the forest for the trees. The main programmers are often too close to the situation to test the site with a fresh perspective.

Once in a great while, the most difficult part of the programming process is inviting client feedback. This is where the project meets the cold light of day. As in the creative side, it is so important that the technical team work with the client to define "Done." No project can be run successfully without an end point in sight, with specific requirements to be fulfilled.

It's funny, because as I'm writing this book, I've run into several project management nightmares. I wish I could present case studies of circumstances that have happened to other people, but at least I have the ability to put these experiences into perspective and include my postproject nightmare reflections here.

Most of the problems that I run into have a very similar theme. The client's expectation does not match the contracting firm's view. In 90% of these cases, with a little discussion and brainstorming, both parties can come to a mutual agreement. The Web firm may need to give a little and the client may need to adjust a little. In 10% of these cases, the rejection of work does not have much to do with the work itself. The requirements have been met, everything is in place, but perhaps as a result of internal issues with the client, like inability to pay the final bill, they keep rejecting the work.

We found this to be true recently when a client company kept rejecting the programming end of the Web site, saying that there were problems every time we approached them for the final payment. When we notified them that the programming was completed, we never received negative feedback; it was only when we kept trying to present them with the final bill that all of a sudden there was a huge laundry list.

Rejection number one came when the client wanted pieces of their online store done with drop-down selections instead of the links that we provided. I considered that perhaps this was a stall tactic, but in thinking it over, I felt the best way to handle the situation was to charge the employee representing the client with "Defining Done." He sounded very clear, and he assured me that drop-down selections would finish the project. I wondered if somehow there had been a miscommunication, and in good faith, I decided to absorb the change, which was significant, costing another $1000 in programming hours. However, once this functionality was completed, we notified the client of completion, never heard from them, and then when the check was due, they complained that they didn't like how the drop-downs looked. In fact, not only did they not like how the drop-downs looked, but they had a lot of other issues with the site that had not been previously brought to our attention.

At this point, I was very angry, because I felt that the client was being uncooperative. As a Web firm owner/project manager, it's easy to become emotional because you know how nonproductive and costly this behavior can be. To make matters worse, this scenario was coming on the heels of another much smaller consulting project, in which the firm had been quite rudely stiffed. Just recently, a client had contracted for a day's consulting time and some graphic work. He had signed a contract and knew how much it would cost. Then, after he received consulting and development services, he told me that my time shouldn't be worth that much. My associates and I laughed about it afterward, knowing that he would certainly find out how mistaken he was with regard to Internet consulting/Web site development pricing. However, the levity at his expense did not take the sting out of his actions. Needless to say, when this next client payment issue arose so quickly on a much bigger account, I did not have a great deal of patience for it. Still, I was determined to keep a cool head. If I was upset and could not interface well with the client at certain points, I would defer to colleagues, who were not as emotionally invested.

We had completed all of the requirements, had documentation to back up all of our conversations with this company, and these folks just would not pay us, saying once again that they required changes. I backed off, saying that we would accept three-quarters of the final payment, the other one-quarter due upon completing a list of small cosmetic changes. However, I told the client representative that we would not even look at the punch list until this partial payment was received because we felt that there had been a breach of contract. Our contract requires that a client review creative and technical Web site initiatives completed on their behalf and provide feedback on a timely basis. This had not been happening to my satisfaction.

It took an entire day to reach this company. We walked them through the Web site and waded through a bevy of excuses as to why they couldn't talk to us. We listened to how the contact people had been out of the office and had not received our messages. As we continually barraged them with phone calls, their resolve began to weaken. At 4:45 P.M., I got the truth. The reason why we weren't being paid didn't have anything to do with us at all. The owner was wanted for violating a restraining order taken out against him by an old girlfriend. He was avoiding arrest on that particular day. However, these people representing him would have had us doing cartwheels under the guise that our work was not acceptable. I maintained my stance that we had asked them to define "Done" and we had delivered. Then I informed them that Web site would be coming down from the staging server by 5:00 P.M. that evening. They would be charged a $500 reimplementation fee should they want to put it back up, and if I still didn't receive payment within five business days, I would be filing a lawsuit against them for the outstanding balance. The young secretary finally cracked and told me what was going on.

Should it have gone that far? Absolutely not. There had been plenty of signs, which would have motivated a savvy project manager to cut losses and exit the project before any additional resources were used.

First, the client had shown all the signs of someone that would be difficult to work with. He seemed agitated in the first meeting and unable to focus. His broad statements that he could "get us so much business" put me off right away. Whenever anyone says this to me, it always raises a red flag. Usually they want us to cut them a deal, and I know, from experience, that this type of person will rarely deliver any viable business to our firm. It's a smoke screen. However, I felt the site seemed very straightforward, and we would be interacting with his employees, who seemed to be much more focused.

Next, it was sticky getting the deposit money from him. This is always an important sign. If someone graciously and promptly writes the first check, chances are they won't be terribly difficult about the last one. We had to keep after him for a week to get the deposit money to us.

Then, when we showed him the first iteration of the Web site, he never provided feedback. When we later asked for payment, he was so irrational on the phone that he let one of his employees explain why his boss was unsatisfied.

I was inclined to cut my losses and exit at this point. However, we did not have a formal project spec. He had shown us a Web site that he wanted his new site to function like, and I felt the requirements were clear. The client was in an extreme hurry to get a new site up and running as he felt that his old one was costing him money. I felt that he would be motivated to get the new site live and not hinder the process in any way. In fact, in the beginning of the project, his secretary called us daily, pressuring us to hurry. Therefore, we skipped some of the important documentation steps.

Given the fact that we did not have a formal project spec, which the client had signed off on, I felt obliged to try to fix any discrepancies that were identified in this conversation, although not without forcing the client to define "Done." When his definition still did not constitute "Done," I felt that something was definitely fishy.

Did I initially break every project management rule in this book? Yes. I didn't screen the client. I didn't prepare formalized specifications for the client to sign off on. Therefore, I got too far into the project too quickly, with too many expenses to back out easily. I allowed myself to be pressured and led. Having had plenty of experience with identifying and understanding client side project warning signs, I reacted to none of them.

I must say that 95% of our clients are delightful to deal with. I doubt there is a criminal record among them, and most behave with the utmost professionalism. We are extremely lucky in this sense. However, any business has to insulate itself against clients who are experiencing internal difficulties and expect the firm to bear the burden.

If this client had only been up front and had told us of their need to exit or postpone the project, we would have respectfully facilitated this eventuality. However, I felt that the client took an aggressive and damaging stance, like the bully in the playground, pushing us down before we could pick up the ball and run with it.

Did I learn from this experience? Absolutely. I learned that my business instincts could be trusted more often than not. Sometimes we just don't trust our inner voice. We try to tell ourselves that it isn't logical to base actions on "a bad feeling." I also changed our payment terms from half the project estimate due at contract signing and the other half due upon completion to half the project estimate due at contract signing and half due when the project is halfway complete. Most important, I set up a more structured project process. From that point on, every client would receive a client packet in the first two weeks of a project, before anyone touched a keyboard. No exceptions, no matter how much of a hurry they were in. Client packets include the following:

Work order.An initial inventory of programming services requested, the estimated delivery date, and the terms of payment.
Programming services agreement.The legal contract between the Web firm and the client company.
Schedule.A detailed schedule of creative and technical deliverables. Clients should look to this schedule to determine when client review will be required.
Approval letters.Client approval is required for all phases of project development. The following client signoffs are requested before the firm moves to the next phase of project development:
1. Receipt of project packet- to acknowledge receipt and review of the client packet.
2. Project specification and site hierarchy approval- to acknowledge approval of detailed project requirements as defined by the project specification and site hierarchy.
3. Composite approval- to acknowledge which of three creative directions the client wishes to pursue, with any appropriate modifications, as defined in the project specification.
4. Graphic design approval- to acknowledge approval of finalized graphic design.
5. Static page approval- to acknowledge approval of static Web pages (Web pages that do not provide dynamic content).
6. Dynamic functionality approval- to acknowledge approval of program functionality as defined in the project specification.
7. Receipt of training- to acknowledge receipt of on-site training hours as defined in the project specification.
Stamped envelopes.Provided for mailing approvals. However, in order facilitate rapid project deployment, clients can fax approvals, make copies for themselves, and mail the originals to the Web firm.
Acknowledgment of domain name and hosting arrangement.Client will arrange for hosting and domain name acquisition at the beginning of the Web site project. This form supplies hosting company information, user name and password selection, domain name (or IP address), and the name of a technical contact at the hosting company. This arrangement must be completed after the work order is signed and this acknowledgment forwarded to my company, Surf's Up Web Development, Inc.
Client questionnaire.Copy of questionnaire completed previously before or during initial client interview.
Site hierarchy.A flow chart of the proposed Web site architecture, as currently understood by the Web firm. The client is asked to review this hierarchy carefully, as graphics will be built based upon this design.
Project specification.The project "bible," as the Web firm currently understands the client requirements. The client is asked to review this specification very carefully, as it is used as the foundation on which the Web site will be built.
List of client deliverables.This is a list of deliverables (i.e., written copy for static Web pages, photos, etc.) that are needed from the client before the Web site goes into the graphic design or static Web page build phase.

We also now formally describe to the client, in writing, what our production process is, and we formalize client approvals before moving to the next phase. Therefore, long after graphic design is complete and the firm is working on the programming, graphic design cannot be revisited without compensation. We send the client the following letter:

When considering the production process used to build your Web site, please review the following phased approach: Client action items are in bold text.

Analysis

Request for quote submitted to Surf's Up Web development

Client questionnaire and interview completed with client company

Surf's Up project team reviews RFQ for viability and drafts a bid

Bid accepted by client company and contracts signed

First half of project estimate now due

Surf's Up drafts a detailed project specification and site hierarchy

Project packet is sent for review to client company

Receipt due

Client arranges for hosting, registers domain name, and applies for Verisign/merchant accounts (if the Web site is e-commerce enabled)

Verification of hosting/domain name now due

Client provides feedback on project specification and site hierarchy. New documents, reflecting any feedback, are drafted by Surf's Up and approved by the client company Review and approval due

Design

Three graphic composites are drafted by Surf's Up and submitted to the client company for review.

Client picks one composite and provides feedback for any modifications.

Review and approval due

Web site graphic design is completed

Client reviews graphics, provides any feedback for modifications, and finalized graphics are built by Surf's Up and approved by client company.

Review and approval due

Last half of project estimate now due

Production

All deliverables on client deliverable list are now due

Static Web pages (pages that are not interactive) are completed, embedding client text and any secondary graphics

Client reviews these pages, provides any feedback for modifications, and finalized static Web pages built by Surf's Up and approved by client company

Review and approval due

Dynamic content (i.e., database and e-commerce driven Web pages) are completed

Client reviews this functionality and provides feedback for modifications. Finalized dynamic content is built by Surf's Up and approved by client company

Review and approval due

Implementation

Web site is tested and proofread by Surf's Up

Training hours are provided, as defined in the project specification, to the client company

Receipt due

Web site is set live and submitted to seven major search engines

Exercises

Write Programming Plan

Write a programming plan for the project you used in 10.3.2b.

_________________________________________________

What kinds of issues did you address in the programming plan that you did not mention in the project specification?

_________________________________________________

Write Test Plan

Write a test plan for the project used in 12.2.1.

_________________________________________________

__________________________________________________________

What kinds of errors would you hope this testing plan might identify?

__________________________________________________________

Invite Client Feedback

Discuss how you would walk a client through a Web site, demonstrating the functionality.

__________________________________________________________

Which kinds of points must be documented in order to manage client feedback properly?

__________________________________________________________

Exercise Answers

This section gives you some suggested answers to the questions in Lab 12.2 with discussion related to those answers. Please post any alternative answers to these questions at the companion Web site for this book, located at http://www.phptr.com/phptrinteractive.

Answers

Write a programming plan for the project you used in 10.3.2b.

_________________________________________________

Answer:

The following was the technical description used in the project specification:

Technical Development:
This site will be built utilizing HTML, Perl, a mySQL database back end, and possibly Java and JavaScript. Server requirements include UNIX platform, Perl 5.0, mySQL. Front Page extentions are notnecessary. Plans at this time are to install the site on the server owned by We Host 'Em, a local hosting company. Another future option includes Host.Net, located in Anytown, MA. A UNIX platform provides for greater functionality and security than the NT platform and is the appropriate choice for a site of this type. HTML will be used to code the standard Web pages. Perl will be utilized in conjunction with the mySQL database back end to build the Acme database and for CGI interactive functions. JavaScript and Java applets may be used to create a more interactive graphical presentation. This site will be best viewed in Netscape Navigator 2.0 and Internet Explorer 3.0 and above.
Database Functionality
Two database tables will track job seeker and job posting information. Both tables will need to be searchable with an AND interface (i.e., Position AND Salary Requirements) or by a singular criteria (i.e., Geography). Links will be provided to more detailed resume and complete job posting information. These files will be uploaded to the server as text files and coded with a number that mirrors the Access database numbers assigned interoffice. A separate database table will track authorized company names with their user names and passwords.
Job Seeker Table
This table will be password protected. Distinct user names and passwords will be assigned to authorized companies, allowing them to view its contents. TABLE RESUME FIELDS id, name, contact_person, current-company, skills, salary, location-desired, desired_position The id number will link to a separate file, "id.html", which will be a text file containing the candidate's text based resume. Administrators at Acme will need to blank out the name and current company information from the resumes before uploading them. Name will be a "hidden" field not shown to the user. This will be included as an administrative back-up alternative, in case the interoffice numbering scheme fails due to misfiling, etc. This table will be searchable by skills, salary, location-desired, and desired-position by the user. It will be searchable by name, id, skills, salary, location-desired, and desired-position through the administrative back room. "Hits", which bring up candidates who currently work at the company that is searching the database, will be dropped and not shown.
Job Posting Table
TABLE JOB FIELDS id, company, contact_person, skills, salary, geographical-location, position, date The id number will link to a separate file, "id.html", which will be a text file containing the company's detailed text based job posting. Administrators at Acme will need to blank out company information from the job postings before uploading them. Company will be a "hidden" field not shown to the user. This will be included as an administrative back-up alternative, in case the interoffice numbering scheme fails due to misfiling, etc. This table will be searchable by skills, salary, geographical-location and position by the user. It will be searchable by company, id, skills, salary, geographical_location, and position through the administrative back room. Records should be automatically deleted from the system after residing there for over thirty days.
User Name/Password Table
TABLE USER FIELDS user_name, password, company This table will be searchable by user_name and company. An administrative back room will be created for all tables with an add, modify, delete, and the aforementioned searching capability.
Forms
Two forms will reside on the site that allow the user to input either job seeker or job posting information. This information will be e-mailed to Acme Personnel, giving Acme the option to follow up with the prospective candidate or company. The candidate form will first present questions regarding desired position, current role, skills, current company, and then contact information. Name, address, city, state, zip, daytime phone, evening phone, and e-mail will be required fields. The job posting form will include company name, contact name, address, city, state, zip, phone, position, skills required, and salary range.

The programming plan must include a listing of programs used to drive this functionality, their modules, and any special technical considerations that might impact on the Web site's ability to provide cross-platform functionality.

A programming plan for one of the programs on this Web site might look like the following:

Acme Personnel Web Site Programming Plan-Seek.cgi

Based upon the requirements described in the project specification, this program allows the user to search the job posting database.

The search functionality must include AND/LIKE/BETWEEN/= conditions. A form must first be built, named seek.html, which includes a text field for skills, drop-down selections for geographical location, drop-down descriptions for types of positions, and two text fields for salary-named salary and salary 1.

Drop-down choices for the location field include North Shore, South Shore, 128 West, 495 North, Western Massachusetts, Greater Boston.

Drop-down choices for the position field include NT System Administrator, C++ Programmer, Web Developer, and Software Engineer.

Variables will be passed to the cgi search program, coded in Perl, using the cgi-lib.pl library.

First, the program must determine which fields have been used in the search criteria.

If several criteria are used, the automatic understanding of the program will be that each criteria will be included in the search parameters with an AND statement.

The other search statements, depending on the fields filled out and passed, include

Skills-LIKE function

Salary-Two fields will be input, facilitating a BETWEEN function

geographical-location-Drop-down input facilitates = function

position-Drop-down input facilitates = function

If there are search results, the user should be directed to an output page, seektrue.cgi, containing the information. If there are no search results, there should be a program, seekfalse.cgi, sending a message to the screen informing the user that there has been a null result, and giving the user a link back to the search page to try their search again.

Error messages should occur if

Character strings are input into the salary fields

There is no search criteria input

What kinds of issues did you address in the programming plan that you did not mention in the project specification?

_________________________________________________

Answer:

In this section of the programming plan, query structure was addressed, discussing which criteria would be attached to which field (i.e., Skills is a "LIKE", Salary is handled as a "BETWEEN", etc.). In addition, error conditions are addressed.

Perl coding will use the cgi-lib.pl library. This would not mean anything to the client. However, in order to maintain programming consistency, it is important to the programming team.

Programming code has to determine which fields are being used as search criteria. From there, a query statement can be constructed.

Answers

a)	Write a test plan for the project used in 12.2.1. _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ _________________________________________________ __________________________________________________________ __________________________________________________________ __________________________________________________________
Answer:	The following conditions for seek.cgi should be tested: Search using each individual search criteria. Search using every combination of search criteria. Enter character strings in the salary fields. Enter no search criteria. Test "LIKE" functionality by entering the beginning letter of a true result. Verify search results containing correct output information.
b)	What kinds of errors would you hope this testing plan might identify? __________________________________________________________ __________________________________________________________ __________________________________________________________
Answer:	I would want the test plan to identify incorrect use of error messages and unreliable query results.

Answers

a)	Discuss how you would walk a client through a Web site, demonstrating the functionality. __________________________________________________________ __________________________________________________________ __________________________________________________________
Answer:	The best way to walk a client through their Web site is through a face-to-face meeting. If this is not a possibility, it is best to speak with the client on the phone while the client is viewing sections of their Web site, as specified by the project manager. If you are already into the technical phase of development, let us assume that graphics and site layout have already been approved. Therefore, if there is a database, test data should have been input ahead of time to illustrate the Web site's functionality. The project manager should have several scenarios to demonstrate to the client. Then the project manager should walk the client through the administrative back room so that they may understand how information is input, modified, and deleted. Lastly, invite the client to then click around the entire Web site, to assure them that all of the links are working correctly.
b)	Which kinds of points must be documented in order to manage client feedback properly? __________________________________________________________ __________________________________________________________ __________________________________________________________
Answer:	Clients are usually concerned with the method by which information may be requested and how that information is then output to the user. So detailed description of the front-end interface is key. Summary of this functionality must be included in the project specification and the more technically interpretive programming plan. The project specification is reviewed and approved by the client; therefore, any pertinent details that could be contested by the client must be included here.

Self-Review Questions

In order to test your progress, you should be able to answer the following questions:

(True/False) The following issues would be typically addressed in the programming plan rather than the project specification:

_____ Sessions coded by ASP programmers might necessitate the use of cookies.
_____ Perl 5.0 is the version of Perl used for the Web site.

(True/False) If a client contested the use of drop-down selections for their Web site, you would refer to which of the following documents?

_____ Project specification
_____ Creative brief
_____ Programming plan
_____ Test plan