Project Management for Web Sites: Solid Pre-Production is the Key
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).