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

AuthorTracy July 22nd, 2009 Comments View Comments

Creative

  1. Have the lead developer on the project review the comps with the designer

    2. The lead developer should check the comp design against the wireframes and discuss any concerns they might have with the designer prior to sending them to the client.

  2. Have the creative director review and sign-off on comp designs before sending them to the client

    3. The creative director should complete a final review of comps/artwork prior to sending them to a client because they provide the necessary criticism that improves the strategy, usability, creative approach, and overall vision to a project.

  3. Have the lead designer QA the final comps before sending them to the client

    4. It is important for designers to take ownership for their own work and get used to doing their own quality assurance prior to comps being delivered to a client.  Things they should scrutinize are: element alignment between comps so that components don’t jump from one page to another, branding is correct and up to date, all comp pages link correctly, comps match approved wireframes/storyboards and match the content map, and spelling is correct.

  4. Make sure the project manager and account manager examine the final comps prior to sending them to the client

    5. Do the comp designs match the wireframes and meet the SOW deliverables?  Has anything been lost in translation? Is the client corporate branding/identity accurate and meet their requirements?  Have the comps been proofread for grammatical/spelling errors?

Build

  1. Ensure all concerns with the comp design have been addressed by the designer and lead developer prior to build

    2. Upon approval of the comp designs, the designer should provide documentation to the development team, which outlines the specifics of the design features.  If there are any questions from the developer they should be addressed prior to build.

  2. Confirm that the folder structure has been set-up correctly by the development team and that the lead developer has reviewed it

    3. Make sure that the build team has set-up the folder structure appropriately at the onset of the project build.  Double-check that the folder structure has been created correctly following any client-specific guidelines (if applicable).

  3. Ensure that the lead developer has provided the project manager with a document that lists all third party libraries/components from the developer

    4. As mentioned before, having this documentation eases future versions of a project since it is often the fact that the original developers will not be on the revision.  Be sure to put them in the project folder for future reference.

  4. During build, the designer should monitor the build to ensure the build matches the comp designs correctly

    5. Make sure that the designer is scheduled to check-in occasionally with the development team to ensure that the build matches the comp design.  Examples of items that are often overlooked:  font kerning, form field alignment, margin and padding, and error messages.

  5. Developers should QA their own work on all platforms specified in the SOW

    6. During development, looming deadlines often impede the quality assurance that is necessary from the developer(s).  Remind the team members of its importance and advise they should be checking that all links work, pages load (including error pages), and all site functions work.  Also, be sure to check that that any fonts, content, imagery, and legal requirements are complete. Finally, be sure to check that the site functions correctly on all platforms that were outlined in the SOW.

    Do your own QA of the build prior to submitting for alpha/beta review to ensure that all deliverables outlined in the SOW have been implemented and operating correctly and that final copy is integrated and proofread for spelling/grammatical errors. Finally, confirm that tracking has been implemented properly.

Quality Assurance

  1. It is best practice to have a development freeze while QA reviews the build

    2. If QA must begin while the development team is concurrently building, then a clearly defined document should be delivered to the QA team that outlines what should and should not be QA’d.  Hopefully, this will not happen very often, as it’s not best practice and will adversely affect your project’s budget.

    If the deliverable calendar has been pushed back, be sure to reschedule alpha/beta testing to ensure your QA team is available when you need them.

  2. Provide a functionality checklist that outlines all deliverables, hyperlinks, copy, page links, etc

    3. Has a functionality checklist been provided to the QA department prior to QA build?  It should include, but not be limited to, what browsers/platforms to QA the project on (this should also be noted in the SOW), as well as include a list of team members responsible for the various aspects of the project.  Having this list assists the QA team when they are assigning project tickets. Furthermore, this document should clearly outline project specs, functionality, tracking consoles login information, what QA should look out for, etc.  Any known functionality issues should be clearly defined.

  3. Copy matches the final copy deck

    4. All copy should be proofread and matches the final copy deck with no spelling errors.  If copy is in a different language, make sure that all special characters show-up correctly in both upper and lowercase versions.

  4. Test the product OUTSIDE your development environment

    5. A pool of testers should be available to review the projects outside your office environment.  Confirm with the QA team leader that these tests have been completed.

Launch is not the end, but the beginning

  1. Confirm with QA that the project has been reviewed once it’s pushed live

    2. Occasionally there will be a hiccup once a project is pushed live. As such, a thorough QA of all functionality should be performed in the live environment.

  2. Post Project Audit

    3. Be sure to schedule a “post project audit”, with your team, to review the key learning’s during the projects development cycle.  This is a great way to ensure that mistakes aren’t repeated on future projects as well as highlighting what went well to repeat them in the future.

  3. Revisit that wish list

    4. Now’s a great time to revisit those items that your team, or the client, wanted to include that were out of scope.   The best projects are the ones that are enhanced and evolve over time.

I hope that you find these reminders valuable for your own process checklists and that they help contribute to the success of your projects.  Should you have any of your own tips to share, feel free to comment below.

Pages: 1 2

« Prev Post Tags : , , Next Post »
  • Nyneena

    Very interesting. I love organization and sounds like you have it well put together. Thanks for the intro into the Internet world…

  • http://www.saturized.com Zoran Usancevic

    Yes! Tracy, great one! I really hope we’ll see more articles about project organization and management in the future. Thank you for sharing.

  • http://www.islanddesignstudio.com IslandDesign

    Great stuff Tracy, keep it coming!

  • Michael

    This article is very helpful. Where I work many, if not almost all of these points are an after-thought. Sometimes some of these points are implemented but often left on the back burner. Only after release do many of these points start to become important. So speaking to the first heading, more individuals need to make it their state-of-mind, that is very true. Thanks for information and your insights!

  • http://pm2pm.blogspot.com jeff

    Fantastic list. Tied together with a bit of overall philosophy and an organizing principal and roles and responsibilities, you would have a service delivery process – typically the domain of project managers.

    For more on that role:

    http://pm2pm.blogspot.com

blog comments powered by Disqus
blog_qa_image

previously