The Ideal Web Team (part 1)
By Peter-Paul Koch
Anyone can tell you that to create a good Web site you need a good Web team. Less people can tell you exactly how this team should go about creating the site. This two-part series presents one view of the ideal Web Team.
The ideal Web team consists of three sub-teams:
- The client-side specialists, who create an attractive, clear front end.
- The server-side specialists, who create a smoothly operating back end.
- The supporting specialists, who make sure that the other two sub-teams can do their jobs.
After some general remarks, I’ll present a closer look at these three sub-teams and the disciplines that should be represented in them.
Number of team members
The total Web team shouldn’t consist of more than seven people. When working with six other people you can (barely) keep track of who’s doing what and what you yourself can do to help him or her. When the team rises beyond seven, this becomes impossible.
At least half of the team members should be seniors in their area of expertise. Not only can they quickly answer practical questions and devise workable solutions, their experience will rub off on the newbies.
Responsibilities
There should be one person responsible for the entire site. Usually, but not always, this is the project manager. Writing proposals and reports, or having other team members write them, is the easier (though not necessarily simple) part of the job. Making sure that the final site actually resembles these proposals and reports, or that the client understands why it doesn’t resemble them, is by far the harder part.
Each team member, except for the newest of newbies, should also have clear-cut responsibilities, details of which are given below. Although these responsibilities may initially appear very simple (the graphic designer is responsible for the graphic design of the site), there are some catches.
The most important catch is that defining specific responsibilities may lead to insularity. In that case, each team member does what he or she has to do, but completely forgets the other team members. (“Well, my design is brilliant and according to the wishes of the client. I don’t care about browser compatibility, that’s your problem.”)
Avoiding this insular way of working is the responsibility of all team members. The first step is to make sure that all team members know about each other’s responsibilities.
The second step is to make sure that team members ask each other for advice. For instance, if the interaction designer decides on a certain feature that impacts the graphic design, he or she should immediately consult the graphic designer.
This example points straight at the third step: team members should respect each other’s knowledge and experience. If the interaction designer maintains that a hierarchical navigation is a bad idea for this particular site, other team members should defer to this judgement, since the interaction designer knows more about navigational structures than the other team members.
In this way, the team can come to some synergetical way of working in which the specializations of the various team members strengthen each other. This is not an easy process, but it’s very worthwhile.
Supporting specialists — the project manager
By far the most important supporting specialist is, of course, the project manager. It is impossible to overestimate the importance of the project manager; if the project management fails, the whole project fails. It’s as simple as that.
Most of the time, the project manager will have the overall responsibility for the entire Web site, as discussed above. The project manager is always responsible for financial matters and planning. He or she is also responsible for communication with the client and within the team—plenty of work for one team member.
The project manager is required to communicate any important, not so important, or even trivial information to the other team members so that everyone knows what he or she has to know.
Conversely, all team members must do the same. If you run into problems and you don’t tell your project manager, it is unlikely that he or she can do something to help you. You might even get new tasks or responsibilities because the project manager decides, based on information received, that you have enough time to handle them.
Communicate with each other! Although the project manager should take the lead, all team members must take this requirement very seriously.
Other supporting specialists
Occasionally a Web site project will employ other supporting specialists, like system or server administrators. Their job is not to create the Web site but to make sure it can run on the system(s) meant for it.
Finally, some projects need an account manager. The difference between an account manager and a project manager is crucial here: while the project manager is responsible for the project, the account manager is responsible for good relations with the client.
In general, the account manager has less feeling for the actual work that’s being done, and more feeling for the moods and expectations of the client. He or she may, therefore, be too easily persuaded by the client to change the planning or scope of the project.
Although this may seem to serve better client relations (faster delivery = satisfied client), in fact it doesn’t. When the Web team is confronted with such changes, even aside from practical issues, it will lose its motivation.
In extreme cases, the team may even decide to ignore the account manager, which will surely lead to problems later on, apart from destroying his/her credibility with the client.
While the project is running, the project manager should make the final decisions, not the account manager. This is easier said than done, but the team should at least attempt to convince the account manager that it’s better not to interfere too much.
To be continued
In my next column, I’ll continue this investigation of the ideal Web team by discussing the server-side and client-side specialists.