Web projects present similar types of management issues as other types of projects. The same set of variables, which range from the look and feel of an application to schedule, cost, budget, and resources, are involved. Some of the most referenced texts on Web project management are those by England and Finney. In their books, Web project management is described as having four phases: preliminary, production, final sign-off, and archiving. Other models have described the phases in other ways, such as in terms of concept development, preproduction, production, testing, and archiving. However, irrespective of the number of phases, or the labels used, what is important is that the phases of management span the stages of Web development cycle; after all, Web project management is simply the management of the various activities of a Web production as well as the associated resources. For the purpose of discussion, the stages of Web development cycle are defined in this text as initiation, preproduction, production, and postproduction, and the management phases are matched to these stages accordingly, as illustrated in Figure 27.8.
1. Initiation Phase
The initiation phase of a Web project typically comprises the definition of the scope of the project, the production and tendering of the final version of the proposal, and the production and signing of the contract. It is the phase in which the initial important decisions are made, including whether or not a project should go ahead, if there had not been any preliminary process. It is where agreements and promises are made that give a project its goal. Although it is not where most of the hard work is done, it is a very important phase, in that getting it wrong can cause problems later in a project. Because of its pivotal position, all the key people in a project are usually present at the start of the phase, if not all through it. Usually everyone who will be using the system is involved at some point during the phase, if situation permits. It is particularly important to urge that end users are involved, as this can often give them the sense of co-ownership, thereby improving their willingness to cooperate.
1.1. Project Definition Process
The determination of a project’s scope (also known as scoping) is the first main activity in the initiation phase and its overall goal is to gather enough information to facilitate the success of a project through researching the client, target audience, relevant content, and the marketing of the finished product, where applicable. Typical agenda includes determining the project’s aims and objectives, determining the risks and possible difficulties, and laying down a road map for the project. As a Web project manager, your role in completing this agenda is very significant. You are responsible, for example, for identifying tasks, breaking them down, estimating the number of hours each task will take, determining staff and assets necessary for each task, and putting a cost to them. You can achieve all these usually through using different tools and techniques, such as meetings, discussions, and brainstorming sessions, including the techniques discussed in Chapter 26 that are used for evaluation, such as questionnaires. Combinations of techniques usually produce the most complete result, since different techniques have their pros and cons.
The scoping process should seek to extract as much information as possible to fulfill the project’s objectives. Questions should be crafted to provide answers that can be used to determine the resources, cost, time, scope, and quality variables. They should seek to extract, for example, the problem you are trying to solve, business objectives (if any), target audience and its technological awareness, how much of each media object type needs to be used, whether there are existing contents and/or system, delivery platform, expected completion time, type of maintenance required, budget, and, where applicable, the contact details of the important people, such as those responsible for giving the go-aheads and sign-offs.
Of all scoping tasks, the costing of a project in the absence of all facts is often most difficult. It is often a guess, even if educated; therefore, the chances of under-costing are just as high as over-costing, depending on experience. It is usually prudent to work on the basis that a little more would be required of everything than has been calculated. If cost then turns out to be less, it would certainly be a pleasant surprise, especially for the client, where there is one.
To help structure and ease the process of costing, there are tools available to do the calculations. However, the tools cannot make decisions on how many hours a task will take, or the cost per hour. In theory, the more structured the scoping process, the more easily and more accurately tasks can be identified and a project appraised. Breaking down activities into smaller task units usually makes the allocation of resources, scheduling, and costing easier and more accurate, just as the use of charts and diagrams, such as described earlier in this chapter, can help present who is responsible for completing which tasks more clearly. A properly structured scoping process also ensures a structured output, which is essential for the production of a proposal.
1.2. Proposal Process
A project proposal brings together all the information gathered during the scoping process into a single cohesive document that communicates the goal of a project, without being too specific on the details of development, particularly as it can be difficult to be certain of everything at the initiation phase. The overall success of the document at communicating the intended message effectively depends on its content and the presentation of that content. The presentation component is the least challenging to attain and the principles that guide its success are not much different from those for producing readable content on the screen. Basic things such as visual hierarchy (using fonts appropriately) and leaving enough space at the margins to enable clients to write comments while reading a proposal can go a long way toward making a proposal inviting, and easy to read and work with, and so can the inclusion of visuals (such as graphs and charts) and good quality print.
Style of writing is also very important for easy understanding. A proposal should not be long when it can be short and sharp. Even when it has to be long, it should not be rambling, but direct to the point that is relevant. It should also be in formal and “politically correct” language that most people understand. For example, colloquial expressions or slangs should be avoided, as they are likely to be understood only locally or by a group of people. The use of “he” or “her” alone, too, should be avoided, because the person reading the proposal might be of the opposite gender and might feel alienated. The same goes for technological jargons. If they must be used, then they should be explained, for example, via footnotes or appendix. Above all, a proposal is a proposal, not a set of instructions, so it should be advisory rather than prescriptive. This helps ensure that clients get the sense that whatever decision they make is their own and you have not told them to do anything. To help further give clients the sense of having an option, it is usually useful to suggest more than one way of addressing their needs. Although this might require a little more work, it can add to the building of trust, in that it gives the impression that you are not trying to push any particular treatment(s) for your benefit.
A proposal can be of any size, ranging from just a few to hundreds of pages, depending on various factors, such as size, type of project, and whether you are competing with others for the same job and therefore need to include a lot of information to gain an edge. However, irrespective of its size or the type of information contained in it, it should normally convey clearly the following messages:
- The problem the proposed project will solve and/or the needs it will fulfill.
- Why you are qualified to do the project.
- What you are proposing to do to solve the identified problem or satisfy the clients’ needs, including proposed timetable and costs.
Usually, these messages are most clearly communicated by breaking down a proposal into smaller, distinct, and appropriately headed sections. Figure 27.9 shows an example that covers many of the topics typically included in a Web proposal. If nothing else, it provides a possible starting point. What goes under each topic depends on various factors, such as size and type of project. The cover letter is not part of the proposal and is usually very short and seldom does more than simply drawing attention to the delivery of the proposal.
1.2.1 Introduction Section
The introduction section provides items that introduce the content of the proposal and its purpose. The title page ideally carries information such as name and address of developer, project title, date, the name and job title of the person for whom the proposal is prepared, the name and job title of the person that prepared it, the description of the project, and project number, if applicable. For easy scanning, the table of content should be divided into sections or parts that reflect the structure of the proposal. A non-disclosure agreement is included to prevent a client from disclosing the information contained in the proposal to other companies.
1.2.2. Summary Section
The summary section is the most-read section of a proposal because it gives a quick brief account of what a project is about. The executive summary describes, in simple language, the essence of a project and cost summary gives the cost totals, typically in the form of costs per group, followed by the project’s total cost. It is common practice to include a disclaimer, at the end, to indicate that the costs are only estimates and not final.
1.2.3 Needs Section
The needs section is used to show the clients that you understand their needs and/or problems and know how to address them. It typically includes the understanding of how the client operates, as well as the description of its background, market, target audience’s characteristics, competition, strengths, and weaknesses. In the case of the target audience’s characteristics, for example, description might include size, demographics, why the audience is the target, and also how the proposed solution will be targeting it. The inclusion of some kind of justification for any proposed solution is also important to bring the client along. This might include, for example, how the proposed solution can give the client an edge over competitors, help the client survive possible adverse industry trends, and/or help productivity and profitability.
1.2.4. Goals and Objective Section
The goals and objectives section provides the objectives of the proposed project and how their achievement will be measured. Typically, the features and benefits that will be offered by the proposed system and how they will be achieved are described. The dates and description of milestones, including the start and acceptance dates of the project, and what will be delivered, are described, possibly also using diagrams, which may or may not be placed in the appendices. Any possible disruptions the implementation of the project will cause in the client’s operations, and how these will be limited, are also useful additions. In all cases, it is important not to promise what is not certain you can deliver.
1.2.5. Methodology Section
In the methodology section, the phases of the proposed project are detailed. For example, the production processes that will be used to achieve the objectives of the project are described, including process model stages, details of human and other resources, marketing plan, legal matters, and constraints and their effects on the project, as well as how they will be managed. The conditions on which the content of the proposal is valid are also commonly stated. These may be, for example, that the proposal is accepted by a certain date, the clients play their parts (such as providing information and existing content on time), and external factors remain roughly the same all through the project (such as costs of sub-contracting). A list of identified risks may also be provided that describes the risks involved, what will be done to minimize them, and the contingency plan to address them, should they materialize. If this information is included, then it is useful for legal reasons to also include a caveat that makes clear that there are no guarantees that all risks have been identified, or that those identified are completely accurate.
The testing plan can include various testing information, including the types of tests that will be conducted, when during the development process they will be conducted, the tools that will be used, how any problems found will be reported, tracked, and resolved, and how re-testing will be carried out. The maintenance plan provides maintenance details, which can include the components that will require maintenance, how often the maintenance will be, estimate of the cost, and who will be responsible for providing it. Even if maintenance will be provided by the same company that develops a site, entering into a separate agreement is usually required.
Any other information relating to the processes and deliverables for a project are also provided in this section or, in some cases, the appendix, including the following:
- Description of how the existing content and any that is created will be used.
- Clear description of treatments proposed to match users’ needs, along with the reasons behind choosing them; avoiding any attempts to impress.
- If applicable, an outline of unusual technical requirements needed for the delivery of size.
- If applicable, information relating to security, data management, regulations, permits, licenses, training plan, installation schedule, data recovery plan, and backup plan.
- If applicable, a list of the project team members, giving the names, roles, and responsibilities.
1.2.6. Evaluation Section
The evaluation section outlines the details of evaluation and describes how, when, where, and by whom the success of the project will be measured, including whether evaluation will be done all at once, or in stages, for example, in line with the project’s milestones. Also included are the criteria against which the project will be evaluated, which are essentially the requirements on which the project has been based in the first place, such as functional requirements, contractual requirements, system requirements, document and training requirements, user-interface requirements, and performance requirements. Explanations about how deliverables will be assessed against these requirements and necessary contracts and agreements are provided. All stages of evaluation and their purpose are explained, including how data will be collected and analyzed, and how the results obtained will be reported.
1.2.7. Budget Section
Details of the cost summary presented in the executive summary section are provided here. Essentially, everything that is to be paid for by the client is itemized in this section, along with a simple justification, if possible. For example, the rationale for charging $100 for something might be that it is the standard cost. Providing such justification ensures transparency in costing, which in turn can translate into clients’ trust. Importantly, a line should be included for hidden costs, such as costs of phone calls, postage of documents, report writing, consumables, and transport, which may easily accumulate during the course of a project. The same applies for contingencies to cover unforeseen circumstances that may call for more time and/or resources. As a rule of thumb, an amount of about 10%-15% is typically added for contingencies. If applicable, a detailed cost-benefit analysis may also be provided that gives some years’ projection. This may show, for example, total costs, benefits in money and return of investment (i.e., “benefits in money” minus “total cost”).
The payment schedule page provides mainly dates, amounts, and the criteria for payment. Staged payment is favored, for many reasons. For example, you might need the money to help progress the project. It is also an insurance against the possible event of the client ceasing trading before a project is finished, which might leave you with no payment for all the work that has been done, if this has not already been settled. Indeed, some companies might just refuse to pay. It is common for payments to be in thirds: one-third at the start of project (i.e., with the signing of the contract), another third at delivery, such as during alpha or beta testing, and the last third on final sign-off.
The supplied materials item specifies the materials to be provided by the client and can be in the form of a list of descriptions of the materials and their due dates, noting that it is the client’s responsibility to provide them on time to avoid delays. The other materials item describes any equipment, materials, hardware, or software required for the project, stating which will be provided by the client and which will be provided by you, and also whether they are to be purchased or leased. If any materials will be cleared (licensed) for use on behalf of the client, this is indicated, and the cost included in the budget section. A contract and terms page is also typically included in this section if a separate contract is not presented elsewhere.
1.2.8. Qualifications Section
This section is used generally to describe why you think you are best qualified to achieve the objectives of the proposed project. This may be in the form of listing the client’s needs outlined in the needs section and describing how you are qualified to satisfy each of them. The amount of information provided depends on different factors, such as scale of project. For example, for large projects, such as government projects, a lot of information is usually required, given that there usually are several companies bidding for the same project. The general aim is to communicate why you are unique for the project in question. In large and/or mission- critical projects, it may also be necessary to include description of any quality control measures in place to ensure that the project does not go wrong, stating if such measures comply with any recognized standards. Further information may be provided in the form of track record or history that provides evidence of your suitability for the project, including the description of past, similar, and successful projects, along with testimonies from past clients, references the client can contact, and even resumes of project team members, if known. In essence, any information that will instill confidence in the client about your capabilities is included.
1.2.9. Appendices
Any information that can help the client further understand the proposal, but cannot be included in the body of the proposal, is placed here. The information might include charts, testimonials, references, solicitor-checked warrantees and disclaimers, glossary, forms, lists of definitions, acronyms, illustrations, and short nontechnical description of relevant Web technologies. Again, the amount of information included depends on factors like the size and complexity of a project. The information is also usually referred to from the body of the proposal, and relevant proposal page numbers may be used with relevant information for better cross- referencing. Like the rest of the proposal, the content of appendix needs to be structured and formatted properly, using sectioning, spacing, and styling appropriately, to make it easy to scan.
1.3. Contract Process
A contract is a binding agreement between persons or parties, and can take many forms. It can be simple, complex, oral, or written. However, in formal business dealing, such as a Web project, it is usually written, for many reasons, some of which are to prevent any party denying, forgetting, or getting confused about their contractual rights or obligations. In a Web project, reaching the contract stage implies that the client has agreed with the content of the proposal. If there is a suitable template contract that contains regular clauses applicable to Web projects, then you need only to ensure that aspects relating to the present project are added, as well as seek the advice of a media lawyer for unusual circumstances that have not been encountered before.
During the process of drawing up a Web project contract, one of the first things to decide is whether the necessary contract terms and clauses will be included with the proposal, or put on a separate document and negotiated separately after the acceptance of the proposal. This is important, as the decision might influence the phrasing of the terms and clauses. If the contract will be included in the proposal, standard legal terms and clauses can simply be spelt out on a separate page and attached to the proposal, while also inserting at various relevant points in the proposal, appropriate terms and conditions. For example, on the Payment Schedule page, terms and conditions may be stated relating to the consequences of failure to comply with the payment schedule. If the contract is separate from the proposal, again, standard legal terms and clauses may be spelt out in a separate document, except that, in this case, project-specific clauses that reference various aspects of the proposal are also added. For example, a clause may be included in relation to, again, the Payment Schedule, stating the consequences of failure to comply.
A contract must be signed for it to be binding. In many cases where the contract and the proposal are separate documents, both are signed, but not always; all depend on factors such as the way the contents of the documents are phrased. This is one reason that the use of a lawyer is often well advised. Like with a proposal, there is no single correct way of structuring a Web contract, nor is there one correct set of information that is concluded. The following are some of the typical sections found in Web production contracts.
- Recitals: This is the typical preamble at the start of most contracts. It describes the intentions of the parties involved. For example, it says what services a developer provides and what service a client wants.
- Definitions: These are the definitions of the terms used in the contract.
- Development, delivery of deliverables, and payment: In this section, the details of the project are given. Examples include the description of the project in no more than two short sentences; statements that the developer or approved contractors will work and deliver deliverables according to specification, production schedule, and confidentiality agreements; statement that the client will pay according to the payment schedule; and statements relating to the maintenance and change policy. Naturally, there will be changes, particularly in large and/or complex projects, so it is common to devise ways of managing them than try to prevent them altogether. The relevant clause could state, for example, that when changes are required, their feasibility, cost, and effects on project schedule will be assessed. If the project will be delivered and/or signed off in stages, then a statement can be included to state the need to agree on who will be responsible, from both sides, for doing the signing- offs. The agreed names can be added to the proposal, where they can be changed during the duration of a project, if necessary.
- Testing and acceptance: This section presents clauses on the types of testing or evaluation that will be carried out and the responsibilities of the developer and the client, as applicable. Clauses may also cover policy regarding the reporting of errors that are found after the delivery of website. If applicable, there may be a statement on how long testing will go on after the delivery of the system before the final sign-off. The details of the testing plan would have been provided in the proposal.
- Copyrights: What all the parties concerned are entitled to, or not entitled to, is clearly outlined here. Examples include who owns the media produced and/or the generated codes, you or the client, and whether or not the clients may use the media produced for other purposes. In a small project, all that is usually required is a release form clearing you from any claims or demands resulting from the use of the media created. A release form for a photograph or a video, for example, can be as simple as shown in Figure 27.10.
- Confidentiality: In this section, terms are stated regarding what information can and cannot be shown to third parties. It is similar to the non-disclosure agreement that may be included in the proposal. The difference lies mainly in when either is signed. A non-disclosure agreement is signed with the tendering of a proposal and typically refers to the content of the proposal, whereas confidentiality agreement is signed after the proposal has been seen, and accepted, and therefore generally refers to what is disclosed during the project. Again, there is no one correct approach; a nondisclosure agreement signed when the proposal is tendered can be made to cover the entire project.
- Warranties, Covenants, and Indemnification: This section states the terms under which the developer and the client can enter an agreement, including the damages and costs, each party is secured against. Also, there are usually statements to say that the use, performance, and distribution of the product delivered by the developer will not violate the rights of any third parties, and that it is the clients’ responsibility to properly license the content they provide. If the clients want to use other people’s work in their content, then they must secure the rights for such usage and indicate in writing to you that they have done so. This indemnifies you from possible secondary copyright infringement. If you are licensing any content on behalf of the client, this responsibility is stated clearly also, along with how any incurred cost will be paid, if not included in the proposal under Project Budget and Cost Summary. For obvious reasons, some contracts may also include a clause freeing the developer from any responsibility regarding deficiency in performance due to influences that are not theirs, such as defective hardware or inadequate computer system setup.
- Termination: The circumstances under which a project will be terminated are described in this section, along with the subsequent actions to be taken, such as whether compensations will be made by one party to another and what will happen to the media assets already produced.
- Miscellaneous: Other clauses are included here. These include standard clauses, also known as boilerplate clauses, such as Force Majeure, to indemnify the parties involved. Other non-specific issues about a project can also be addressed.
Because a Web project can involve dealing with freelancers to complete parts of a project, such as video production, instructional design, and music production, it is sometimes necessary to also draw up contracts for these parties. Any formal agreements with such parties naturally happen after the main contract has been signed with clients, and it is clear the project is going ahead. Once all agreements are firmed, the project is moved on to the planning and designing phase.
2. Preproduction Phase
This phase is where the project team is determined (if applicable) and the elements necessary for achieving the objectives of a project designed and/or gathered. The managerial tasks are to ensure that the right people are selected and the design of both media components and website satisfy the requirements that have been set out during the initiation phase. The sets of tasks include building the team, gathering content and getting clearances, designing the system, designing the media elements, selecting the production and development tools, and selecting types of testing, all of which are discussed next.
2.1. Project Team Selection
The first task required in putting together a team for a project is identifying the skills needed to fulfill the requirements of the project. Doing this requires you to have a clear vision of what a project entails, as well as a good understanding of the skills used in the various fields involved. This knowledge would also have been applied during the initiation phase to produce the estimates (e.g., schedule and cost) presented in the proposal. The mix of skills required would depend on many factors, some of which are content, media object types that will be used, best-suited integration tool, and project size. The challenge at this point is to match the skills required to personnel selection. How this is done, again, depends on various factors, such as your size, and whether or not you have dedicated staff with the skills required. For example, if you are a freelance developer with multiple skills, you may not need to put a team together, or might only need to contract out only a small part of the work. In contrast, a multi-staffed developer company may have full-time staff from which to assemble a core team (i.e., people that provide the core skills needed) and only need to bring in other people from outside, as required, to form an extended team.
For obvious reasons, core skills are usually matched with in-house personnel, where possible, before considering people from outside. For example, it tends to cost less. Recruiting outside personnel can be made especially easier if there is already a list of freelance developers that can be brought in, instead of using advertising or recruitment agencies, which often adds extra cost to the process. Typical core roles include Web designer/programmer and graphic designer. Extended roles include video personnel (e.g., director/producer, editor, and journalist), sound personnel (e.g., sound editor), animator, instructional designer, actor/actress (e.g., voice-over artist), proofreader, tester, and many more, depending on type of project.
2.2. Content Gathering and Clearance Process
The completion of the core team selection, if applicable, means that the crucial manpower is in place to start the development part of a project, which is started by first gathering and analyzing relevant existing assets. The task here is to ensure that the assets are provided in time by the person who would have been identified during the initiation phase. It is also to ensure that the assets are evaluated against project requirements, which may involve checking quality and whether or not any clearance (creator’s permission to use asset) is needed, and has been acquired by the client, if applicable. The outcome of this process will largely influence the decision about which components need to be designed. For example, if the quality of an asset is not good enough, or it cannot be cleared for use in all the required territories, it means it has to be created or bought from royalty-free stock. For noncommercial projects, such as personal sites, there are many sites that offer free media as long as certain terms are followed, which is typically that a link is provided back to their sites.
Even if the client is responsible for clearing existing assets, it is your responsibility to ensure that they have been cleared properly, because rights clearance can be complicated. For example, clearances normally cover specific markets and territories; that is, they are cleared for specific purposes, audience types, length of time, and countries. For instance, clearance is usually for the whole world, since the Web is global. Most importantly, the clearance process should start as early as possible so as to prevent any delay. For example, sometimes, clearance may take long, either because the author of a media cannot be ascertained or found, or a publisher’s licensing process is complex and lengthy. This can delay a project. Also, requests for clearances can sometimes be refused. If this is not realized as early as possible and fixed, it can disrupt a project. If it is realized early, necessary decisions can be made to drop the media concerned and clear another, or design a substitute, without any delay.
2.3. Website Design Process
Whether or not any significant designing has been undertaken before the preproduction phase of a project depends on the negotiating situation. If, for some reasons, it has been necessary to show some sort of prototype to the client before proceeding with the signing of the contract, then some designing activities would have been undertaken during the initiation phase. However, in most cases, the design phase is where serious designing work happens. The task is to ensure that an appropriate design concept is established that matches requirements and this should be done from the start, as problems are better and more easily solved at the early stage than later when they can cause serious disruptions, including termination of project.
It is important that the right design tools, such as wireframing and flowcharting (discussed in Chapter 26), are used and every design detail documented, following a predetermined format, in order to foster effective and consistent communication of design ideas within the project team, if there is one. Doing this also ensures that if any team member drops out, another person can easily pick up from where they left without serious disruption.
For a freelance developer, although the urge may be strong to skip the design phase and/or the use of visual techniques like storyboarding and move on to production, it is always advisable to suppress it, because not only does visualizing a design first on paper help spot any design shortsightedness that might prove costly later in development, but also outputs from such processes are part of the documents archived at the end of the project for future reference. The importance of archiving is discussed later in this chapter.
2.4. Media Objects Design Process
Designing the media objects needed for a website typically entails a variety of task sets, such as designing graphics, producing animation and video storyboards, determining the types of sounds required, and designing the content. The task here is to make sure that every component is designed to meet the project’s specification. For example, in the case of sound, is it in mono or stereo, is resolution in 8, 16, or 24 bits, and is it CD quality? In the case of graphics, what resolution should be used? Similarly, for video, is it full-, half-, or quarter-screen in size; is color resolution in 8, 16, 24, or 32 bits?
The management of media components’ quality is particularly important, as poor media quality can make an application appear unprofessional. Of course, good project management also includes knowing that high-quality media is used only when necessary. For example, images used for icons need not be of high quality, whereas images used for content must be of good-enough quality to communicate intended message effectively. The design of some media components may also require choosing between professional and non-professional production. For example, if a project requires an original piece of music, this would require professional-standard production, probably in a professional studio or a similarly equipped environment. Similarly, if a high- quality video is required, professional production may be considered.
Good management would also ensure that appropriate and consistent file formats and file-naming conventions are used to store files to facilitate the exchange of files between software tools. For example, a file could be named according to “screen number + whether an image is a button + if it is a button, the state it represents, and so on,” representing each parameter with a number or letter(s), as appropriate; so that the image of a button that is depressed and on screen 2 might be coded as 2BD, where “B” stands for button and “D” for depressed. Something like this can prove very useful for troubleshooting and the effective management of changes during subsequent phases.
2.5. Media Production Tools Selection
Whether the selection of media production tools should come before or after the designing of media elements is debatable. One way of thinking is that knowing what is going to be created helps in the choice of the right tool to do it. The choice of these tools will usually be influenced by the operating systems running on the computers to be used for production. For example, there are some tools that are available on Microsoft’s Windows but not available on Apple Macintosh or Linux, and vice versa.
However, most tools are increasingly available across main operating systems, and for tools that are not available on other operating systems, there are equivalent tools that offer similar functions.
3. Production Phase
The translation of the design to an actual system occurs in this phase, although it is not unusual for some minor adjustments to be made to some designs. In general, project management in this phase revolves mainly around managing content creation, content processing, and the creation of the designed website. Content creation and content processing (i.e., editing and adding effects to media) tend to happen together when content is newly created, whereas for existing content, only processing is usually needed. In either case, all outputs need to be checked against project specification. Where a team is involved, typically, the individual team members responsible for creating or processing any media component would be capable of doing this, but the project manager may be involved, or at least be aware of the outcome, either immediately or periodically. One way a project manager usually manages the outputs from the various media production activities is through using a database, not necessarily to store the media components, but to store their details, so that a search for the name of a file, for example, would provide all necessary information about it.
In comparison to other phases, more problems are likely to occur or surface during this phase, because translating designs to reality is often more difficult than generating them. Even though design would have been assessed for feasibility, unforeseen problems commonly surface, some of which can be so difficult to overcome. This means that the chances of a project starting to fall behind are greater during this phase and good management is needed to minimize them.
4. Postproduction Phase
Assuming website implementation is complete and the client still wants it because it has not gone ridiculously over deadline, the next set of tasks are final evaluation, delivery, final sign-off, clean-up, and archiving, all of which constitute the postproduction phase, which should not be confused with the same phase in media production, which comprises, for example, the cleaning up of media, editing, and addition of effects, which fall under the production phase here.
4.1. Final Evaluation
The evaluation plan outlined during the initiation phase would have been reviewed and refined before this point. You would also have ensured that the iterative evaluation of prototypes were carried out all through the development process, so that the final evaluation will just be about testing to see whether or not the site meets the overall project requirements. The evaluation is comprehensive. For example, testing is done on different systems and browsers (particularly major ones), different browser configurations, different Internet connection speeds, and different devices. All bugs, problems, and data from users are recorded and reported consistently, using the method that would have been specified under the evaluation plan in the proposal. This ensures that necessary corrections and changes are made in an organized way that is easy to monitor. After the initial corrections and changes, further tests may be done to find more functional problems, and this is repeated until there are no more obvious ones, at which point, the system is formally delivered and any subsequent problems are dealt with under the maintenance plan negotiated in the proposal.
4.2. Delivery and Final Sign-Off
For delivery, a domain account with adequate specifications is acquired, as discussed in Chapter 26. Delivery is also accompanied with well-written documentation that contains, for example, information on how to solve possible problems. Issues relating to the copyright of the media produced during the project are also dealt with. The types of rights issues that commonly arise in a Web project are discussed in Chapter 28.
The final sign-off is the formal indication that all the objectives of the project have been delivered, evaluated, and found by the client to be acceptable. The final payment will also usually occur at this point, if applicable. If a project is large, then there would have been prior intermittent sign-offs and they would also have been tied to payments. The maintenance plan is also implemented at this final stage. Where maintenance will be provided by a different company, necessary maintenance materials are transferred to them. If you will be taking on maintenance, a separate contract would usually have been signed. Irrespective of who provides maintenance, the contract does not usually start until after a grace period, during which any missed problems are fixed for free by the developer company, provided no other company has tampered with the product in the intervening time.
4.3. Closure
An orderly closure (i.e., cleanup and archiving) is important after a project has been completed, so that aspects of the project can be referenced quickly and easily in the future. This may be necessary for various reasons. For example, a completed project may be opened again in the future, either because a client is commissioning additional work or for maintenance purposes. It may also be because the elements used in the project need to be applied to a new project for someone else.
The orderly closure of a project involves various tasks, such as backing up all relevant files (more than once, if possible) in an orderly fashion and according to the predefined plan set out in the proposal, after which the originals are usually removed from the immediate work environment to make room for new projects. For extra security, backups are sometimes stored at different locations. To wrap up a project in a meaningful way, a project review or retrospective analysis may be done to consolidate the lessons learnt from the project and how they could be applied to future projects. If a team is involved, then this would be in the form of a final project meeting.
Source: Sklar David (2016), HTML: A Gentle Introduction to the Web’s Most Popular Language, O’Reilly Media; 1st edition.