Developing Effective Websites

A Project Manager's Guide

Roy Strauss, Patrick Hogan

• Publisher: Routledge
• Year: 2013
• ISBN:
  9781136133015
• Edition: 1
• Topic: Computer Science
• Subtopic: Programming Games
• Index: Computer Science

Is your website project out of control?Every website project needs a manager. Developing Effective Websites describes Internet technologies in plain language and helps you see beyond your expertise to the big picture. It does this by drawing on established software project and management principles. Like any project, effective management of website development starts by understanding and balancing the constraints of time, resources, and tasks. You can deliver your project on time and on budget, by following a process that includes: · Analyzing the requirements of users and your market
· Developing a workplan for the site and breaking it down to tasks
· Scheduling with Gantt and PERT charts and measuring slippage for more accurate revisions
· Estimating cost by the budget-first or design-first methods
· Using the team development process and covering all the necessary roles
· Aligning contractor and client interests to create a win-win relationship
· Following an iterative development process for designing, prototyping, and building out
· Applying software testing principles to website development
· Making hosting decisions and planning for maintenance

1

Project Management in Three Dimensions

Managing complex projects, such as websites, often entails many conflicting issues and concerns. You may think the time available to accomplish the task is insufficient, the job is too complex, or the budget is inadequate. Determining the proper course of action can be difficult. Understanding the three dimensions of project management—time, task, and resources—can help you get a grip on things.

Without an understanding of how these three factors interrelate, you can easily slip into a reactive mode, constantly responding to the crisis of the moment. Once these three factors are understood and appreciated, however, they become the reins of control by which you can effectively manage the development and maintenance of a complex website.

These three factors of time, task, and resources constantly interact in a Web project, changing priorities and fluctuating in importance as the project advances. Understanding how they interact gives you a valuable and objective perspective that helps demystify the development process. The project manager must juggle these factors and make decisions about tradeoffs and compromises along the way.

In Dynamics of Software Development, Microsoft’s Jim McCarthy writes: “As a development manager, you’re working with only three things: resources (people and money), features (the product and its quality), and the schedule. This triangle of elements is all you work with. There’s nothing else to be worked with.”

These three factors can be represented as the three points of a triangle (Figure 1.1).

THE THREE PROJECT FACTORS

Time

For the purposes of a website, the available time is indicated in the project schedule—specifically, the period from start date to completion deadline; that is, when the site is to “go live.” The schedule relates to the nature of the task (as designed) and the available resources (people and equipment). As a rule, the more resources available and the simpler the design, the faster the task can be accomplished, but only to a point. One might suppose that a project that takes one year with only one person working on it would take six months with two people and one month with twelve. In practice, however, adding more people does not reduce the amount of time at the same rate; a point of diminishing returns occurs when the overhead of communication and administration to coordinate the myriad of people and activities negates the increased work actually being performed.

Figure 1.1 The project management triangle: time, task, and resources.

For example, during the development of an expanded, highly interactive version of a map publisher’s website, the development team included more than one dozen internal programmers, artists, and content/editorial personnel, as well as external website developers. With so many team members, it became increasingly difficult to coordinate their activities and ensure effective communication to avoid wasted and duplicated effort. With the release date approaching, it became evident that some of the individuals were working at cross-purposes, thereby actually slowing down the development process. The only solution possible at this point was to reduce the project staff to only those who were essential to the completion of absolutely necessary tasks. By doing so, the project was able to pick up speed and finish on time, albeit with the minimally required content and functionality.

You may also have experienced this effect of more resources slowing down development when working on a project that has fallen severely behind schedule. Management, seeing a problem, decides to solve it by throwing more people at it. This actually slows the project down further, at least temporarily, as the newcomers get equipped, trained, and worked into the process. The work often is not speeded up appreciably, even after these new recruits have been assimilated, because of the increased overhead for administration and communication within the team.

Some tasks, by their nature, take longer and depend heavily on the talent, skills, and experience of the individuals performing them. Software programming is the best example, where the effectiveness of different programmers can vary by several orders of magnitude. An experienced, creative programmer may complete a task in a few days, whereas another programmer lacking experience or motivation may need several months or may be incapable of completing the task at all. Even a particular individual’s temperament may be more or less well suited for a particular task. In some situations, a programming task can be speeded up considerably by hiring the right programmer, or slowed down a similar amount by adding several inappropriate programmers.

Occasionally, the fastest way to complete the project is not to change anything. Even though progress may appear to be going exceedingly slowly, maintaining the existing situation may be the most efficient option.

Task

The task refers to exactly what is being built. Task expresses the scope of the work to be performed: the magnitude, complexity, and design of the project. For a website, this consists of the site design, including quantity of content and programmatic features. This definition of the end product determines the number of people necessary to produce the site, the skills they must have, the kind of equipment they will need, and how long it will take them to complete the first version of the site. For example, all else being equal, a Web presence consisting of six pages with a basic design takes less time and fewer resources than a database-driven, searchable informational site with e-commerce capabilities.

Resources

