I became obsessed with project management and ‘process’ after an incident several years ago at HotWired. We were launching a Cocktail, HotWired’s modern-day speakeasy, after a lengthy but fairly smooth design and production schedule. It was our first experiment with framesets and we kept running into little bugs that delayed the launch that day from morning, to afternoon, to on into late evening. I was in the production department and my job, in addition to managing the schedule, was to integrate content into the live site and check that the HTML and code actually worked. This generally was all the quality assurance testing we did — and instead of weeks, we usually had hours. Not surprisingly, we ran into many unexpected problems with Cocktail and its frames, but all of us in production and engineering tried our best to fix the bugs so the site could still launch that night.
What triggered my obsession was not the chronic lack of time, or the many errors that kept appearing, but a certain anonymous coworker. He had recently started at HotWired, and hadn’t worked on Cocktail. He just happened to be at the office that night. Just at the worst possible moment, when everyone was panicking and trying to come up with a quick fix, he approached me.
Instead of offering to help, he said, “Pam, we really need to talk about process.” At that moment, his comment could not have been more loaded. He might as well have said, “Pam, this is the biggest mess I’ve ever seen and you have no idea what you’re doing.” Obviously, I was irritated by his unsolicited comment. I just walked away and continued doing my job until the site launched a few hours later.
As irritating as the remark was, to a certain degree he was right. Most of the time, sure, we didn’t know what we were doing. We had no road maps to follow and we invented the process as we went along.
However, we did manage to produce new sites regularly and the launch of Cocktail was by no means the worst we’d experienced. We posted a new set of stories to the site once a day by hand-coding HTML without the luxury of the fancy content management systems the kids have these days like Vignette or Interwoven. And we usually had a good time working together. Sometimes things got rough, but we got through it as a team.
Still, I started thinking there had to be a better way: a way to protect ourselves from having to do everything at the last minute; a way to get the work done and still go home at a decent hour; a way to keep people like anonymous coworker from feeling compelled to make irritating comments.
The information in this article comes from many sources. Much of it may sound familiar because — well — project management isn’t rocket science. People have been doing it for a long time in many disciplines other than Web production, such as software and game development. I’m going to describe the position of project manager and some of its challenges. Then I’ll go through the process I use at my current workplace, Red Industries. Red Industries consists of just four people, yet we follow this process carefully because we value our down time. Using this process, we’re able to handle large jobs yet still take weekends off. It works for us — and hopefully it will help some of you avoid another late night at the office.
What Is Project Management?
The project manager directs the building of a website from the first brainstorming session to the site’s launch and wrap up. It’s up to the project manager to keep the process on track and the trains running on time. It’s a sometimes thankless job that involves cracking the whip, providing therapy to depressed or otherwise high-maintenance employees, dealing with politics and, worst of all, controlling the purse strings on the budget.
Those are the downsides. But there are just as many great things about being a project manager. You get to work with people from all Web disciplines, and assembling diverse groups to work together on a common goal can feel pretty good. You deal with people constantly throughout the day — on the phone, in meetings, and one on one. It can be overwhelming, but if you like helping people and solving problems, this could be the right job for you.
What you need to know
If you were to look at a job description for a project manager, the laundry list of requirements would probably read like this:
- Ability to manage a team
- Experience dealing with clients
- Excellent verbal and written communication skills
- Strong attention to detail
- Ability to create schedules and budgets — experience with Microsoft Project a plus
- Basic knowledge of standard Web tools such as Photoshop, HTML, XML, and other Web software and languages
- A knowledge of browser work-arounds, and general Web do’s and don’ts.
You can gain these skills by working in a variety of Web disciplines, such as production, design, engineering, advertising or marketing (for more about what each of these jobs entail, check out Webmonkey’s The Right Web Job for You). I prefer production because it’s my professional background. Production people need a wide range of skills to do their job. They understand more than anyone in a Web department how much tedious work goes into building a website, and as a result are good at estimating how much time it will take to complete a segment of work.
If you want to get into project management, the best way is to show your boss by taking on more responsibility. If you see an inefficiency, find a solution and take the initiative in getting it implemented. Demonstrate that you play well with others and are a role model for good working practices. Have no fear — your boss will notice. If not, then leave and take with you as much experience and as many office supplies as you can carry. Apply for a project manager job somewhere else where your initiative will be appreciated.
Right Job for You?
Consider the pros and cons before you take on a project management job. It’s stressful work, but can also be very rewarding. You’ll have to deal with tasks that appear to have nothing to do with building an actual website: living up to your boss’s expectations, managing a team, vying for resources, and dealing with criticism and politics.
The factor that will most motivate you to better manage a project is accountability. Being a project manager means being accountable for everything from engineering to design to production. If a deadline is missed, or some work is done poorly, it’s on your head. If you didn’t account for all the stages and the project takes twice as long and costs twice as much, they are going to blame you. This will motivate you to stay on top of the schedule and the people doing the work. If you procrastinate don’t even bother trying to be a project manager. Everything everyone else does is dependent on you making decisions, and getting others to make decisions.
Of course, accountability can be taken too far. I worked at an ecommerce site during its first launch. They hired a San Francisco Web development company to do the bulk of the site’s production and design under brutal deadlines and were quickly on their third production manager (the first two quit).
Project Manager No. 3 tried to impress the management by promising to be available 24/7 . He gave us his office, page, cell, and home phone numbers so we could ask him anything at any time. This was not a good idea and soon he stopped answering his phones altogether and was barely accessible via e-mail. The key is to schedule and set boundaries so you don’t need to be accessible 24/7.
Your most time-consuming task will be managing people. Obviously you can’t do everything yourself, although sometimes you’ll wish you could.
Language is a big barrier — design, engineering, production and editorial all use different words and make different assumptions about problems. The project manager needs to understand all these and make sure the engineers know what design is talking about (and vice versa).
I did some consulting work setting up a process for a Web company last year. They began correctly by brainstorming and setting a feature list, but by the time they started work, the engineers’ and designers’ interpretations of those features were very different. They entered the integration phase with essentially two different products because the project manager was having problems getting the two sides to collaborate.
Meet regularly with your team one-on-one. This can be quick and informal, to see how they’re doing and whether they have problems or questions. Many people find it easier to share their problems one-onone rather than in a large meeting. Don’t make it easy for people to complain. Try to solve problems quickly and nip conflicts in the bud. If it’s a something that will affect your project, deal with it immediately regardless of feelings or politics.
It helps to be involved in day-to-day work on a project and not just overall issues. If you understand what your employees are doing, you can better manage them. If they see you working alongside them, they’ll have more respect for you and will trust that you understand the challenges they face.
Defend your employees if they are put in a difficult situation. Do you have the guts to stand up for your employees, defend them when they need it and inform them when they aren’t living up to expectations? You picked your team for a reason — stand by them and make sure they have the tools and information to get the job done.
Do you have the authority you need?
Before taking on the job make sure you’re given the authority you need. It is essential that your role be clearly defined and explained to your employees and to other departments at your company. At the ecommerce site where I worked briefly, I wasn’t given sufficient authority by my boss. I was hired to create and run a production department but was never presented to other departments in the company as the head of anything. It made dealing with them impossible. I disliked the job so much that I soon gave up and quit. I felt guilty about leaving my new employees, but figured whoever replaced me might have a better chance of getting something done.
Project managers are easy targets for criticism because the success or failure of a project is often dependent on their decisions. I know it’s impossible not to have at least a slight ego — especially if you like being in charge. But don’t let the endless commentary get to you. You’ve signed on for a reason — you like to lead others, and part of leadership is the ability to deal well with stress and criticism. Now that I’ve covered what it takes to be a project manager, I’ll go through a general process to get you started managing effectively.
Effective Project Management
The qualities of a good project manager can be described nicely by adapting Larry Wall’s Three Great Virtues of a Programmer: Laziness, Impatience and Hubris. My version goes like this:
Laziness: The desire to put great effort into reducing overall energy expenditure such as late nights and weekends in the office. It drives you to create a labor-saving process that other people will find useful, and document what you developed so you’re not answering so many questions. Hence, the first great virtue of a project manager. (And hence, this article.)
Impatience: The anger you feel when the process isn’t working properly. This makes you create a process that doesn’t just react to your needs, but actually anticipates them. Or at least pretends to. Hence, the second great virtue of a project manager.
Hubris: Excessive pride, the sort of thing Zeus zaps you for. Also the reason you write (and maintain) a process that other people won’t say bad things about. Hence, the third great virtue of a project manager.
Depending on the size and budget of your Web project you could be working with millions of dollars and dozens of people around the world, or you could be building a five-page site about your dog Sparky. I just finished a job where the client was located in Switzerland and Italy, the design team was in San Francisco, user interface was in New York, business affairs in Atlanta, and engineering in India.
However small or big the site is, you still need to start a project with some kind of a process, whether it’s the one I’m going to describe below or one of your own.
Once you have an acceptable process framework, document it and lead the entire staff through a training session. Be certain everyone understands it and agrees with it. Once you have a structure, it can be can improved and used over again and again. The staff will get used to it and find it becomes second nature. They’ll wonder how they managed without it.
Be consistent. If it’s going to help, everyone needs to follow it even if you think you can get by without it — just this once. The process is a tool that keeps the work predicable and easier to manage.
Create a checklist: For your own sanity, put together a checklist of everything that must be completed to launch the site. Pass it by others in your team in case you forget something. It’s a good place to list things like ‘Check that group server permissions are set up correctly’ or ‘Arrange for approvals and reviews of UI and design.’ You can even assign dates to create a schedule for yourself.
I’m going to take you through the four basic stages of development for a Web project. You need to understand what happens during each stage in each department. Only then can you schedule and hire properly. This takes practice, but soon it will become second nature.
The four general stages for getting a Web project to launch are: Discovery, Planning, Production and Engineering Integration, and Quality Assurance Testing and Wrap-up.
The discovery phase is when you figure out the basic structure and purpose of the website.
Brainstorming: The first step is to brainstorm. I suggest accompanying this with a client questionnaire. Write down all the questions that need to be answered about the project. Some sample questions: “What is good/bad about the competition?” “Who is your primary audience?” “How will you promote your brand with this website?”
One client I worked with at an entertainment company would meet with the Web team and tell them to create something amazing like no one had seen before on the Web — and that was usually the extent of his direction. The UI team and designers — thinking they had creative freedom — developed original ideas and concepts that the client always disliked because, unfortunately, they couldn’t read his mind. The client must provide detailed direction and not rely on the designers and writers to develop the concept. The project manager needs to extract this information from the client and force him/her to make decisions.
Requirements doc: The brainstorming meetings should produce a written document that outlines the site’s scope and feature set. This document acts as a starting point for everyone — the client and the Web team. If, at the conclusion of the brainstorming sessions, you can all sign off on the contents of the document — usually called a requirements document or work order — you’re in pretty good shape. Research: Once everything’s down on paper, the departments need to do some research. For example, the designers should check out the competition’s websites. The engineers should check the feasibility of the programming the site will require. The user interface designer should start testing scenarios to show whether the site is going to serve the needs of the client’s audience. UI could draw up some rough schematics of the website.
Scheduling: Using the requirements doc and the research results from tech, design and UI , you can start initial scheduling and budgeting. Determining the schedule is your toughest task because so much rides on these decisions. My advice is be pessimistic and pad the dates. The best scheduling tool is Microsoft Project. I’ve tested a number of other project management software packages, and nothing works better. MS Project makes creating a schedule and changing it as needed simple because it automatically recalculates the schedule and budget. With a little practice, you’ll be creating beautiful schedules in no time.
The launch date: Find out what is really setting the client’s desired launch date. Is it an event, a third quarter stockholder report, or the desire to launch an excellent well-tested product? It’s usually not the latter. Here are a few rules to try to follow when setting the schedule. However, budget pressures will always win the argument.
1. Never plan press or party events around a Web launch. No matter how hopeful or optimistic management is, this is a recipe for agony and disaster. An example is the holiday media blitz that was attempted by the e-commerce website I worked at. It was the worst combination of untested software and optimistic scheduling.
The company spent millions of its precious venture capital on a print and television advertising campaign that was to run concurrent with their launch. Media buys for print and TV happen months in advance. So the buyers went ahead and purchased the ads because they felt tremendous pressure to launch the site before the holiday buying season. So instead of a quality product determining the media campaign launch, the ad campaign set the launch date. At launch barely half the sales actually made it through the bug-laden purchasing process, which turned off the majority of customers who came to the site after seeing the advertising campaign.
2. Trust your schedule and stick to it. Don’t let anyone convince you they’ll get something done faster than you know they can. If it’s going to take six months, that is how long it will take. Careful thought takes time. Good design takes time. Writing solid code takes time. These things can’t be rushed. However, you can look for alternatives.
Set up an online store with Yahoo or Bigstep instead of building one from scratch. Build the site in phases. Establish priorities and calculate how much of the site can be built in three months versus building everything in six months.
3. If a delay is caused by the client or by some other unforeseen catastrophe, stick to your schedule or push the launch date back by as many days as necessary. Unfortunately, while this is nice in theory it usually doesn’t work.
I worked for Lucasfilm’s Star Wars website during the launch of Episode I. The full length trailer was highly anticipated and Lucasfilm wanted the first online version to be Apple’s high-quality QuickTime and not a grainy video taken from inside a theater. Everything was moving along according to schedule when we realized that because of time zone differences, Australia had permission to exhibit the trailer a day earlier than theaters in the United States or Europe.
This opened up the possibility that a fan might videotape the trailer in a theater and post it on a fan website. On our side of the planet, we weren’t ready to post the trailer — but it didn’t matter. We worked all night setting up the pages, reviewing the QuickTime and posted it a day early.
4. Use virtual space. Create a simple Intranet where the team and client can view and download documentation. Include all the information you can on the Intranet and get the staff in the habit of checking it first for schedules and documentation. This will greatly reduce the number of repetitive questions.
Get e-mail aliases set up and get people using them from the very start. Identify tech and design contacts at the client’s company and get their e-mails and various phone numbers. Remembering email@example.com is much easier than keeping track of a half dozen client, contractor and internal e-mail addresses. Create a reliable server workspace for your project. You may need more than one. For example, engineers are much more likely to bring down the server than the HTML coders, so allocate a special place for them to do experimental work. Get the proper passwords and permissions system set up for everyone.
During stage two, you and the team establish every element of every page. By the end, you’ll have developed a document that describes visually and textually how to build the website. The brainstorming is over and it’s all about the details.
Site map: Start by designing a site map. A site map helps you plan the structure of the site. The process of sketching a basic diagram will force you to consider the many issues you’ll face when building the site.
Schematics: Once the client signs off on the map, start visually describing each page with simple schematics. You need to stress to the client that these are not design documents. Make them as simple and unattractive as possible so there is no confusion. The schematics define the content for every page. This is necessary for editorial to anticipate the text they’ll write, and for designers to know the elements they’ll be designing.
Functional specification: The next step is to take the schematics and describe how each page functions. The document that will emerge is called the functional specification. Engineering and production should contribute to it, adding details about the server, site structure, security, and so on. This information is essential to the Web team when they build the site. The details need to be reviewed and approved by the client before work starts.
Once the functional spec is in good shape you can revise the schedule and start dealing with staffing. But until the functional spec is complete and approved by the client, you won’t know what the real budget and schedule will be. The client may cut something substantial from the project that would have required a whole team of programmers, so waiting to hire them would be wise.
I worked on one project a small design firm was doing for a big luxury goods company that kicked off three times. Three times before a contract was officially signed, we rushed to find design and Flash resources. Three times we had to call them back after they were hired and tell them the project was on hold. Though the client appeared to be entirely supportive of the project, and had legitimate reasons to pull out, it was very frustrating and also made us look bad to our contractors.
You will most likely need to revise the functional spec several times. This will require spending hours with the client reviewing the site map, schematics and functional description until the site is what they want. Deliver a final budget and schedule with the functional spec, but don’t do any additional work until they’ve signed next to the X, in blood. Most companies charge for the functional spec, and for good reason. The client can take the functional spec to any company. Just because your company put it together doesn’t mean you get to build the website.
Design treatments: You shouldn’t design the site until the functional spec is complete. However, your designers may want to produce some initial comps since, without a doubt, the first thing your client will ask is what the site will look like. Design will use the functional spec and schematics as a guide for designing the pages. If possible, design should also have final text so they can design using the right words.
I was a freelance project manager for a San Francisco design team creating an international web portal site. They designed lovely pages in English with consistently sized title images. Then we realized these titles had to appear not just in English but in Japanese, French, Spanish and German. This changed the entire nature of how to approach the design and would have affected the launch, so the client decided to go with English-only titles.
Plan for design reviews and give the client enough time — at least two or three days — to review the design. Always ask for written feedback. This ensures that the client has reviewed the design carefully and critically. Ask them specific questions about the design. They may say they don’t like the website colors, but what they really mean is they don’t like the yellow outline on the featured product images and in reality everything else is OK.
Design and production specifications: Once the design has been completed, the design and production staff should work together on a style guide. The style guide is a document that details color, font, sizing and naming conventions. The designers should be available throughout the production process to review and create any new or replacement art that is needed.
Stage three is where the bulk of the work happens, but getting this work done well depends on the planning and documentation completed during stage two. The important thing about stage three is followthrough. It’s the project manager’s job to make sure the team sticks to the plan. Check that everyone is following the functional spec and style guide, that they are using the proper naming conventions and version controls, and that backup files are being saved on the server.
An example of where good planning went bad was during my brief stint at the e-commerce site. The production company they hired went through extensive planning and developed beautiful documentation and style guides. However, when it came to actually building the site, they didn’t pay enough attention to the work their contractors were doing. Shoddy work by a single part-time HTML contractor delayed the site’s launch by weeks.
Instead of following the naming conventions and size specifications set by the documentation, he took it on himself to give all the HTML pages and the image references totally random names. So, when my team placed our image work on the server, nothing worked. It was a terrible crisis and caused multiple meetings, lots of yelling, and revisions galore.
No one works well in chaos except contractors, which is why they can charge very high hourly rates. Contractors are most effective if their work goals are clearly defined before they arrive at the office. This highlights the importance of good documentation. If standards aren’t set, each person will use a system that works for them. Trust me, each system will be very different and will introduce unnecessary errors into the website.
QA and Wrap-up
It’s important to leave enough time for QA testing after a project is completed. This is possibly the first opportunity your client will have to see the project working and moving. They may have very different expectations and you need to time to change things if they’re unhappy.
Plan for QA before it starts. Develop a simple QA testing matrix that describes the different combinations you’re testing for. Use a software package to track the bugs, or create simple text files where people can enter information about the bugs they encounter. Assign bugs to engineering and production and do additional testing to make sure the bugs were actually fixed and new bugs haven’t been introduced.
Make sure your client understands what they’ve been given and that they will either hire your team to maintain the site or train their inhouse staff. If they’re going with the in-house staff, those employees should have participated in some of the website development.
At the end of each project do a wrap-up with your team and the client to review what worked and what didn’t. Now is the time to change your process and update documentation before the next one begins. This is also the most psychologically damaging part of the process for a project manager because it’s everyone’s chance to tell you what they disliked about the process. But that’s just the way it is.
Above all, have a party. You all worked hard and tried your best, so you might as well celebrate a little!