Tips for the IT Professional

Although it is our intent to assist project managers from all disciplines in their quest for PMP certification, we do want to share a set of tips and insights that will be particularly useful to the majority of IT project managers. Why do we focus on the IT project manager? Three key reasons:

  • Although the IT project management discipline is improving each year, a very wide range of implementation maturity levels and experiences still exist.

  • Given the target market of the Exam Cram 2 series, it is anticipated that most of the readers of this book have experiences from the IT field.

  • We are both IT project management professionals.


If your project management experience has not been in the IT world, we encourage you to read this section anyway. There are generally gaps between PMI's vision of project management and your own experiences, and this section will help you identify those gaps. More importantly, we share several key PMI insights and assumptions that will benefit you greatly on the exam.

The purpose of this section is to summarize the common gaps between the experiences of most IT project managers and what they need to know to successfully pass the PMP exam. You want to avoid the trap of thinking that you might pass the PMP exam easily because you have been managing projects for a long time. The reality may be that the way you have completed IT projects and the way you understand IT project management may not be the way that PMI sees this industry. So, when it comes to passing this exam, you will need to stay alert to what PMI says about a topic in order to answer exam questions correctly.

This section also covers several tips that will help you streamline your exam preparations. These tips are organized into the following classifications:

  • Common "conceptual" gaps

  • Common "experience" gaps

  • Common "terminology" gaps

  • What's important to PMI?

  • Key PMI assumptions

  • Exam topics not covered in the PMBOK

Common "Conceptual" Gaps

Because it is important to answer the questions from PMI's perspective, and not necessarily from your real-life experiences, let's first review several key, high-level differences between the PMI vision and common experiences of IT project managers:

  • Culture clash Because nearly every organization implements project management differently, we generally find that most implementations are not entirely consistent with PMI's view of the world. You will want to identify those differences for your own situation.

  • "The" project manager Given the wide range of "project manager" experiences within IT (for example, technical team leader, project administrator, project analyst, project leader, project coordinator), you may be surprised by the expectation PMI has of the project manager role and the powers that come with it.

  • Unapproved practices There are several project management practices and techniques used routinely within IT that are considered "inappropriate" by PMI (for example, the use of overtime, forcing estimates down). These will appear on the exam as incorrect options.

  • Bigger ballpark For most IT project managers, the PMI PMBOK describes a field of project management that is much broader and complex than what they have experienced in real life.

  • The whole story Most IT project managers lack experience in the complete lifecycle of project management. Generally, there is minimal exposure to the Initiating and Closing phases. You must understand the complete project management process as described by PMI.

Common "Experience" Gaps

