Project management for Web development can be a simple process or a
very complex undertaking depending upon the scope of the project.
Large scale projects will often require a separate project manager who
tracks the timing and completion of designated tasks by specific
resources. The critical path for these projects can alternate
among various entities such as graphic design, programming or data
requirements.
Even the more simplistic approaches to tracking progress on a job
require some sort of project management tool, and the project schedule can
often suffice to tie the pieces of the process together. Minimally
the project schedule should include a description of the work involved
and a designation of who is responsible. Each item should also
have a proposed date, revised date and actual date. This will
provide a record of those instances when a deliverable was late, and its
affect on the project schedule and the ultimate delivery date.
This can be helpful when it is necessary to explain to a client that the
project schedule will need to be pushed back. The sooner the
client knows that project is slipping the better they can prepare for
the consequences the web designer may not be aware of. It almost never
makes sense not to tell a client that the project is late in hopes that
the designer can make up the time.
The following are some typical milestones with a description of each at the bottom. The term designer is used as an example in this schedule, but developer or web project leader may be more appropriate depending on the specific case at hand.
|
|
Description |
Responsibility |
Proposed Date |
Revised Date |
Actual Date |
|
1. |
Planning Meeting |
DESIGNER, CUSTOMER |
|
|
|
|
|
|
|
|
|
|
|
2. |
Distribute meeting summary |
DESIGNER |
|
|
|
|
|
|
|
|
|
|
|
3. |
Draft Legal Contract |
DESIGNER, ATTORNEY |
|
|
|
|
|
|
|
|
|
|
|
4. |
Sign Contract |
CUSTOMER |
|
|
|
|
|
|
|
|
|
|
|
5. |
Production Meeting Submit initial text, photos, discuss
keywords |
DESIGNER, CUSTOMER |
|
|
|
|
|
|
|
|
|
|
|
6. |
Domain Name Acquired |
DESIGNER, or CUSTOMER |
|
|
|
|
|
|
|
|
|
|
|
7. |
Distribute Specification Documentation |
DESIGNER |
|
|
|
|
|
|
|
|
|
|
|
8. |
Approve Specification Documentation |
CUSTOMER |
|
|
|
|
|
|
|
|
|
|
|
9. |
Receipt of Final Text, Photos, Data |
CUSTOMER |
|
|
|
|
|
|
|
|
|
|
|
10. |
Initial prototype ready for review |
DESIGNER |
|
|
|
|
|
|
|
|
|
|
|
11. |
Comments on initial prototype due |
CUSTOMER |
|
|
|
|
|
|
|
|
|
|
|
12. |
Revisions incorporated into final prototype |
DESIGNER |
|
|
|
|
|
|
|
|
|
|
|
13. |
Final Prototype Approved |
CUSTOMER |
|
|
|
|
|
|
|
|
|
|
|
14. |
Web Hosting Service Acquired |
DESIGNER, or CUSTOMER |
|
|
|
|
|
|
|
|
|
|
|
15. |
Web Site Launched |
DESIGNER |
|
|
|
|
|
|
|
|
|
|
|
16. |
Web Site Approved |
CUSTOMER |
|
|
|
|
|
|
|
|
|
|
|
17. |
Submit to Major Search Engine Listings |
DESIGNER |
|
|
|
|
|
|
|
|
|
|
|
18. |
Generate Traffic Analysis Reports |
DESIGNER |
|
|
|
Normally the planning meeting would be a face-to-face meeting where all aspects of the project are discussed and details are established based on the desires and needs of the website customer. Usually some of the details are concrete and others are vague at this point. The sooner the vague details become clear, the sooner development can begin. This meeting can also be accomplished over the phone or through a questioning email.
There are advantages and disadvantages to not having the planning meeting face-to-face. Certainly the savings in travel costs is a positive. The primary negative is that emails are not always clear and often misinterpreted, particularly the discussions of those issues where feelings are involved and where design issues can be misconstrued. Much more effort will also be necessary to accomplish the same things when working through emails. Phone conversations can be effective, but they never are as good a face-to-face meeting.
For a telephone conversation I would suggest that the Planning Meeting questions be submitted to the client so they can organize their answers prior to the telephone call and the call can be used to confirm the issues.
Once the Planning Meeting is complete the meeting is summarized in writing to be sure that both parties are in agreement.
A contract is drafted by the designer usually based on some boilerplate that has been established and is geared to the requirements of the job. If there are questions regarding legal language an attorney should be involved.
At this point, once the scope of the project is known, a contract is prepared which outlines the commitments on both sides. Even though it can take substantial work to get to this point, formal work on the project does not begin until the contract is signed.
The purpose of the Production Meeting is to confirm all aspects of the Planning Meeting and any subsequent discussions regarding design, text, links, graphics and anything else necessary to start programming the website. It requires that the initial text is complete, that all pictures or graphics have been delivered and that the design and layout have been established to a point where development of the prototype can begin. Keywords and meta-file descriptions will be discussed to determine how search engines will look at your site. Domain names and alternatives are discussed.
A domain name is purchased based on its availability. In the Planning Meeting possible names and alternatives were discussed.
This initially defines the specifications for the site. This documentation will either be updated as the site design is updated, or will be used get to the online web prototype as the ultimate documentation. How long to use the Specification Document will be based on the complexity of the design itself. Usually, the more complex the design, the longer it is necessary to work from paper documents (Word files), rather than from the website prototype itself. In some instances all aspects of the site will need to be documented. This is an arduous task and in many cases can become more work than the design of the actual site. Project needs and complexity will dictate the forms of documentation necessary.
Approval of the Specifications Documentation by the client happens before programming begins.
At this point any final text changes or revised graphics files are provided. This is the step that usually delays implementation. Until all content is provided it is difficult to move forward. The designer can help generate content, but usually the business owner has the best idea of what their business is and the image they want to convey.
Once we have everything defined a prototype is developed so the client can see how the site will look on the Web. A development site with separate client directory structures can permit the client to view their web site before it is launched under their own Domain Name.
The client views the development site and provides any comments or revisions.
The changes are incorporated into the 2nd and final prototype.
The client reviews and approves the prototype. Generally, it is wise to limit the number of revisions to 2 with an additional charge for more. This is primarily done to prevent significant and time consuming changes ― scope creep. Minor changes are possible but try to avoid going back and forth with changes at this point since the initial planning should have things defined pretty well and the client should be encouraged to be thorough.
If it does not exist already a Web Host is obtained. This is normally not too difficult if all of the components and requirements of the site are known. But, when additional development is expected after the initial launch then consideration will need to be given to the ultimate design and its affect on the hosting capacity required.
Launch the site by moving the files from the development system to the hosting system under the new domain name.
The client now has a chance to review the site in its final location. There should be no difference if the structure has remained the same.
Register the site with the major search engines and monitor traffic.
Do an analysis of the traffic reports to determine what needs to be done to increase traffic if that is an issue of importance.
This list will change slightly from one project to another with the addition of certain critical items, but it should not get much smaller. These are intended to be the minimal steps necessary to complete a small Web project.
While at first glance this sequence would seem to be quite straightforward and maybe unnecessary. Nothing could be further from the truth. Managing from a Project Schedule can require the tact of an elder statesman. Convincing the client that it is in their best interests to follow this guideline strictly can tax your negotiation skills.
I remember a client who seemed ready to go into convulsions over the fact that their site was going to be late. The client was late with everything but still thought they could demand that the schedule be met. He was firmly given a choice. You can have it on time or you can have it right. Take your pick. After much moaning the client agreed to delay the delivery date. It turns out that part of his bonus was dependent upon the timeliness of the project. The project was delivered slightly late, but the client was especially thankful for the delay because in the end he was complimented for a project well done.
In the end, managing a project without a schedule is like pushing a string ― a good deal of effort gets you nowhere until the end of the line.