Thanks to Intel’s Gordon Moore, it is a common belief that the processor chip speed of technology doubles every 18 months. This law has spread to practically all areas of technology, which, in turn, means the role of an IT project manager can be expected to change just as rapidly. IT project managers everywhere struggle with keeping teams, budgets, and goals focused. IT project management becomes even more tedious when you consider the economy, the instantaneous expectations of stockholders and management, the constant turmoil in the IT industry, and the flux of each team member’s commitment to their own career.

According to the Standish Group, a respected IT industry analysis and research firm, IT project management is getting better, but still out of control. Consider these statistics from their 2004 version of the CHAOS report:

While this news is encouraging, it’s still far from success. Some would argue that these tighter values put more requirements on the project manager because they have less “wiggle room” on their projects than just a few years ago. You could also make the argument, however, that the education, expertise, and granular approach to project management provides more successful projects than ever before.

Still, there’s that 23 percent of project cancellations and the 51 percent of projects that are late, over budget, or both. How can this be? Why do so many projects fail from the start? Projects fail for many different reasons: other projects take precedence, team members lose sight of the purpose of the project, and project managers try to do the work rather than lead the team, among others. At the root is a fundamental problem: vision. Vision, in project management terms, is the ability to clearly see the intangible and recognize the actions required to get there. One of your jobs is to develop, nurse, and transfer the vision to everyone on your team. The project manager, however, cannot have a clear vision of the project if the project needs are never clearly established.

Once you’ve discovered your vision, create a goal. A goal should be a clearly stated fact, for example, “The new database will be installed and functional by December 6 of next year.” A goal sums up the project plan in a positive, direct style. Every member of your team should know and pursue the goal. It’s not all up to you. The goal establishes the direct need and purpose for undertaking the project.

When creating a goal for your project, be reasonable. Just like it would be foolish for a fat man to say, “I’m going to lose sixty pounds this month,” it would be as unreasonable for you to create an impossible goal.

A logical goal is not just an idea, a guesstimate, or some dreamy date to be determined. A goal is actually the end result of a lot of hard work. Each IT project will, of course, have different attributes that determine each goal. Let’s say, for example, that your company is going to be migrating your servers and desktops to the latest and greatest operating system.

With this scenario, certain questions would have to be answered to determine the ultimate goal: Is the hardware adequate for the new OS? Will the applications work with the new OS? Will the team have adequate time to be trained and experiment with the new OS? These questions will help you create the end date for the goal.

Once you’ve determined the business needs for the project, it’s time to create a project charter. A project charter is similar to the goal, but more official, more detailed, and in line with your company’s vision and goals. Obviously, a project can stem from a broad, general description of an IT implementation. A goal narrows the description and sets a deadline. A project charter formalizes the goal and serves as a map to the destination. Above all, however, a project charter formally authorizes the project.

Not only does a charter clearly define the project, its attributes, and its end results, it also identifies the project authorities. The project authorities are usually the project sponsor, the project manager, and the team leaders (if necessary), and the charter specifies the role and contact information for each. See Figure 1-6 for the evolution of a project charter.

Why do you need a project charter? Why not just hop right in and get to work? In a small company, plowing right into the project may turn out just fine. However, in most companies, including smaller ones, a project charter is the foundation for success. Consider what the charter accomplishes:

• Authorizes the project

• Defines the business need in full

• Identifies the sponsor of the project

Figure 1-6.  The project manager must lead the process to create a project charter.

• Identifies the project manager

• Makes the project manager accountable for the project

• Assigns authority to the project manager on behalf of the project sponsor

When you create the project charter, you can include just about any information on the project that you’d like. Generally though, consider these elements:

• Official project name

• Project sponsor and contact information

• Project manager and contact information

• Purpose of the project

• Business case for the project (reasons why the project needs to happen)

• High-level results and deliverables of the project

• General statement about how the team will approach the work

• Basic timeline of when the work will be implemented (A more detailed timeline will exist in the project plan.)

• Project resources, budget, staff, and vendors

Every project needs a charter. It authorizes the project, creates a sense of responsibility for the project manager, a sense of ownership for the sponsor, and a sense of teamwork for the project team. The project charter will save you headaches, establish who’s in charge, and move you to your goal more quickly and with more confidence.

Following is an example charter, based on a fictional company called Best Enterprises. The company’s network currently consists of 380 computers running Windows NT, 11 Windows NT 4.0 servers, and 5 Novell NetWare servers. It has made a decision to move all the workstations to Windows XP and all the servers, including the NetWare servers, to Windows 2003 Server. 

This article is excerpted from IT Project Management by Joseph Philips (McGraw-Hill/Osborne, 2004; ISBN 0072232021). Check it out at your favorite bookstore today. Buy this book now.