Administration
  Home arrow Administration arrow Page 4 - Initiating the Project
Dev Shed Forums 
Administration  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Forums Sitemap 
IBM® developerWorks 
Dedicated Servers 
E-Commerce Hosting 
Linux Web Hosting 
Managed Hosting 
Small Business Hosting 
Download TestComplete 
VPS Hosting 
Weekly Newsletter

 
Developer Updates  
Free Website Content 
IBM Rational Software Development Conference
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
ADMINISTRATION

Initiating the Project
By: McGraw-Hill/Osborne
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 4 stars4 stars4 stars4 stars4 stars / 9
    2005-04-06

    Table of Contents:
  • Initiating the Project
  • Does the Project Have a Reasonable Deadline?
  • Interviewing Management
  • Identify the Project Needs
  • The Project Charter
  • From the Field
  • Chapter Summary

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      Del.ici.ous Digg
      Blink Simpy
      Google Spurl
      Y! MyWeb Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article
     
     
     
    ADVERTISEMENT

    Dell PowerEdge Servers

    Initiating the Project - Identify the Project Needs
    (Page 4 of 7 )

    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:

    Project Attribute 1994 Statistics 2004 Statistics
    Cancelled before completion

    31 percent

    23 percent

    Missed deadline, over budget,

    88 percent

    51 percent

    or both
    Average cost overrun

    189 percent

    45 percent

    Schedule overrun

    222 percent

    63 percent

    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.

    Creating Reasonable Expectations

    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.

    Creating the Project Charter

    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

    Project Charter Elements

    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.

    More Administration Articles
    More By McGraw-Hill/Osborne


     

       

    ADMINISTRATION ARTICLES

    - Configuring Load-Balanced Clusters
    - Load-Balanced Clusters
    - UNIX Time Format Demystified
    - Making Changes in the CVS
    - Building Your First CVS Repository
    - CVS Quickstart Guide
    - Authorizing Users in Samba
    - Handling User Accounts in Samba
    - Authentication in Samba
    - Accounts, Authentication, and Authorization
    - Advanced Concepts on Dealing with Files and ...
    - Dealing with Files and Filesystems
    - More Hacks for the User Environment in BSD
    - Personalizing the User Environment in BSD
    - Customizing the User Environment in BSD

     
    Accelerating Trading Partner Performance
     
    Competing on Analytics
     
    Cost Effective Scaling with Virtualization and Coyote Point Systems
     
    Five Checkpoints to Implementing IP Telephony
     
    Hosted Email Security: Staying Ahead of New Threats
     




    © 2003-2008 by Developer Shed. All rights reserved. DS Cluster 3 hosted by Hostway