If you are currently studying for the Project Management Professional (PMP)® exam then you will be aware that each of the 49 processes listed in the Guide to the Project Management Body of Knowledge (PMBOK® Guide) has inputs, tools / techniques and outputs associated with them. If you were to learn these off by rote, you would have to memorize hundreds of different items.

In this post:

Emphasizing Understanding Over Rote Memorization

Here at Velopi we do not advise our students to learn these off like multiplication tables. Instead we place our emphasis on understanding. If you are clear in your mind about what each process does, you should have a good understanding of the tools and techniques needed. Indeed, most of the PMP® exam preparation course material centres on these very tools and techniques.

Building a Comprehensive Picture of Process Relationships

However, if you are also clear in your mind about how each process relates to others, you should be able to build up a picture of what artefacts are communicated between them. For example, each planning process produces a section of the Project Management Plan. All of these sub-sections then feed into the Develop Project Management Plan process. The PMBOK® Guide encapsulates all of these sub-sections in one input called “outputs from other processes”.  Once you are aware that the outputs being referred to are sections of the overall plan and that the other processes are planning processes, this input now makes a lot of sense.

Recognizing Inputs, Tools/Techniques, and Outputs in Context

Generally speaking, processes tend to have one or two main inputs and use these to produce their own outputs. But there are processes that draw on ten or more inputs and these can be frightening for the PMP® exam student. A good example is the Estimate Activity Durations process. Although the inputs are clustered under four headings, they expand into a total of 14 inputs as follows:

• Project management plan
  • Schedule management plan
  • Scope baseline
• Project documents
  • Activity attributes
  • Activity list
  • Assumption log
  • Lessons learned register
  • Milestone list
  • Project team assignments
  • Resource breakdown structure
  • Resource calendars
  • Resource requirements
  • Risk register
• Enterprise environmental factors
• Organizational process assets

Instead of blindly learning all fourteen of these inputs, consider for a moment what the Estimate Activity Durations process is trying to do. It is trying to determine how long each activity will take. So the first thing we will need to know is what activities do we need to determine durations for. It might be useful to study the overall Project Scope Statement to understand where all the activities fit into the big picture, but we will definitely need to access the outputs of Define Activities to get the list of activities. We would also be interested in any other information about the activities, so the Activity Attributes document will be welcome as well.

What else should be available to us at this point? Well we should have estimated the activities’ resource requirements. These can have tremendous consequences for scheduling because a particular task might require a particular resource that might be difficult to obtain. This is particularly true if the activity needs a particular member of staff. So we need to know when this person will be available for selection. In other words, we need to reference Resource Calendars and the Resource Breakdown Structure.

Another question to ask is: have we got all the activities from the scope planning work? The only other knowledge area that might add extra activities is risk planning. We might decide to take steps to mitigate the probability and / or impact of some risks and these might involve some extra work for the team. So the Risk Register becomes an input.

Knowing the activities that need to be estimated is a good start, but is there anything available that will help the Project Manager come up with sensible estimates? When you are dealing with planning-related processes, it is always a good bet to consider the Enterprise Environmental Factors and the Organizational Process Assets. The environmental factors can provide databases for estimating based on norms for this industry and productivity metrics. The Organizational Assets supply historical information from previous projects and advice on which tools / techniques work best.

Applying Knowledge in the PMP® Exam

In the PMP® exam itself, inputs and outputs are tested by asking “which of the following is (or is not) an input / output of process X?” If the question is about inputs, ask yourself what should be available before I start this process? You will often find that at least one of the answers given is one of this process’s outputs. Once you have reduced the options to plausible ones, ask yourself what could this process do with each input? Often an input will rule itself out because it cannot contribute to the process’s work.
Similarly, if the question is about outputs, ask yourself what does this process contribute to the overall project? Do any of the answers make sense in that context? If you cannot imagine how this process could produce an output then it is a safe bet that you can rule that option out.

Conclusion

In summary, do not try to learn lists of inputs and outputs mindlessly. Instead, ensure that you know what all the processes are, what they do and how they relate to other processes. That understanding will help you make sensible judgements about their inputs and outputs.
Velopi’s PMP® exam preparation courses cover all the project management processes. They are run online in our virtual classroom for your convenience. For more details of these courses, please visit our training page, or contact us directly.