Sample Web Design & Development Project Work plan & Methodology

Web Design Project Methodology:

The following is an example description of our methodology for developing projects and executing the services we sell to our clients as well as the communication channels used to ensure clear, effective communication at every level.

Phase I:  Project Inception

Creation of Work Plan & Clarification of Project Goals by FDG Web staff.

To understand the business case and needs behind the individual specifications listed, we must return to our clients a work plan. The work plan is not merely a reiteration of the specifications, rather it is the mapping of the proposed solutions and how they will meet the client’s goals for each phase of development.

The Work Plan consists of:

1. 1. The Software Framework, System, Software or other solution(s) implemented to meet the client’s particular needs.
   2. The modifications & custom programming to be made in order to meet the client’s needs.
   3. The step-by-step workflow for each custom, “non-housekeeping” function included in the solution(s).
   4. The determination of the project area(s) and what version controls will exist.
   5. The areas that are considered to be “Discovery” by either the client or FDG (or both) and the workflow for guiding everyone through the Discovery Phase for features, process and functionality.
   6. The “content plan” which details what assets will be provided, who is responsible for integration of content and in what format it is to be received in. The content plan may have several different processes based on the client’s needs and the functionality of the website.
   7. Who the project manager and staff responsible for the work plan are and their contact information.
   8. Where the project will exists in our Project Management system and how easy it is for the client to interact with it from their browser or mobile device.
   9. What the testing plan will be and why we use the “Exploratory Testing Method” as opposed to manual scripted testing approach.
   10. An outline of the expected times in which meetings or presentation of deliverable will occur and what decision-trees may need to exist. It is important to make sure that the client understands when a critical decision point is going to be reached for an individual function, feature or development milestone. The Work Plan helps outline these things in a more natural language.

Upon submission to the client, the client will sign off on the plan or suggest revisions. The sign-off can occur as a unilateral agreement via email or fax, but just not phone.

 Phase 2:  Design Concepts & Framework

Depending on the overall schedule and specifications, we will have a creative cycle that includes the creation of one or more flat mock-ups (JPG/PDF) that acts as an initial wireframe for the design process.

Example Website Sitemap

This is done to track all iterative builds in the design process and allow viewing or reference to previous mock-ups in the design process.

Upon completion of this process, we will have a viable wireframe and walk through of all primary pages and features of the website and the client will sign-off on the concept and design framework. The sign-off can again occur as a unilateral agreement from the stakeholders via email or fax, but just not phone.

 Phase 3:  Web Development

Development occurs concurrently in most cases, with the design team working on the HTML/CSS templates for all pages, views, modules and features of the website – while the development team begins building the database schema, framework and installation(s) that occur prior to design integration.

Each team as a Lead and that lead is the main point of contact for the work being performed. The Lead or the Project Manager may be in contact with the client directly, however it is the PM’s responsibility to manage and organize all contacts so there is no confusing on who is responsible for what tasks.

Typical the breakdown looks as follows:

Project Manager
Designer (Lead)

• Additional Designer

Programmer (Lead)

• Additional Programmer
• UI Programmer (Design Integrator)

Leads may talk directly to the client in order to get information and direction. All communications via email get logged into the Project Management System. If a phone call results in a decision or action(s) to be taken – the Lead is responsible for re-capping or summarizing what was decided and posting it to the Project management System.

This is an easy to take step that allows a summary of what was discussed to be quickly verified with the client.

Development will have different phases depending on the project. Phases will be outlined in the Work Plan. Besides the actual design, development, integration and eventual deployment of the project – all development must include:

1. Complete testing of deliverable(s) across all target browsers.
2. Complete testing of all alternate content across all target devices.
3. ADA compliance testing (if applicable)
4. Load & stress tests for all target hardware.
5. Security testing, anti-SQL injection, securing all inputs and reviewing vulnerabilities and vulnerability management (E.g. mod_security rule sets)
6. All software, open source, third-party apps and technologies are logged into the Vulnerability Database so we can be notified of any changes, patches or updates that must be applied irregardless of where we are at in the development or release cycle. E.g. http://secunia.com/
7. User testing (blind or focused)
8. Client has a release checklist and who to contact with edits, changes, updates or bug fixes upon release.
9. Client understands what information they should try to ask for from users who report problems or bugs in the system.
10. Client stakeholder testing and sign-off

 Phase 4:  Release

Release is ready when the client has signed-off on the deliverable(s) and functionality as demonstrated. Release adheres to its own schedule depending on the needs of the client.

In the case where a project is migrating to a new server, and will involve a DNS switch – we must ensure that the client and their staff understand what that will entail and how best to blunt any trouble typically associated with DNS propagation.

In the case where an internal DNS switch is made, the client will advise us as to what systems will be impacted and to what degree.

Regardless if it is a new site, replacing an older site or a hybrid … both the client and FDG Web will agree upon a release schedule and when the system should not be used until the release is complete.

In the case of ecommerce deployments we will typically have a synch of customer and order data prior to the release – then synch again after the release is completed.

In the case where a website, intranet or application can been build on an existing domain, we will synch any production data (if applicable) backup the BETA build, backup production again and roll the BETA into the root of the website.

As soon as the new site/project is live, we will rebuild the Google XML site map, verify and resubmit it again to get the site indexed correctly.

As soon as the project is released and active, we immediately undertake the following steps for live, production testing:

1. Complete testing of deliverable(s) across all target browsers.
2. Complete testing of all alternate content across all target devices.
3. ADA compliance testing (if applicable)
4. Mod_Rewrite for friendly urls is functioning correctly.
5. All forms submit and connect to their mail servers.
6. All transactions perform correctly.
7. All robots.txt, exclusion files or other items designed to hide the website has been removed where applicable.
8. All 300/301 redirects have been put in place to redirect traffic from non-functioning urls to their new equivalents.
9. A catch-all redirect is put in place for all other 404 errors, etc.
10. All debuggers used have been switched to IP-only so no errors are displayed to users.
11. All other items identified in the project’s launch list, as developed internally on http://launchlist.net/ are tested again.

Phase 5:  Evaluation & Maintenance

Now that the website or application has active users, we can quickly determine any additional needs or troubleshooting that may be required.

The project manager may begin to receive change requests or bug fixes from client. Requests may also begin to come into Leads depending on the area of responsibility and who is making the request.

• All bugs are logged and tested.
• All updates are made in a timely manner.
• All requests which appear to be feature-requests are logged and discussed with the Project Manager who can formulate a business case or explanation to the client.
• Many clients will just forward user feedback directly to FDG Web staff .. which is valuable in the case of bugs, user issues, etc, however, suggestions or features to be added should first be presented to the client prior to engaging any further development. Users should not be modifying the clients specification upon release is the issue we would be trying to filter out of post-release troubleshooting.
• Post-release we will have refreshed the BETA area and all development, bug fixes or additions are added here prior to promoting it to production.
• Post-release we will have scheduled a time to discuss with the client any post-release issues or unfinished features, or third-party integration that may still need to be implemented.
• Maintenance shall be performed according to the schedule outlined prior to release.

Post-release evaluation shall be organized and executed in conjunction with the client’s desires by the FDG Web project manager. While we have formal surveys, we can submit to the client, often the client doesn’t want any extra homework or obligations at this phase. In this situation we will discuss the satisfaction of the project with the client in-person or over the phone and publish the notes internally for additional feedback and/or action.