Project Management for Web Sites

January 31, 2007 at 4:52 pm | Posted in General, Management | Leave a comment

Developing Web sites, whether it be for Internet, intranet, or extranet purposes, one thing is certainly clear: Having the right project-management process is essential. I’m not talking about your average skill sets of being organized and knowledgeable about the project. I’m talking about the detailed thought process involved that makes professional Web developers stand out from the rest.

Whether you are an actual programmer or not doesn’t matter, but understanding programming and what is involved does. There are certain criteria for project managers who deal with the Web that differ from people who manage projects of a different nature. The best way I can summarize how to be the best manager of a project geared for the Web is to sanely have multiple personality disorder. By this I mean you really need to put yourself into many people’s shoes and be able to think like them in order to develop a Web-based project from start to finish. Solid, professional project management is more than the task of wearing many hats. It goes much deeper. Professionals need to be able to completely shift mindsets and think from several different perspectives, and that’s what makes them so successful. Let’s take a typical Web site and break down the process.

Getting Started Before You Get Started

For the sake of keeping this article to an article (and not a book), I’m going to assume you can take the concepts here and appropriately apply them to the type of project you are tackling. Let’s set the scene. Your client comes to you and says they want a Web site. Well, what is the proper Web production methodology? The most important step you can take is preproduction. Thorough preproduction. Before you jump in to design anything or write a single line of code, you need to ask questions. I typically ask my clients 30 to 50 questions right from the get-go (a mini-interrogation, if you will). And this is only a start. Understanding everything your client wants is imperative. No matter how much information your clients give you, keep in mind that they are not Web developers and don’t know all of the information to give you, let alone give it up-front.

Here’s where you have to be able to think beyond the basic questions of how many links you want and what type of content you’re planning to put in your site. Consider what will happen when (not if) your client changes his mind about something…how will that affect the architecture you established for the site? Can it easily be changed? Is the design and layout built in a way that the site is expandable? Can you easily add and remove functionality without needing to reprogram half of the site? Which language(s) do you use? And will these languages be supported where the site will be hosted?

We’ve had clients request that the site be developed using ASP (Active Server Pages), only to find out (fortunately still in the discovery phase) that this site will eventually be moved in-house to their IT department, which runs everything off of a UNIX server. Could you image how upset you and your client would have been if you had developed the entire project and then found out that it wouldn’t work on their servers?

There are a million questions that need to be asked before you do anything. Are there any specific requirements that need to be met? Sometimes, there are questions that aren’t even obvious to ask. When working with the federal government, there are certain laws and regulations that must be met when developing Web-based technology for them. There’s a little thing called Section 508 compliancy that deals with developing pages that meet the accessibility of information requirements. Here is where you have to ask yourself, “Okay, the government is not like a typical corporate client, so what might be different? Are there any regulations that I need to worry about?”

Hopefully, you can role play these games BEFORE you develop anything. Whoever your clients are, try to image every possible scenario and see if you can have them answer as many questions as possible so that after you start to develop the site, you have to do it only once (unless they are willing to keep paying for all those changes).

Establishing the Guidelines

Now that you’ve asked your client every possible question relevant to the project, it’s still not time to start writing code. The next thing is to lay out your project roadmap. This is when you can use one of those project-management software applications (or if you’re a techno whiz, write your own program). If you’re not comfortable with that, break out pen and paper—but for God’s sake, write stuff down. Start with writing a creative and technical brief. Take all that information you just received from your client during the “question-and-answer” period and write up a statement about what needs to be done. Write up the goals and objectives of the project, both creative needs as well as technical requirements. Just as important, write down the things that your client doesn’t want. These creative and technical briefs will help keep you on track as you develop, especially the larger the scope of the project and the more time needed to complete this project. Another way this will help is if you have multiple people working on this project. Be it staff or freelancers, in-house personnel or outsourced resources, everyone will have the same directives in front of them. No one can say they weren’t told.

Next, draw a schematic or flowchart of the site. It doesn’t matter how you do this. I still use Quark Express to design my layouts. Any software that can create an organizational chart (whether automatically or manually) can be used. Be as detailed as possible. This serves many different purposes. First of all, this schematic is a great checklist to make sure that you’ve covered all of the areas that need to be developed. I recommend that once you have it complete, have your client sign off on it. Many clients may not understand it (again, they hiring you to develop the site because they are not developers, so you may need to hold their hands and explain the process of how the site will look and function from this line diagram). But once they sign off on this, it protects you from the client changing his mind every five minutes on what is expected in the site and where it belongs.

