Some Notes on Terminology

Some Notes on Terminology

In this book, I have used the following terms.

client The company or department that specifies what the project is to accomplish, pays the bill, and accepts delivery of the system. The client may be an external customer, such as that of a consulting company, or an internal department.

The client is represented by client staff. Among them are client managers or decisionmakers, and users. When this book refers to a client as a person, it is referring to the former.

project manager The person responsible for the schedule, budget, functionality, and implementation of a project or subproject. Many organizations differentiate between project managers and project leaders, but the difference is one of nomenclature and sometimes project size. It is not one of skills.

project A set of activities that has a clearly defined start and end, and that produces a tangible product. A project can produce a new application system or a major enhancement. It may also provide an implemented software package, upgraded hardware, reports and analyses such as application requirements, a technology architecture, a strategic technology plan, or a reengineering plan. A project does not include ongoing activities such as regular maintenance, help, or consulting.

users The people who will actually use the results of a project. For most projects, users form part of the client team, responsible for specifying the project requirements.

About This Book

Any project has four distinct phases: understanding the project, defining it, planning it, and running it. In all of these phases, you must exercise both general management skills and specialized project management skills within the project management context described above. A picture of project management would look similar to what you see in Exhibit 1.2.

This book consists of six chapters.

"Introduction" sets the framework and the context for the book.

"Understanding the Project" describes what you need to understand and what role you can take in shaping a project from the start.

"Defining the Project" lists the things that you need to define,

fine, including deliverables, scope, and how the project will be managed.

"Planning the Project" deals with the techniques of project planning, including how to break down a project into activities; how to prepare an estimate, a budget, and a schedule; how to plan resources; and how to identify the risks.

"Running the Project" presents the day-to-day activities needed to keep the project on track, including how to build effective teams, how to track progress and manage schedule slippages, and how to handle scope change requests. It also deals with how to manage subcontractors and client teams.

"Management Skills" is an introduction to many of the general skills that you will need in order to manage the people who are part of the project. It deals with such issues as setting realistic outcomes, listening effectively, running meetings that work, presenting bad news, and managing your time.

Many sections of the book include a set of "What If" questions about issues that can arise from the topic of the section. Each What If question represents a problem or risk that, if it actually arises, must be addressed. For each question, there is a brief description of the consequences of not resolving the issue and a set of actions that can help.

In the ideal project, you would move sequentially through the phases of understanding, defining, planning, and running the project. In reality, these phases overlap; until the project is over, you are never finished with any of them.

Nevertheless, a project road map can be drawn (see Exhibit 1.3). In it, the heavy arrows mark the normal flow of your work, and the smaller ones indicate that the process is iterative. Throughout the entire project, you will always be returning to previous phrases to deepen your understanding.

The road map also acts as a checklist. If you can answer yes to all of these questions, you have your project well under control. Any noes are flags indicating where some pitfalls may lie and where you may want to dig deeper.

This book follows the road map. It offers a methodology and serves as a reference guide for managing systems projects. It is a tool kit whose pieces are to be used as the situation requires.

Exhibit 1.3 Project Management Road Map

Do I understand the project justification?
Do I understand the background to the project?
Do I understand the project politics?
Do I understand who the players are and the roles they will take?
Do I understand the client's priorities?

Have I defined the project deliverables?
Have I established the scope-both system and project?
Have I determined how deliverables will be reviewed and approved?
Have I defined the structure and organization of the client team?

Have I defined the risks and developed plans to mitigate them?
Have I documented the project assumptions and constraints?
Have I defined the structure and organization of the project?
Have I developed a quality plan?
Have I developed a list of detailed project activities?
Have I defined the dependencies between activities?
Have I built a project estimate of the work required?
Have I assigned resources and leveled them?
Have I completed the schedule, complete with milestones?
Have I aligned the schedule with the client's requirements?
Have I developed a project budget?
Have I prepared an overall project plan?

Am I building an effective team?
Do I know where I stand against the schedule, estimate, and budget?
Am I managing risks?
Am I solving schedule problems?
Am I managing requests for scope changes?
Am I managing for quality?
Am I micro-planning when needed and not elsewhere?
Are my subcontractors delivering on their commitments?
Do I understand the expectations of the client, and can I meet them?
Am I conducting regular team meetings, and are they effective?
Do I report project status and outstanding issues regularly?
Am I taking the time to reflect privately on progress?
Do I and my team celebrate our successes?

The book is not intended to be a theoretical academic text on project management; there is no final examination. It is a practical discussion of topics and issues that you will encounter every day in your real job of managing a successful project. Each topic is restricted to a few pages so that you can treat the book as a reference guide rather than a textbook. However, the wise reader will at least skim the subjects to understand the context of what is being recommended.

To further help you apply the concepts that are presented, the chapters on understanding the project, defining the project, and planning the project include detailed checklists.

Finally, I hope that you find the book useful, usable, and readable. I invite your comments, and I wish you every success in one of the most demanding roles in systems projects.