Lecture 4: Web Project Management Essentials 2

Reading: Chapter 9, 10, 11 (Staging, Launch and Closure)

•    The Value of Templates
•    Capturing Essential Lessons Learned
•    Using Lessons Learned with Templates

What you will learn in lesson 4:
1. How to use customize templates to save time
2. The importance of Lessons Learned and how to get others to contribute
3. How to use Lessons Learned to improve your templates

In the last lesson we learned about essential communication skills, how to manage risk, how to prevent late content which can make you miss a launch date and how to deal with change requests that can cause budget overruns.

Now we look at the value of templates and the creation and use of lessons learned so that Web Project teams utilize their experience to continually improve.

The Value of Templates
Web Project Managers must have excellent communication skills. They must be able to communicate technical information to non-technical people. In Chapter 4 the authors discuss the value of communication and the types of communication skills a Web Project Manager needs to develop.

One tool that can aid communication is to prepare templates for all important documents. In the textbook there are 17 Checklists, many of which are details on documents to use to keep the Web Project on track. These need to be tailored to each project, but that doesn’t mean you should write them from scratch each time – in fact, having a set of customized templates is preferable.

You will have no problem finding templates on the Internet. Some companies try to charge hundreds of dollars for their templates – don’t bother buying them. You will do better to get some of the free templates and customize them for your needs. In fact, you will do much better.

Not sure which templates you need? A good place to start is the “interactive Project Management” textbook. In fact, to make things easy, here are the documents the book recommends and the checklists or page numbers where they appear:

Cheat Sheet List

Management Plan Cheat Sheet 001
Strategy & User Brief Cheat Sheet 002
Requirements Document Cheat Sheet 003
Blueprint Cheat Sheet 004
Agreement Cheat Sheet 005
Production Plan Cheat Sheet 008
Development Plan Cheat Sheet 010
Testing Plan Cheat Sheet 014
Communication Plan Pg. 151, location 2588 in eBook
Lessons Learned document Pg. 170-174 in book, location 2872 – 2926 in eBook
Project Closing Document (See Template example file)


I’ve created some example templates for you in the Word document,   Web Project Management Template Examples You will find links to a number of template examples which should provide a basis for you to customize the templates yourself.

Customize your templates by reading through the templates you download and thinking about what in the template is applicable to the type of projects you do.

Note: you would not sit down and create all these templates in one intensive sitting or even in a sustained effort over several days. Use the time between projects (okay, you probably don’t have time between projects) and create one or two templates to use. Chances are you already use a Project Strategy document and a User Brief (also called a Creative Brief.) If you don’t already have these set up in template form take the time during the Requirements Definition stage of your next project to turn the documents into templates with as much information filled out as you can complete without knowing the project specifics. Save this as a template and make a copy to use for your project.

If there is an aspect of Web projects that always seem to frustrate or create problems due to communication issues during the project process, think about whether there is a project document that can help you improve the process.

Perhaps you have a hard time getting your client/stakeholders to read your status reports or there is confusion on every project about the Web Process itself. Try creating a Communication Plan that states what communications will take place, how often and what response is required.