Most standard contracts that we write let a client know that if they change something once signed off on, it’s going to cost them more money, take more time to develop, or possibly both. This will also help you plan your programming strategy by seeing how things link together and possibly avoid a lot of redundancy. You’ll be amazed at how quickly the site makes sense to you (or doesn’t make sense if it’s a bad site conceptually) when you visualize the entire site on paper. But you’re still not ready to begin programming.

Timing is Everything

Now that you see the site, you can start developing your timetable for development. This means figuring out the best way to approach this project. Is it in sections vertically, completing all levels of one specific topic or tackling all similar levels of the hierarchy at a time? Once you figure out which direction will be the best approach from a programming-functionality standpoint as well as a time-saving process, it’s important to guesstimate how long each “section” will take you or your team to complete.

A good project manager not only considers all of the aspects that need to be developed, but thinks about the order in which they need to be developed. Does one person’s actions affect those of another individual, or are they completely separate? If one person is late by a day (or two or three), how will that affect the rest of the project? Can you schedule the programmers before the designers? Are there things a programmer can be doing while the designer completes his work? Precision scheduling is the next key to success during the preproduction phase of this project. Without accurate schedules, the project is sure to fail. Again, whether you use a software application such as Microsoft Project or Excel, or simply break it down on a grease board in your office, the key is to cover all necessary aspects.

Here’s where it’s important to understand programming and what it takes to perform the tasks at hand, even if you’re not a programmer. The same holds true for design. How can you set realistic timeframes if you haven’t a clue as to what it takes to complete certain tasks? I can create the most detailed schedule on paper, but what’s the point if it’s useless? Could you imagine telling your client that you can have an entire extranet application for their global manufacturing company that will allow vendor orders, track inventory, automatically alert accounting, process billings, and allow sales personnel to monitor the status of the job 24 hours a day, 7 days a week complete in under a week? No matter what the budget, there’s no way in the world to complete a project like this, test it, and launch it in under a week. So knowing what it takes to build each and every aspect of the project is imperative. If you don’t know, ask someone who does. Talk with the people who you plan on using how long it will take them. Not all tasks are cumulative (unless you’re working by yourself). Remember that many tasks will overlap.

Establishing the Right Team

The next logical checklist question during the preproduction stage is “Do you have the resources available?” Making sure you have the right people with the right tools who know how to complete the tasks relevant for this particular project is important. Do you have a person competent to deliver each aspect in the set timeframe you just established in the step above? That’s also why it’s good to ask them how long it will take a certain task to develop. Even if the average developer only takes x amount of time, that’s all irrelevant if this person requires twice that amount of time and he’s the one doing it for this project. As you select your team, make sure to list the tools that will be used for this project. Also ensure that each person involved in this project has the right set of software and hardware necessary to complete their portion of the project. Nothing will slow a project down more than if someone on the team decides to deviate from the set plan and uses something that is incompatible with the rest of the team’s work.

Now, the tricky part…the true art of project management…setting start and due dates for every aspect and every person involved. Take a project with a six-month development time. Everything can’t be done at once. Well, which aspects need to be done first? What elements need to follow? Can anything wait, or will that hold up someone else? That’s why it’s not only important to issue start dates, but (just as importantly) issue due dates. If a graphic designer is given the go-ahead to start designing the look of the site but waits on his end of the line too long, how will that affect the programmer who wants to begin testing some of his code to see how different things will affect the overall layout of the page?

Give everyone a realistic timeframe in which they need to finish that particular portion of the project. And as a part of the original creative brief, make sure that they provide the right deliverables. Completing a task on time is one thing, but if it’s not what was needed in the correct format, being on time is pointless, anyway.

So how many different people do you have to “be” to effectively project manage a Web site? You’ve bombarded the client with questions for research, you’ve mapped out the information into a written brief with an accompanying flowchart, you’ve read Jason Miletsky’s Web Photoshop books in order to think like a designer, you’ve read every article on InformIT’s Web site to understand programming from every alternative aspect, and you’ve even used the non-pictorial side of your wall calendar to plan the milestones of this project. How many does that make?

Oh, and don’t forget one more personality that you need to incorporate: the ability to be your own devil’s advocate to challenge everything that you just worked out and make sure there are no holes in your plan. If you have successfully done this, you have completed part one of the project management lifecycle—the preproduction phase. Now, you are ready to jump in and start developing. Look for future articles as we continue to break down the aspects of project management during the production process and what to do at the end of the project.


Leave a Comment »

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Blog at
Entries and comments feeds.

%d bloggers like this: