Identify the Project Needs

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, or both	88 percent	51 percent
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.

Figure 1-6: The project manager must lead the process to create 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

• 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.

Sample Project Charter

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.

Project Results

• 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

Basic Timeline

• 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.

Project Resources

• 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.

Finding the Completion Date

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.

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 .

Figure 1-7: If a project stays on schedule, so will the budget and the 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.

From the Field

Interview with Kevin Kocis

Name: Kevin Kocis
Title: Manager of Information Technology
Years in the IT field: 10

Kevin Kocis has been working in the information technology field for over 10 years. He is currently the Manager of Information Technology for a division of a Fortune 100 company, where he develops strategies for network and server infrastructure, Oracle implementation, and platform interoperability issues (Windows, UNIX, and Macintosh).

Q: What is the best part about IT project management?

A: The best part about IT project management is leading an initiative that resolves a business need and/or contributes to business success. Another great part about IT project management is the challenge of leading new cross- functional teams.

Q: How do you start a new project?

A: The project is usually started in response to a broad objective or a business request. Once a performance analysis and feasibility study are completed, it can be determined whether the objective or request can be deemed a project. A project can also be initiated to optimize internal processes and to leverage return on investment.

Q: When you start a new project, what is the first thing you do?

A: The first thing to consider when starting an official project ( assuming performance and feasibility tests are complete) is to gather requirements and document flowcharts to develop the project plan. Of course, requirements often change throughout the project, but the initial requirements will be based on current knowledge. Make it a priority to update the business champions and sponsors in regular project meetings.

Q: When starting a project, what's the most important thing a project manager should do?

A: When starting a project, the most important thing a project manager should do is to identify the business goal and determine the business champion or sponsor. The business sponsor needs to understand the project scope and help convey this process to the senior management team.

Q: How do you manage the relationship between upper management, your team, and the project?

A: The IT team manager manages the relationship between the upper management team and project by acting as interpreter. One of the challenges is that senior management may not understand the IT role for the project and vice versa. The project manager should debrief both groups to ensure a synchronous understanding.

Q: How important is a project goal?

A: The goal is always significant as it is essentially the initial reason for pursuing the project. However, the goal cannot be achieved without certain conditions. Factors such as scope creep, team relations, and communications will become important as the project progresses. These factors will contribute to the success of the project, so while a project manager must maintain a focus on the goal, she cannot ignore the factors contributing to the project's success.

Q: How necessary is it for project managers to create a project charter?

A: A project charter is very important for the project manager as it serves as a roadmap for the project. As its name suggests, the roadmap should define the key steps of the project, as well as the high-level deliverables. The roadmap should also include the relationship of the project to the business' operational or strategic goals. Project charters should be well publicized (such as through an intranet web site) in addition to the project's progress.

Q: Can you share an example of how you started a project and the steps it took for you to complete it?

A: One of my projects (that saw plenty of challenges) was an internal domain migration in preparation for Windows 2000. My company was one of the first to install Windows 2000 in its production environment, and with several hundred internal Windows NT domains, there was a strong need to consolidate to a handful of key domains. To simplify the process for the scope of this chapter, we communicated heavily with our business group management. I met with senior staff to inform them the migration was a corporate initiative that would simplify a later transition to Windows 2000. I also informed them that to mitigate potential risks, we would test the migration in our test lab.

Since the timeline for this project was short ( weekend transition with one week scheduled for follow-up issues), no project charter was created. We tested the feasibility to perform the migration in our lab, working with an outside vendor for our domain migration software. We communicated the transition to the user community on a weekly basis, and on the Friday of the conversion.

Unfortunately, we did not plan for the unexpected power outage , nor the virus infection that occurred that weekend. As a result of these unforeseen events, our team had to branch out to maintain progress on the project. The only issues that resulted from the project were vagabond machines or users, and this essentially helped us prepare for our internal audit, so I considered this project quite successful.

Q: How do you work vendors into your timeline?

A: I always notify vendors during the project proposal phase as a courtesy when a project need is identified. This enables me to arrange project-planning windows around their turnaround times. Many hardware vendors do not build or prepare hardware until they are issued a purchase order, but advance notice can help expedite the process. Vendors (depending on the project) often work in parallel paths with the project team. For example, if we are looking to upgrade our servers by replacing them, the project team can plan communications and documentation while waiting for the hardware to be built and shipped.

Q: What do you do if vendors are late on delivery, which may disrupt your project completion date?

A: To avoid vendor delivery issues, the project managers should address contingency plans for any vendor- related critical path that exists in the project plan. By discussing the critical nature of the delivery, vendors can assist with providing an alternative solution before the schedule is critically impacted. These issues should be discussed prior to committing to the vendor.

Q: How do you balance the time between projects and your regular work duties ?

A: Unfortunately, when it comes to balancing time, there is seldom a right or defined answer. Individuals balance time responsibilities differently. In my case, I prioritize the projects and weigh them against my daily duties. Some project meetings I may not attend , and assign a team member to represent me. For the team, I prioritize their project tasks and communicate with management to ensure there is understanding that daily tasks will not maintain their priority. For example, if a desktop support person is involved in a critical stage of the project, daily support will not be able to maintain the same expectation level. This can be leveraged with additional resources if the business wishes to maintain its support expectancy.

Q: What's a common trap IT project managers fall into and how can they avoid it?

A: IT project managers often fall victim to making reactionary decisions based on a hardship or challenging situation. Often, the response time in light of a complication is limited, and if no contingency plan was developed or an unpredictable event occurred, the project managers may be forced to make a reactionary and critical decision without business support. To avoid this, make sure contingency and rollback plans exist for all projects. Listen to the project team, and form a consensus on the issue. The project managers may also have a tendency to become too hands-on or hands-off in the process if the plan is behind or ahead, respectively.

Q: What are characteristics of a successful project launch?

A: The characteristics for a successful launch include high publicity and management involvement. Start with a kickoff meeting (with goodies ), and make sure all business management can participate, as well as the entire project team. Ensure that all communication standards are agreed to, and that management understands the goal of the project and its participants. Review the plan and its impacts in great detail. Listen to concerns and modify the project plan only if critically necessary.

Q: If a project has many steps to the final implementation, how do you keep the project moving and heading toward each milestone?

A: For long- term projects, accountability and strict deadlines are mandatory. A key to ensuring that the team does not burn out or fade is to acknowledge their successes at milestones, regardless of the size or magnitude of their contribution. Teamwork is critical for a successful project.

Q: What advice can you offer fellow IT project managers in regard to implementing new technologies?

A: My personal advice to fellow IT project managers regarding new technologies is to thoroughly understand the enhancements and changes. Make sure external resources exist (such as vendor training and demos). Test and document the technologies thoroughly. Never underestimate how people (your users) are affected by change, even good change. Overcommunicate and focus on the positive results.

Q: What advice can you offer for aspiring IT project managers?

A: My advice to aspiring IT project managers is to remember that we grew from a certain track. Some of us are (or were) developers, DBAs, systems engineers, and network engineers . We may not have led people from other tracks. Learn to listen and be fair. Don't be influenced by where you've been. Focus on teamwork.