Filling out all the relevant information you can ahead of time will save you time during when the project reaches a hectic pace. Things you can add to the plan include:

  • Background company info
  • Your team members’ names and contact info, including email address and twitter or skype info if you and your client/stakeholders use social media for project communications (note: this is not necessary or recommended unless everyone is already using these vehicles to exchange info or very comfortable with this technology.
  • Table of Contents – set it up ahead of time. These documents can grow lengthy on some projects and it is easier to locate information with a TOC
  • Set up your headers and footers

Final note: If you work for a small design firm or even for a small in-house Web team, make your documents look professional. Your clients/stakeholders will get copies of these documents during the project (many of them will require signed approval) and/or at the end of the project. You only enhance your image when you include your logo, company contact info, etc. For comprehensive documents such as the Web Project Specification document sections like the Communications Plan or Testing Plan can be removed by the testing team to distribute without the bulk of the rest of the Spec document.

Make sure everything looks like a set.

Don’t be afraid to add and delete information and sections from your templates – that is how you make templates work for you. Remember, the entire idea is to make you more productive. You work for your Web team, not for the template. Project documents should not be busy work. If they don’t make the process easier for the Web Project Manager to manage, they shouldn’t be used.

Capturing Essential Lessons Learned

Let’s face it, after the project is launched second guessing is natural, after all hindsight is a wonderful tool – and that is exactly the point of Lessons Learned. Write down all those wonderful thoughts of how you could have done things better – and use them the next time you have a similar project!

The book mentions Lessons Learned (pages 170-174, but doesn’t emphasize the concept. Actually, Lessons Learned is the key to a Web team’s success and that includes the Web Project Manager.

Usually Lessons Learned are mentioned at the end of a book on Project Management, as it is here in the “Interactive Project Management” book. The reason is logical, you realize how you could have improved the project management process or done a task faster in hindsight. However, you don’t need to wait until a project is over to see how a different strategy might have worked better.

A Web Project Manager and everyone on the Web team should be looking and recording Lessons Learned from the beginning of the project. Here are some ways you can collect Lessons Learned: Before the project starts review the Lessons Learned document from previous similar projects (if such a document has been written.) Then incorporate those lessons in your Management Plan.

During your status meetings (or daily SCRUM meetings) listen carefully for approaches that worked for the Web team – did the graphic designer find better pricing on a stock photo site than the site used before?

Did the programmer have a revelation on how to set up a search script so that the results are more accurate based on an article she read? Capture that in the Lessons Learned document

Did your stakeholder misunderstand the project process and tell you how the misunderstanding could have been avoided? Capture that in the Lessons Learned document.

Did a subcontractor miss their deadline? Capture that in the Lessons Learned document (with a note to try out a new subcontractor.)

Once you start looking for Lessons Learned you will find the first few times they are everywhere. But after a few projects there will be fewer and fewer to record. Why? Because you and your team are learning from each project to become more efficient and more professional.

After the project is completed, ask the Web team members to review their Lessons Learned. The Web Project Manager doesn’t know everything that happens during the project. There might be some great lessons that in the momentum to finish the project, the programmer or designer or tester didn’t report. Capture that information at the end of the project.

Don’t be afraid to ask the client/stakeholder about their experience. Are there things they wish the team had done differently? Was there anything they wished they had known before the project started? Document this information too in the Lessons Learned document as it will lead to more satisfied REPEAT clients/stakeholders.

Note: To benefit from Lessons Learned an environment must exist where the Web team is encouraged to report their mistakes and missteps. Otherwise they will be afraid to tell you if they discovered a better way to do things. For the Web team and the company to benefit from Lessons Learned the goal must be for everyone to be dedicated to the team’s success. If people are chastised for mistakes, then this approach will not result in team success, but in finger pointing and hiding errors.

Using Lessons Learned with Templates

Use Lessons Learned to improve your Web Project Management Templates. After documenting Lessons Learned review each template to capture the great ideas collected in the templates. In the rush of a project, it is easy to forget those lessons learned, but if the templates are improved based on the lessons learned, then the lessons will truly be incorporated into the project process.

What you learned in lesson 4:

  1. Customize document templates to save time and to improve performance with each project
  2. Collect Lessons Learned from the beginning of the project. Encourage the Web team to contribute their lessons learned too. Ask stakeholders for their experience and look for ways to make their experience better.
  3. Incorporating Lessons Learned into document templates will insure proposed changes are acted upon in the next project


Alternative 1: Create a Documentation Plan identifying which, if any, templates you will use in your Web Project Process.

Alternative 2: If you currently have a set of templates that you would like feedback on submit those instead. Indicate if there are any templates you lack but plan to start using.