Managing an IT project may be the most exciting -- and challenging -- task you ever undertake in your career. This article will show you how to get started. It is excerpted from the book, IT Project Management, by Joseph Phillips (McGraw-Hill/Osborne, 2004; ISBN: 0072232021).
Welcome to information technology (IT) project management. IT project management is different from managing any other project you may have worked on in the past. In the world of information technology, we’ve got attacks on all fronts: ever changing business needs, hardware compatibility, software glitches, security holes, and network bandwidth, not to mention careers, attitudes, and office politics.
Don’t be scared off! This is also the most challenging and exciting place to be in a company. What you do here will affect entire organizations, and have an impact on profits, and can boost your career, confidence, and life to the next level.
IT project management can be as exciting as a white water rafting excursion or as painful as a root canal; the decision is yours. What makes the difference between excitement and a sore jaw? Many things: leadership, know-how, motivation, and, among other things, a clear vision of what each project will produce, what it will cost, and when it will end.
This first chapter will help you build a strong foundation for managing successful IT projects. Like anything else in the world, adequate planning, determination, and vision are required for success. Ready to start this journey? Let’s go!
Gathering Project Information
Everybody talks about project management, but what is it exactly? In some organizations, any task or duty is considered a project that requires someone to manage it. Puh-leeze! Project management is the ability to administer a series of chronological tasks resulting in a desired goal. Some tasks can’t be completed until others are finished, while other tasks can be done in parallel. Some tasks require the skill of a single individual; other jobs in the project require that everyone chip in and lighten the load.
A project, technically, is a temporary endeavor to create a unique product or service. Projects are an undertaking outside of the normal operations of an entity. For example, you might roll out a new application, install new monitors, create a new portion of a web site, or establish a new call center for application support. In some organizations, such as ones comprised of application developers or consultants, or IT integration companies, everything they do is a project because they complete projects for other organizations. Consider a company that creates custom applications for other organizations. Their operation is an ongoing series of projects. The organization that completes the project work is called the performing organization.
IT project management is the ability to balance the love and implementation of technology while leading and inspiring your team members. Of course, the goal of project management is not technology for technology’s sake, but rather a movement toward things like improved customer service, enhanced product quality, and increased profitability. As you can see in Figure 1-1, project management is a high-wire balancing act.
Establishing the Project Requirements
Before the actual project work can begin, the project manager must establish the project requirements with the project stakeholders. Stakeholders are any individuals, groups, or communities that have a vested interest in the outcome of the project. On some projects, the stakeholders may be just one department. On others, when projects may affect every department, the stakeholders may be throughout the entire organization. Identifying stakeholders is important because their input to the project requirements early in the project initiation can ensure the project’s success.
Of course, on most projects there will be key stakeholders who influence the project’s outcome: department managers, customers, directors, end users, and other folks who have direct power over the project work. With the input of these key stakeholders, specifically their requirements for the project, constraints on the project, and time and cost objectives for the project, the project manager will be able to gather the project requirements to begin building a project plan to create the project deliverables.
Clarity is paramount. When the decision has been handed down that your company will be implementing some new technology, and you’ll be leading the way, you need a clear, thorough understanding of the project’s purpose. Ambiguous projects are a waste of time, talent, and money. Before the project begins, you need to know what exact results signal the project’s end. A project truly begins when you know exactly what the project will produce.
Figure 1-1.A project manager must balance the team and the technology.
Once the project is defined, you need a clearly stated start and end date. The role of a project manager is not permanent but temporary. You, the project manager, are responsible for seeing the goal, developing the steps to get there, and then leading the way for your team to follow.
How will you know what the end result of the project is to be? Ask! Who do you ask? People like the project sponsor can answer these kinds of questions. More about that later! You must have a clear vision of the end result, or the project will drone on and on forever and you’ll never finish. Too often IT projects can roll into project after project stemming from an original, indecisive, half-baked wish list. Whether you are a full-time employee within an organization or a contract-based project manager, you must have a clear understanding of what the end results of the project will be.
Imagine your favorite archeologist maneuvering through a labyrinth of pitfalls, poison darts, and teetering bridges to retrieve a golden statue. In the movies, there’s always some fool who charges past the hero straight for the booty and gets promptly beheaded. Don’t be that guy. Before you can rush off toward the goal of any given project, you’ve got to create a clear, concise path to get there.
To create this path, you’ll have to interview the decision makers, the users the change will affect, and any principals involved in the development of the technology. These are the stakeholders—the people who will use the project deliverables on a daily basis or will manage the people who will use the project deliverables. You must have a clear vision of what the project takes to create it or you’re doomed. Often projects start from a wish list and evolve into a catalog of complaints about the current technology. One of your jobs in the early stages of the project will be to discern valid input from useless gripes.
As you begin your project, consider these questions:
Does the Project Have an Exact Result?
Projects that are as indecisive as a six-year-old at an ice cream stand rarely are successful. As a project manager, you must ensure the project has a definable, obtainable end result. At the creation of the project, every project manager, project sponsor (the initiator of the project), and team member should know and recognize the end result of the project. Beware of projects that begin without a clearly defined objective.
While you should be looking for exact requirements that a project is to include, you must also look for requirements that are excluded from a project (for example, a project that requires all mail servers to be upgraded in the operating system, but not the physical hardware). As the project takes form, the requirements to be excluded will become obvious based on management, the time allotted for the project’s completion, and the given budget.
Are There Industry or Government Sanctions to Consider?
Within your industry there may be governmental or self-regulating sanctions you will have to take into account for your project. For example, in a banking environment there are regulations dealing with the security of the technology, the backup and recovery procedures, and the fault tolerance for the hardware implemented. Government regulations vary by industry, and if your company is a government contractor, there are additional considerations for the project deliverables.
Within your industry there may be standards and regulations. Regulations are “must-haves” that are required by law. Of course, pharmaceuticals, utility companies, and food packaging companies have regulations that dictate their practices. If companies break regulations, fines and lawsuits may follow. Standards, however, are generally accepted guidelines and practices within an industry. Standards are heuristics, rules of thumb, which are not laws but are usually followed. The project manager must be aware of regulations and standards that affect the project’s work and deliverables.
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.