Tips to Assist a Manager Throughout a Project’s Development Cycle

blog_qa_image
QA is not a phase, it’s a state of mind.

In the crunch created by limited manpower, looming deadlines and last minute revisions, it isn’t hard for a “best practice” process to get derailed.  To help keep your projects on track, I’ve compiled a list of some steps that seem to get overlooked most often during a project’s development cycle.  As a QA manager, I’ve found that having a checklist to reference is an invaluable tool to ensure that things aren’t overlooked.    True quality control should happen throughout a project lifecycle, and not just during a predefined QA phase.  Of course, every project is different, but the items outlined below represent some of the best practices from my experience and I hope you find them useful.

The all-important Scope of Work

  1. Schedule a meeting with your quality assurance (QA) team to review the timeline and calendar that will be included in the SOW (Scope of Work).
  2. It is important to ensure there is enough QA time blocked off on the calendar, prior to sending the SOW, to the client.  QA has a tendency to fall on the back burner of a project’s timeline but it will no doubt affect final budget and launch date if time is not properly allotted.  The time required for QA will vary from project to project depending on the project’s length and complexity.  Make sure to allot time throughout a project’s life cycle, during each stage of production, instead of only scheduling time at the end.

  3. Include a “development freeze” on QA initiation prior to a beta review, within your SOW, and on the associated project timeline
  4. For all projects, it is best practice to have a ‘development freeze’ for 1+ days for quality assurance (the number of days is determined by the sophistication of the project).  Make sure this development freeze is scheduled on your timeline and discussed with the client.

  5. Discuss search engine optimization (SEO) with your client prior to completing a SOW
  6. Always give thought to SEO strategy. This obviously does not apply to all projects, but SEO should be considered and planned for, as an item in the budget, just like “account management” or “creative reviews” are.

  7. Define tracking and analytics for the project and include it in the SOW
  8. Prior to finalizing the SOW, determine with the client if tracking will be utilized.  If it will be, converse with your senior technologist (or developer) for recommendations, so that they are included within the final project scope.

  9. Have a senior technologist (or developer) review the projects SOW deliverables prior to client delivery
  10. Your senior technologist (or developer) will be able to “red flag” any items that might hinder a project’s success with regard to budget/timeline and functionality issues.

Project Initiation

  1. Ensure a “version control system” has been set-up
  2. Has your project been set-up on a “version control system” such as Subversion SVN?   All projects should be stored on a version control system to maintain current and historical versions of files.  It is best practice to follow this rule even if it’s a one-person project.  Your team leader should meet with the senior technologist (or developer) to set-up a repository, as it should be tied to a project number.

  3. Ensure a staging/development server has been set-up
  4. At the beginning of a project, a staging development server should be set-up.  Relying on a live environment for assembling, updating, and testing is risky and inevitably delays Quality Assurance.

  5. Make sure the development team has outlined/planned for tracking prior to beginning build
  6. Many times during development, tracking is implemented at the end of a project and becomes a burden if done as an afterthought.  In contrast, when planned from the onset, it is a painless and an easy element to implement as it can be done parallel to development.

  7. Make sure a bug-tracking tool has been set-up prior to the project beginning
  8. Email should not be used to track bugs. Email makes it extremely difficult to keep track of all “issues” and bugs that crop up during the different phases of a project. Dedicated bug-tracking software like Bugzilla or Lighthouse does a much better job of keeping bug reports orderly and ensuring they are corrected.

    Notify all the team members, involved on the project, where they will be tracking their comments prior to beginning wireframes/storyboards.

  9. Ensure that formal meetings have been scheduled between the designer and lead developer throughout the duration of the project
  10. Meetings should be scheduled between the lead designer and the lead developer at different phases of the project.  Meetings to discuss site flow, wireframes, comps, and development phase should be part of your initial timeline calendar.  These discussions will guarantee that the design can be programmed and built.  Any “red flags” should be hashed-out between team members and adjustments made to the build plan based on solutions. Having these meetings, prior to client deliverables, will make certain that you aren’t promising deliverables that could be problematic or unachievable.

  11. Make sure that all team members (including the QA department) have the information architecture document, content map, and project requirement list
  12. The delivery of the information architecture document, content map, and project requirements to your team members and QA, prior to wire-framing/storyboards, ensures that everyone on the project understands the information architecture of the project.  Additionally, having a meeting to review, these documents, will answer any “red flags” that a designer, developer, QA specialist may have prior to jumping into wireframes/storyboards.

  13. Distribute any brand guidelines to the creative, development, and QA teams
  14. Brand Guidelines should be provided to the designer, development, and QA team prior to beginning a project to guarantee that everyone on board is using the correct corporate identity.  The last thing you want to happen is to present a comp to a client with outdated logos, fonts, and/or colors that aren’t up to date/standards.

  15. Ensure that the lead developer/senior technologist, creative director, project manager, and account manager have reviewed/signed-off on the Wireframes/Storyboards prior to delivering them to the client
  16. The lead developer/senior technologist should check the wireframes/storyboards and discuss any red flags with the designer.  Additionally, once the lead developer has assessed them, the creative director should complete a final review prior to sending them to a client.  It’s also a good idea for the QA team lead to review the wireframes/storyboards since they catch things that your team might not have noticed.  The project and account managers are also responsible for reviewing the wireframes/storyboards to ensure that they meet the deliverables that were originally outlined in the SOW.

  17. Define what development platform will be used prior to beginning build and be sure it is documented in the project folder for future reference
  18. It’s a good idea to keep records that outline any development platforms on a project.  For example:  what version of Macromedia Flash is being used, what JavaScript is being used, specific Flash components, Papervision version, customized components and WordPress version.  Additionally, if certain components/versioning is known prior to the SOW it is recommended that they be added to the document.  Having a document that outlines these features will help when a “Phase 2” project release is scheduled especially if the original developers aren’t going to be working on the updated project.

Pages: 1 2