jim.shamlin.com

Analysis and the Project Plan

The author speaks of "analysis" as a phase where a project plan is considered - my sense is that he is saying that just because something can be done doesn't mean it ought to be done. Examples given include delivering video via a Web site whose audience is primarily comprised of modem users, or using a Web site when a brochure would be more effective in reaching the target audience.

Fundamentally, a project is an effort to fill a need for a person (or group of people). Looking at the validity of that need, and the characteristics of the group of people, are keys to understanding whether it is worthwhile to move forward on a given project: whether the audience will benefit from the project in a specific way, and whether the method described in the project is the best way to fill that need.

The author speaks of gathering user requirements by means of surveys, interviews, and focus groups. I'll skip the description, as I already know that stuff. The key is: user requirements are critical, rather than allowing project sponsors to dictate what the customers (or others who will benefit from the project) need. These studies can address the need in general, and features in specific.

He also speaks of analyzing the competition: it's important to know what they're up to, and predict how they are likely to react to your move - especially since Web sites are very public, they will be aware of what you are doing. And if competitors are already doing something, it is important not merely to do the same thing, but to do it better.

Planning

The first step in the planning process is the requirements specification: what core functions should the project have, and what features should be added. Each of these should be determined by the information gathered in the analysis. The specification should indicate whether each function is a "must have" or a "nice to have" to assess its importance and ensure the critical parts are not omitted - and the difference is what is critical to accomplishing the project goals.

Once the requirements are know, a work plan can be developed. The author provides an outline for a work plan, thus:

Once the plan is complete, approval to proceed (especially to obtain the resources) is obtained.

1. Overview
   1. Executive Summary (who, what, where, when, and how without jargon, in one page)
   2. Goals and Objectives
   3. Marketing Considerations
   4. Effect on Existing Business
   5. Maintainability
   6. Special Issues
2. Task
   1. Requirements Specification
   2. Design Specification
   3. Quantitative Evaluation
      1. Content to produce or purchase
         1. Photos
         2. Text
         3. Other (graphics, sound, video)
      2. Data to produce or purchase
         1. Databases
         2. Data files
         3. Other
3. Time
   1. Milestones Defined
   2. Milestone Target Completion Schedule
   3. Gantt Chart
   4. PERT Chart
4. Resources Required
   1. Personnel
      1. Technical (roles and skills)
      2. Nontechnical (roles and skills)
   2. Equipment
   3. Software and Materials
   4. Outside Services
   5. Web Hosting
   6. Testing
   7. Special Technical Services
5. Further Considerations
   1. Assumptions
   2. Risk Factors and Mitigating Them
   3. Technical Factors (new development considerations)
   4. Others
6. Appendix
7. Approval

Rogue Projects

There is a note on rogue and skunk works projects that proceed without approval, often "borrowing" resources from other projects.

The rogue project is done by a junior manager who wishes to get a project to a specific point before taking it in for approval, on the assumption that management will feel they have committed significant resources and might as well see it through. This can be a career-ender, as it is inevitably discovered.

The skunkworks project is approved by management, but done piecemeal by separate groups to keep it below the radar. This, too, is inadvisable, as people will talk about their work, and others will discover what's really going on and call attention to it.

The best advice in all cases is to do things above boards - or if you have a secret project, treat it as a standard project, but keep the players in the know about the confidential nature of the work.

---

Contents