Resources refers to the funding for the project and all that it purchases in terms of people’s time and services, materials, and equipment. In general, more funding enables a faster development schedule (time) or a more complex, higher-quality site; however, as noted earlier, if a project has fallen behind schedule, adding resources (people and money) does not always speed it up. Adding people to a project that has fallen behind schedule can cause it to fall even further behind if the wrong resources are added or are added at the wrong time. When more highly skilled and specialized resources are needed, they should be added early or not at all. For example, adding programmers early in the project can speed it up, but adding them toward the end may well delay the project even further. Frederick Brooks, in his software project management classic The Mythical Man-Month, wrote: “Adding manpower to a late software project makes it later.” The maxim expresses such a fundamental truth that it has come to be known as Brooks’ Law.

The project’s fixed variable, and thereby its limiting factor, is often resources. When no more money or people can be thrown at a project, the time (schedule) and task (functional requirements) variables are where adjustments must be applied. When a project with fixed resources runs into difficulty, you must simplify the design or extend the deadline or a combination of both.

SEEING IT IN THREE DIMENSIONS

In the heat of a project, all three factors—time, task, and resources—are ever changing, constantly interacting variables. The job of the project manager is to constantly balance these three factors (Figure 1.2). Suppose management transfers a key team member to another project, restricts access to equipment, or cuts the budget. As a result, the project either takes longer to complete (time factor changes), becomes less ambitious in scope (task definition changes), or both. Likewise, if the design is scaled back (features are dropped or simplified), the project can be finished faster or with fewer people. The main goal of project management is to constantly balance these factors in flux.

Figure 1.2 Balancing the three project factors.

Your consciousness of the interplay of these three factors and ability to act on them will make you a master of the development process rather than its slave. By manipulating these factors, you can exert considerable control over the project. Your command of their interplay will help you:

•	Explain schedule delays.
•	Say “no” to design changes and “feature creep” with good reasons.
•	Justify increased personnel and equipment requests.
•	Recognize opportunities to improve project dynamics.

Only by examining these factors on an ongoing basis can you identify trouble spots and proactively address growing problems. Once a crisis hits, your analysis will help you learn from your mistakes, but you will fall short of saving the project at hand. Prevention always works better. Project management software can help you monitor progress. When you watch these factors on a daily basis, you can make minor adjustments along the way and avoid crises before they develop.

For example, our project developing an e-commerce website for an association publisher was slow getting started because of a resource problem. The plan for the site required a full feature set, including an online catalog of books and promotional items with cross-referencing ability, user surveys, a guest book, customer reviews, and multiple searching options. The project was adequately funded and scheduled accordingly. As development began, however, it became apparent that not enough people were working in content development. This limiting factor set a slower top speed for product development, lengthening the schedule requirements in other project areas. Next, the effect of the lengthened schedule lowered the project’s priority in the eyes of the external programming team, compounding the scheduling problem as the work took a backseat to more active projects. As development drifted on at this slow pace, the site was at risk of stalling entirely. With little to show in the way of progress and the deadline approaching, the project managers feared that their funding might be withdrawn. Saving the project called for drastic measures.

First, the project manager trimmed the task by narrowing the feature set to the minimum necessary. Next, a new content lead came to the project and staff was brought over from other projects to quickly populate the backend database with content. The project manager rescheduled the due date with the external programming staff and sought their commitment, with assurances that the project was on track and would move quickly. The abridged first version was ready to go live in a few months. In terms of the three factors, a shortage in the anticipated resources was addressed by lengthening the time factor and decreasing the task.

A natural reaction in such a situation, however, is to make up for lost time by pressuring programmers, while avoiding any adjustment to the project. Although this approach may improve appearances in the short term, it is usually not effective in the long haul. You may inspire spurts of super-productivity, but this pace is difficult to sustain. Work patterns gravitate toward their equilibrium. If you must apply pressure to change programmers’ behavior, then you may have to keep the heat on for the remainder of the project. As the programmers become desensitized to such pressure over time, you will need to become increasingly firm. This tactic can create an uncommunicative, dysfunctional, and potentially explosive situation as the project grinds along. By the end of the project (if you make it that far), you may no longer be on speaking terms with the programmers. Costs emerge in employee dissatisfaction and the long-term quality of work. You will be subject to the law of diminishing returns. People working excessive hours tend to make more mistakes and usually do not work as fast as they normally would. So while you take on additional cost, you may not gain proportional benefits in productivity. Asking team members to work longer hours is usually beneficial only at the end of the project.

A better course of action is to identify as early as possible the source of the problems, without blaming individuals. Then try...

Table of contents

• Cover Page
• Title Page
• Copyright Page
• Dedication
• Contents
• Preface
• 1 Project Management in Three Dimensions
• 2 Technologies of the Web
• 3 Scheduling
• 4 Estimating Costs
• 5 Analysis and the Project Plan
• 6 The Web Development Team
• 7 Contractors and Clients
• 8 Designing and Prototyping
• 9 Build-Out and Production
• 10 Quality Assurance Testing
• 11 Going Live and Beyond
• Appendix 1 Recommended Resources
• Appendix 2 The Proposal Process
• Appendix 3 Integrated Product and Process Development
• Index