eBook
Available on Compatible NOOK devices, the free NOOK App and in My Digital Library.
Related collections and offers
Overview
Product Details
| ISBN-13: | 9781567264210 |
|---|---|
| Publisher: | Berrett-Koehler Publishers |
| Publication date: | 10/01/2006 |
| Sold by: | Barnes & Noble |
| Format: | eBook |
| Pages: | 464 |
| File size: | 15 MB |
| Note: | This product may take a few minutes to download. |
About the Author
Frank Parth, MS, MSSM, MBA, PMP, is the President of Project Auditors, LLC, a project management consulting, training, and auditing company. After ending a career in aerospace as the assistant technical director on a $12 billion satellite program, he branched out in 1993 and began consulting in technology management to major U.S. companies, national governments, and the U.N. He was CTO for a small but successful e-commerce company, headed up systems engineering at TRW Information Systems during a major infrastructure upgrade, and created PMOs for several major corporations. He taught systems analysis and management at the Graduate School at the University of Southern California, has been an instructor at the University of California, Irvine PM Certificate program since 1994, and has taught at the Claremont Graduate School. Mr. Parth has undergraduate and graduate degrees in physics, a master’s in systems management from USC, and an MBA from the Peter F. Drucker Graduate.
Read an Excerpt
Introduction to IT Project Management
By Cynthia Snyder, Frank Parth
Management Concepts Press
Copyright © 2007 Management Concepts, Inc.All rights reserved.
ISBN: 978-1-56726-421-0
CHAPTER 1
Projects and Operations
After reading this chapter, you will be able to:
• Define how projects and operations are different.
• Describe how IT projects differ from non-IT projects.
• Explain the value of project management for IT projects.
• Define key terms in project management.
Welcome to the world of information technology project management. In reading this book, you will find that managing IT projects can be highly rewarding and, often, equally frustrating. You will discover that project team members, project customers, and other project stakeholders can be very easy to work with and at the same time can be very challenging. It is not uncommon in project management to get a high-priority project from upper management one week and then find the next week that things have changed and a new project is the number one priority. You will almost never have enough resources to do the work and never have enough time to produce the best product possible. You will be told not to spend time planning the project but to just begin working, and you won't have enough time to gather the user requirements before you need to start development. Your resources will be working on three other projects as well as normal daily operations, while you're trying to get them to work on your project.
However, when the project is over you will have produced something that makes work easier for the other people in your organization, saves your organization a significant amount of money, keeps private data secure, or upgrades a legacy system into something much more effective and efficient. When all the work of the project is over, you will have made a real contribution to the organization.
What Is Project Management?
Project management is the application of skills, knowledge, and abilities to produce a unique product, service, or result. Three components that lead to successful projects are technical knowledge, general management abilities, and project management skills.
The project manager must have knowledge of the technical aspects of the project. Although some will debate this point, in IT projects particularly the project manager needs to know enough to detect when something is amiss and to understand the general principles of the project. He or she certainly does not need to be a subject matter expert in every facet, but some amount of knowledge is a necessity.
The project manager also needs some capability in the area of general management, including skills in budgeting, analysis, planning, and coordinating. Finally, the project manager must apply project management skills, tools, and techniques to make the project a success. This book focuses on the project management component while referencing technical knowledge and some general management abilities (see Figure 1-1).
Managing IT projects is similar to managing other types of projects, such as projects in the fields of construction and pharmaceutical development. However, IT project management has unique aspects, including:
• Technical projects require team members with specific technical skills.
• For small projects, team members are typically working on multiple projects at the same time.
• Most team members have operational responsibilities as well as project responsibilities.
• Larger IT projects tend to form the very infrastructure of the organization, and failure can cost millions of dollars.
• Because of the pervasiveness of information systems, a simple IT project may become complex because of the number of other systems it touches.
• Technology is evolving so rapidly that software and hardware are almost always out-of-date before they are deployed.
• Technology requires continual upgrading, maintenance, and improvement.
• The changing nature of technology can make it difficult to estimate accurately or to learn from previous projects.
The differences inherent in IT projects create a need for specialized approaches to manage IT projects effectively. The basic methodology of project management continually advances as we learn what works under what conditions and what does not work. Although it is tempting to use a recipe approach to managing IT projects, the reality is that each organization must start with the basic principles of project management — which are presented in this book — and develop a detailed approach that works for its organizational structure, culture, and environment.
Project management practices and methods are evolving. As organizations change and evolve, the approaches needed to effectively manage projects also change and evolve. The largest professional organization dedicated to project management is the Project Management Institute (PMI®) with over 200,000 members worldwide at the time this book was written. PMI's book A Guide to the Project Management Body of Knowledge (PMBOK®Guide) was developed by practicing project managers, and it is the American national standard for project management. This guide is continually evolving as new approaches and new practices are integrated into project management. However, it is not the only approach to managing IT projects. An approach called Projects in Controlled Environments (PRINCE2) was developed by the IT Directorate of the British Government. PRINCE2 places a heavy emphasis on creating a strong business case for IT projects and continually monitoring the project against the business case. The Information Systems Audit and Control Association (ISACA) has developed Control Objectives for Information and Related Technology (CoBIT), which emphasizes controlling and auditing IT projects.
Why Use Project Management?
Why are there so many approaches to managing IT projects? Because the failure rate of IT development work is high. The baseline study of IT project success is the CHAOS Report released by the Standish Group in 1995. This report showed that 31 percent of projects were canceled before completion and 52.7 percent of projects cost over 189 percent of their original estimates.
Based on this research, the Standish Group estimated that in 1995 American companies and government agencies spent $81 billion for canceled software projects and had to pay an additional $59 billion for software projects that exceeded their planned schedules. It estimated that almost 80,000 projects were cancelled in 1995. Although large IT projects are always risky, many of these projects were as straightforward as a drivers' license database, a new accounting package, or an order entry system. This book will help you understand the unique aspects of managing IT projects and how to improve the success rate of your projects significantly.
This book is about how to manage IT projects. It is not a book on software project management and it is not a book on implementing enterprise-wide software applications. It is not a book on how to manage local area network (LAN) design and installation. All of these are types of IT projects, but IT is a much broader field than any one of those areas. We will use a working definition that IT project management is about managing projects where a significant portion of the product or result is dependent on some aspect of information technology. This book will give you a strong start towards managing those projects.
How Is Project Management Different From Operational Management?
When most of us consider an organization, we think of a hierarchical assortment of departments that collectively produce some type of product or service. Most organizations have a marketing department, a finance department, a human resources department, some type of production or manufacturing department, and, of course, an IT department. These departments work more or less collaboratively to create something of value that the organization provides to its customers in order to sustain the organization. In the world of operations management, departments work towards company objectives.
For example, in operations management the goal could be to produce and sell the best widget for the least amount of money and to sustain those operations. At that point, production becomes repetitive and static. However, projects are not repetitive; projects are one-time events designed to produce specific results and then to end. The PMBOK® Guide defines a project as a temporary endeavor undertaken to create a unique product, service, or result.
Although departmental operations tend to focus on the objectives that each department is working to achieve, projects focus on a client or business objective. Operations management is concerned primarily with keeping the lights on and ensuring that the company continues and grows. Projects produce a specific deliverable and then dissolve.
The structure of management is also different. Operational departments have managers and staff assigned full-time with well-established roles, responsibilities, and authority. Projects are temporary in nature; the project manager and team members are brought together for a short period, complete the work, and then disband. The project may be comprised of people at varying levels of skill, responsibility, and authority. Depending on the organization, project managers may have full authority or very little authority when it comes to making decisions and managing people and budgets. Although their level of authority varies, their level of responsibility does not — they are always fully accountable for bringing the project in on time and on budget and for satisfying all the requirements.
For projects, time, budget, and scope are constraints — limitations within which the project manager must work. By comparison, in production environments these constraints are incorporated into the process. For example, a production line produces 750 widgets each day, the staffing is sufficient to manufacture the widget, and material costs are negotiated upfront with a fixed percentage factored in for rework or failure.
Although this is a somewhat simplified version of operations, you can see that managing an outcome in the world of project management can be much more challenging than managing an outcome in an operations environment.
Successful Project Management
Now that we have provided a summary definition of successful projects and project management, let's take a closer look at project management. Project management includes identifying requirements; establishing clear and achievable objectives; balancing demands for quality, scope, time, and cost; and adapting the specifications, plans, and approach to the needs and concerns of various stakeholders. But this is just one aspect of what it takes to call the project a success.
Projects are usually performed by a team rather than by just one person, so a major component of being a successful project manager is managing people to achieve the project goals. Many new project managers mistakenly think that project management is just another task to be done on top of developing the product. As an IT project manager, you are primarily responsible for ensuring the work is done, not for doing it yourself. This is a difficult transition for many technical people to make. You are a manager now, not a technical person doing coding or designing a LAN.
Another common misconception is that if you have Microsoft Project or some other project software you can manage a project. There is an old saying in project management that having a copy of MS Project makes you a project manager to the same extent that having a copy of MS Word makes you an author. Managing schedules and using software are pieces of project management, but certainly do not, by themselves, lead to successful projects.
One of the most challenging jobs a project manager faces is defining and balancing the expectations of project stakeholders. If you meet the scope of the project, on time and within budget, but the customer is not satisfied, the project is not a success. Additionally, even if the customer is satisfied, if the project team is burned out — or worse, feels abused — the project should not be considered a success. One criteria of success can be whether the team would want to work with the project manager again. If the answer is no, then the project manager did not successfully manage the team.
So then, what is a successful project? One view says that a project is successful when all stakeholders are satisfied. For the most part that means that the customer's requirements were met in a timely fashion for the agreed upon budget. However, it also means that the project is a strategic success, is consistent with the organization's strategy (more on this in a later chapter), and meets the needs for which it was undertaken. It also means that the team members are satisfied. Sometimes the biggest challenge is how to meet tight deadlines without creating team burnout. Figure 1-2 shows the project management balancing act.
Programs And Portfolios
Although this book will focus on projects and project management, understanding the context of projects in the bigger picture is useful. Some organizations do projects (sometimes many projects) that too often are not organized or prioritized in any particular manner. The entire suite of projects within a company or department is called the project portfolio.
Earlier we defined a project as a temporary endeavor undertaken to create a unique product or service. Some projects are so large that they have to be subdivided into multiple projects, each of which contributes to the accomplishment of the larger project. A project that consists of subprojects is called a program. Each of the smaller projects is managed separately, but all of them have goals that support the program. An example of a program is a large corporate initiative such as installing an enterprise resource planning (ERP) system. Each department affected by this program may have a series of projects related to the program, such as requirements definition, process engineering, identifying the business rules, and so on.
A project portfolio is a collection of projects and/or programs managed as a single group to support organizational or departmental goals. The projects in a portfolio may be related, such as a portfolio of defense programs and projects or a portfolio of commercial programs and projects. They may be unrelated, such as when a portfolio is managed to ensure the proper balance among infrastructure projects, security projects, and business development projects. Figure 1-3 shows a possible project portfolio composed of various projects and programs.
A Brief History Of It Project Management
Modern project management traces its roots back to the late 1950s when the Project Evaluation and Review Technique (PERT) and the Critical Path Method (CPM) were developed. These methods were created to handle projects that were growing increasingly complex. PERT was developed and used in the defense field and CPM in the construction field.
Projects from both of these fields shared common characteristics: they were large and complex, had significant technical risk associated with them, and had dedicated project managers and dedicated project teams. This environment existed for more than 20 years, and it worked very well. NASA's ability to develop large, complex, risky rockets and manned space systems under tight schedules during the 1960s was due to its strong project management skills.
Electrical machines have been able to perform calculations since the first large computer was wired together by hand. As mainframe computers grew, the field of software engineering also grew, and much of the development took place under government funding by NASA and the military. However, often these programming efforts were not managed as separate projects but as subsets of large programs. It was not until early in the 1980s that the practice of managing software development as a separate project began to mature in private industry. This development occurred as commercial applications grew in size and complexity.
(Continues...)
Excerpted from Introduction to IT Project Management by Cynthia Snyder, Frank Parth. Copyright © 2007 Management Concepts, Inc.. Excerpted by permission of Management Concepts Press.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
Contents
Chapter 1: Projects and Operations,Chapter 2: Organizational Structure and the Strategic Role of Project Management,
Chapter 3: Project Processes, Phases, and Life Cycles,
Chapter 4: Project Management Plan Elements,
Chapter 5: Initiating and Planning Project Scope,
Chapter 6: Creating the Work Breakdown Structures and Project Schedule,
Chapter 7: Developing the Project Team,
Chapter 8: Quality Management,
Chapter 9: Project Communications,
Chapter 10: Project Risk,
Chapter 11: Finalizing the Schedule and Budget,
Chapter 12: Project Execution,
Chapter 13: Project Monitoring and Control,
Chapter 14: Project Audit and Closure,
Appendix: Answers to Review Questions,
Index,