This section reviews common gaps between the experiences and practices of most IT professionals, and their respective organizations, and what PMI expects the project manager to do:

  • Project planning Of the 39 PMBOK project management processes, 21 deal with planning. As you can imagine, PMI's definition is much more encompassing than the project plans routinely developed by IT project managers.

  • Developing a project schedule It is still rather uncommon to find IT organizations and IT professionals who build a project schedule the "right way." As you can imagine, the "right way" is much more involved than the method routinely employed within IT. If you do not use a four-step process, use network diagramming techniques (there are more than one), understand the three estimating methods, account for all Work Breakdown Structure (WBS) dictionary items, or identify all dependencies and level resources, you probably have some work in this process area.

  • Planning project management Yes, we still have not left this "planning" theme yet. PMI expects that all project management activities are planned and documented. So, if your project plan does not include supplementary plans, such as a staffing-management plan, a responsibility matrix, a communications-management plan, a quality-management plan, a scope-management plan, and a risk-management plan (for starters), you will want to focus on these and understand their value.

  • Tracking project performance "Earned value" is PMI's recommended technique for tracking and controlling project costs, schedule, and scope. Earned value analysis is not a generally applied technique across IT, and many IT professionals have limited experience in managing project costs.

  • Risk management Because a full-scale risk-management process, as described by PMI, is rarely implemented on IT projects, many people have not been educated in this area, either.

  • Quality management Quality management has the same reasons as risk management, except many organizations do have some levels of quality programs in place. The issue here is that your organization's philosophy, terminology, and processes may not match those espoused by PMI.

  • Procurement management This is not as frequent a gap as it used to be, but if your experiences have not dealt with soliciting, selecting, and managing vendors, you will have gaps to close in this area.

  • Project selection Although the practice of applying sound business principles to prioritizing and selecting IT projects is increasing each year, there are still many IT project manager types who have not been exposed to business case development and official cost-benefit analysis using financial techniques, such as NPV, IRR, and payback period. (Don't be concerned, we will explain this area further and tell you what you need to know.)

Common "Terminology" Gaps

A common revelation of many Project Management professionals, when they are first exposed to the PMBOK, is that they find terms and concepts they know in one fashion do not necessarily mean the same thing to PMI. Although a complete glossary of key PMP exam terms is included in this book, it is important to review the common terminology gaps for IT professionals now, so we can "get on the same page" early in the process:

  • Project charter To PMI, this is the document that authorizes (initiates) the project and the project manager to do his work, and is the key output from the Initiating process. In many organizations, this document is often given other names (for example, Project Initiation form, Business Case).

  • Project plan To PMI, the project plan is the key output of the Planning process and contains many subdeliverables (for example, the project schedule, WBS, all the supplementary project management plans). In many IT-related organizations, this document may be known as the Project Charter, Project Contract, Statement of Work, and so on.

  • Project plan versus project schedule A Gantt chart (MS Project) project schedule is not a project plan. A project plan contains the project schedule.

  • WBS versus Gantt chart To PMI, a Work Breakdown Structure (WBS) is not equivalent to a Gantt chart (MS Project) project schedule. The WBS is a key input into the schedule-development process, and the project schedule accounts for calendar time and resource leveling.

  • Terms to verify Here are several other common project management terms you use that may not have the exact same definition to PMI (these differences are less critical than the ones previously mentioned):

    • Audit

    • Baseline

    • Corrective action

    • Kickoff meeting

    • Procurement management

    • Risk management

  • Uncommon terms to notice Several terms used by PMI are not that well-known in the IT project management world. You will want to make sure you review these terms:

    • Gold plating

    • Integration management

    • Project expeditor

    • Project Management Information System (PMIS)

    • Work Authorization System

What's Important to PMI?

To better appreciate why these common gaps exist and to better prepare for the exam, let's review some of the underlying principles guiding PMI's vision of project management:

  • The project manager "makes it happen" and "brings it all together." The role of project manager is extremely important and extremely valuable.

  • Planning is very important 21 of the 39 PMBOK processes are "planning related."

  • All "management" activities should be analyzed and planned in advance. These supplementary "management" plans are part of the overall project plan.

  • The project plan should accurately describe project activity, is based in reality, and is used as the baseline to measure progress.

  • The Work Breakdown Structure is a very important project management tool.

  • Communication is the most important activity of the project manager (90% of the PM's time is spent here). Other communication-based principles that are extremely important to PMI include the following:

    • Coordinate with stakeholders on all project aspects.

    • Clearly assign all project roles and responsibilities.

  • The risk-management process is very important and is a continuous project management activity.

  • All estimating should be completed by the people who will actually do the work.

  • All projects, regardless of outcome, should complete the Closing process. The emphasized outputs from this are as follows:

    • Capturing "lessons learned"

    • Executing proper administrative closure

Key PMI Assumptions

To further understand these common gaps but more importantly, to better prepare for the exam let's review some of the key assumptions that guide PMI's vision of project management:

  • The project manager is selected when the project is authorized before any estimating or preliminary requirements gathering.

  • The project manager is ultimately accountable for the project.

  • PMI assumes you have historical records of past projects.

  • WBS is the basis for all project planning.

  • The project plan is the baseline that the PM uses to "control" the project.

  • The project plan accurately describes the project activity. The project plan is realistic and can be used to measures progress.

  • PMI assumes your organization has project management methodologies and quality-assurance procedures.

  • The project manager does have Human Resources and team-development responsibilities.

  • PMI assumes the project team is involved in all planning decisions and problem-solving situations.

Exam Topics Not Covered by PMBOK

Although the PMP exam is based "primarily" on the PMBOK, and the PMBOK should be a central reference in your exam-preparation efforts, several exam topics originate from general business-management knowledge or other PMI publications and are not addressed in the PMBOK.


This point also demonstrates one of the major values of practice exams. The questions you will encounter will help you find the topics you may need to study outside of the PMBOK.

Although this list is not meant to be exhaustive, here are some key non-PMBOK exam topics you should understand:

  • Conflict-resolution techniques

  • Organizational theories

  • Problem-solving techniques

  • Professional responsibility

  • Theories of motivation

PMP Exam Cram 2. Project Management Professional
PMP Exam Cram 2. Project Management Professional
Year: 2003
Pages: 169 © 2008-2017.
If you may any questions please contact us: