Project Charters for Web Development

The first thing I hear from people when I discuss web project management is, “Ugh. How boring.”  The web developers live in a world where technologies change every few weeks, and the thought of taking time to manage a project—versus diving into the tasks at hand and getting things done—doesn’t make initial sense. I like to explain it this way: “Everyone does project management. If you don’t know project management principles, then you are doing it wrong!”

For most people, the problem begins the very moment they get a new “project.”  Before the work begins, you need to clearly define what is a project, so you know when to use project management principles. At the University of Wisconsin-Platteville, we use a simple rule in IT: a project is anything that will take over 120 hours or $10,000.

Once you know what is a project, you can then utilize the tools to help manage them.

Why use project management tools?

That answer is simple: use project management to make order of the chaos. Using project management helps you establish priorities and manage expectations. They help keep things on task and projects within scope, so your shop can run more efficiently. The bottom line: they allow you to be more nimble.

What are the project management tools?

A lot of the project management tools are forms, documents, communications, reports and discussions. It doesn’t seem to magical when it is described like that, but the results can be amazing. The first thing you need to understand is that if you are working on a current project, and you have not started to use these tools, you can’t do anything now. The only way to use project management is to start it off from the very beginning.  So let’s review one of the most common project management tools: the Project Charter.

The Project Charter

A project charter is a document used to identify the exact details and expectations of the proposed project. Identify who is the project sponsor, a.k.a. who’s paying for this or who is the end decision maker (NOT A COMMITTEE) for the project. Identify the problem, describe the project, and the end goals. From here, develop the scope of what the project will contain, and most importantly, what it will NOT contain. Have a section to list a few critical success factors, and what your assumptions are going into the project.

Next, identify the authority of the project. Find out who has control over the money, and who is responsible for the oversight of the project. Sometimes there are multiple people here. You also need to list what milestones exist for the project, but keep this at a very high level. You don’t need to get into details yet—that comes later with the work break down structure and the project plan.

Now that you have identified the problem in detail, and the authority, you need to define the team. Make a list of all of the people who are affected, and give them roles and responsibilities. You must have one (no more than two) project sponsor(s). You must identify the key stakeholders who will be able to affect your project, as well as the subject matter experts within the area who will do the work. List the technical team and identify their specific role for this project, as well as listing any required resources (software, hardware, meeting rooms, etc.).

The last part of your charter should include the project leadership’s points of contact—get all of the information together in one spot. If there are terms being used that your functional users won’t understand, add a a glossary. You also may need to add appendices of reports, forms, or anything else that is applicable to the project.

There are five simple rules for Project Charter documents:

• Rule #1: Never start to work on a project unless you have a signed project charter by the project sponsor. No matter how “critical” something seems to be, or how much pressure you are getting from above, simply do NOT start the project until is that charter is completed and signed.
• Rule #2: Identify the right people. Nothing is more frustrating than a project that begins with a project sponsor who has no authority when decisions must be made. In the same aspect, do not forget to identify ALL of the stakeholders.
• Rule #3: Project scope is critical. You MUST identify everything that is in scope, and most importantly what is OUT of scope.
• Rule #4: Do not attach a detailed budget to the project charter. Keep things simple and brief in the charter. You will have other project management tools to manage the procurement, budget, and time resources of staff.
• Rule #5: Be patient. Be firm. You are changing how your office runs by expecting your customers to sign a project charter before you begin. They will not like it, and will push back. Be patient and be firm. If you are really going to succeed, you must have this in place.

Take these first steps and get everyone on the same page with your project charter. It will make a huge difference when the project sponsor signs on the dotted line!