The Project Charter - Administration

Project: Operating system upgrade: XP and 2003 servers
Project Sponsor: Sharon Brenley, Chief Information Officer (x. 233)
Project Manager: Michael Sheron, Network Administrator (x. 234)
Project Team: Edward Bass, Ann Beringer, Brad Bobich, Carol Fox, Charlotte Harving, Don Khunle, Casey Murray, Mick Suskovich, Mark Turner, Stephen Utmeyer

Project Purpose All desktops will be upgraded to Windows XP by December 3, 2005. All servers will be upgraded and moved to five Windows 2003 Servers by December 20 of the following year.

Business Case Windows NT has served our company for the past five years. We’ve learned to love it, embrace it, and grow with it. However, it’s time to let it go. We’ll be embracing a new technology from Microsoft, similar to Windows NT, but far superior: Windows XP. Windows XP will allow us all to be more productive, more mobile, more secure, and more at ease.

In addition, there are new technologies that work excellently with XP, such as infrared networking for our manufacturing shop floors and new accounting software that will be implemented later this year.

Of course, our company will continue to embrace our web presence and the business we’ve earned there. XP will allow us to follow that mindset and create greater opportunities for us all.

As our company has experienced over the past year, our servers are growing old, slow, and outdated. We’ll be replacing the servers with six new multiprocessor servers loaded with RAM, redundant drives, and faster, reliable tape arrays—which means faster, reliable, more productive work for us all. The operating system we’ll be implementing for all of our servers will be Windows 2003.

Windows 2003 will allow our users to find resources faster, keep our network up longer, and provide ever-increasing security.

• Windows XP on every desktop and portable computer

• Windows 2003 Server installed on six new servers

• All implementation complete by December 20 of the following year

• September Test deployment methods, capture user and application status, finalize deployment image, and create scripts.

• October Initial deployment of 100-user pilot group. Test, document, and resolve issues. Redeploy 100-user pilot group with updated images and scripts. Begin Windows 2003 Server testing and design.

• November Begin month-long four-hour training sessions. While participants are in class, XP will be deployed to their desktops. Troubleshoot and floor support in coordination with Jamie Bryer, Help Desk Manager. Continue to test Windows 2003 Servers. Three Windows 2003 Servers will go live on November 15.

• December Finish deployment of XP. Install new 2003 servers and create infrastructure. Convert each existing server to Windows 2003. Project completed December 20 of the following year.

• Budget: $275,000 (includes XP, 2003 server, client access licenses, consultants, training)

• Test lab reserved for four-month duration

• On-site consultant from Donaldson Education

Your project charter can include as much or as little information as you deem necessary. Project charters are often shared with the entire company (with the exception of the budget) so you may have a few revisions before the charter is complete. Sharing a project charter with the entire organization, especially one that will affect all users as in the sample charter, can get everyone involved, excited, and aware of coming changes. A project charter also creates a sense of responsibility for all involved.

Your project team members will get distracted, pulled in different directions, and lose interest. Vacations pop up, kids get sick, people quit. Realize at the onset that not everyone will be as dedicated to your project as you are. Do your best to inspire, motivate, and lead. Set aside politics, egos, and aspirations and work toward the goal.

Finally, keep in mind that a charter can be called different things in different organizations and that the level of detail can vary depending on the company or the project being created. Most charters, however, accomplish two primary things: authorizing the project work and defining the project work.

There’s a cartoon that’s probably posted in every auto mechanic’s garage. In the cartoon, there’s a bunch of people rolling around laughing uncontrollably. Above all this mayhem is the caption, “You want it when?” Of course, as an IT project manager, you can’t take that same approach, but a reasonable deadline has to be enforced.

A firm end date accomplishes a few things:

• Creates a sense of responsibility toward the project

• Gives the team something to work toward

• Signifies a commitment from sponsors, team members, and the project manager

• Confirms that this project will end

How do you find the completion date for a project and how do you know if it’s reasonable? The magic end date is based on facts, research, and planning. In upcoming chapters, you’ll get a more detailed look at project end dates and how you establish them. For now, know that projects are a sequence of steps, and each step will take time. The completion of each step will predict when a project should end.

Figure 1-7.  If a project stays on schedule, so will the budget and the morale.

Some project managers create a flexible deadline. Don’t do it. If you allow yourself a deadline that is not firm, you’ll take advantage of it. And so will your team, your sponsor, and your management. Set a deadline based on an informed opinion, and then stick with it. The charts in Figure 1-7 demonstrate how a missed completion date is bad for the project, the company, and morale.

A rule of economics that affects scheduling is “Parkinson’s Law.” Parkinson’s Law states that work will expand to fill the time allotted to it. In other words, if you give yourself extra time to complete a project, the project will magically fill the extra time. A firm deadline gives the project manager and the project team a definite date to work toward.

Some projects have a self-contained deadline. Remember the Y2K scare? With the year 2000 rolling in like a summer storm, every programmer and company found a way to make the deadline because it wasn’t moveable.

Other factors can have impact on your projected deadline:

• Business cycles Does your project deadline coincide with busy times of the year? Think of a retail giant. How willing do you think it would be to overhaul the database that handles shipping and store management around December?

• Financial situations A company may be more (or less) willing to invest in new hardware or software at a particular time of the year due to taxes, fiscal year ending, or the advent of a new budget. You’ve got to consider these factors when you request finances for your project.

• Times of the year When will your team members take vacation? How will their vacation plans coincide with your deadline? What other internal time commitments do they have? Will they be traveling to other sites? These factors can delay a project for weeks and months—ultimately resulting in a missed deadline. Work with your team members to ensure their availability coincides with their responsibilities within the project plan.  

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.