4squareviews

In going through John Stenbeck’s book “Introducing Agile Project Management”, I saw on p. 48 of Chapter 2 “Introducing Agile Project Management” a familiar sight: an “Agile Project Management Processes Grid”, like the processes matrix I was used to for traditional project management from the PMBOK Guide.   This is my second year leading a study group for those aiming to take the PMP exam, and I always stress how important it is to memorize the 47 processes that are divided up into a “processes matrix”, with the 5 process groups in columns and the 10 knowledge areas in rows.   When you know that matrix backwards and forwards to the point that you can recreate within 10 minutes on a blank sheet of paper, then you know it to the point that it can actually help you with situational questions that are asking “what should you do next?”   If you know what process you are in NOW based on what situation is being described in the situation, it’s a simple matter of looking at the matrix and finding out what process happens NEXT.

Similarities and Differences between the Traditional and Agile PM Processes Grids

Another thing that looked familiar was the fact that there were 5 process groups in the Agile Project Management Processes Grid.   They are fairly close to the ones in traditional PM–here is a list of the 5 process groups in Agile with the traditional PM equivalent taken from the PMBOK Guide listed in parentheses immediately afterwards

1. Initiate (Initiating)
2. Plan (Planning)
3. Iterate (Executing)
4. Control (Monitoring & Controlling)
5. Close (Closing)

However, when you get to the rows, there you start to see the difference between the Agile Project Management Processes Grid and the Traditional Project Management Processes Matrix.   There are 10 knowledge areas in PMI’s formulation of PM processes as found in the PMBOK Guide on p. 61.   On p. 48 on John Stenbeck’s book there are 7 knowledge areas, which are listed below, with my interpretation of which knowledge area (or areas) they correspond to most closely in the traditional PM processes as set forth by PMI.

1. External Stakeholders Engagement (Stakeholder)
2. Value-Driven Delivery (Scope, Quality)
3. Adaptive Planning (Time, Cost)
4. Team Performance (Human Resources)
5. Risk Management (Risk)
6. Communication (Communication)
7. Continuous Improvement (Quality)

The two knowledge areas in traditional PM listed in the PMBOK Guide that I could not find an equivalent for in Agile were “Integration Management” and “Procurements Management”.   My guess is much of the “integration” that is going on in traditional PM projects is probably being spread across many knowledge areas in Agile; procurements management is an optional knowledge area even in traditional PM because not all projects require vendors or contractors.

The next HUGE difference is the number of processes in Agile:  87 as opposed to 47.   Now this is a daunting task to memorize this number of processes, so the best way to go about it is to memorize them block by block, and today’s post will introduce the 4 processes in the first block of the Agile Project Management Processes Grid, those that are in the Initiate process group (the first column in the grid) and in the External Stakeholders Engagement knowledge and skill area (the first row in the grid).   In the next subsequent 4 posts, I will go into depth on each of these processes.

Processes in the Initiate Process Group, External Stakeholders Engagement

1. Process 1.1–Stakeholders Identification
2. Process 1.2–Vision Statement
3. Process 1.3–Project Data Sheet
4. Process 1.4–Active Listening

Before I go into a quick introduction to these 4 processes, the first thing I wanted to say right off the bat was I thought it was interesting that the knowledge area dealing with Stakeholders is the LAST knowledge area in traditional PM according to PMI, but it is the FIRST knowledge area in Agile PM.   That tells you a lot about the focus in Agile on the stakeholder, because after all, that is the source of your requirements for the product that is the reason for your project’s existence.

Process 1.1–Stakeholders Identification

This process actually consists of two parts–identifying stakeholders and building stakeholder engagement.

Identifying stakeholders does not just mean listing who they are, but also classifying them in terms of whether they are favorable stakeholders (project champions), neutral, or opposing stakeholders.   There are a series of questions to be answered that can help in this classification.   Once the stakeholders have been identified in the sense of what their relationship to the project will be, the process of engaging the stakeholders can begin.

Building stakeholder engagement is, like everything in Agile, an iterative process.   John Stenbeck says that traditional PM often conceives of the convergence on the solution as a “stair-step process” that is linear, whereas in the real world, the convergence on the solution is an oscillation that goes back and forth with smaller and smaller wavelength until the solution is reached.

Process 1.2–Vision Statement

Although the tool is called “Vision Statement”, the closest tool I could find in John Stenbeck’s book to this description is the “Product Vision Box”.

Taking the place of the project charter in traditional project management, which contains a high-level description of the product that is being proposed to be created by the project, there are a group of tools which are used in Agile to convey to the customer what they can expect from the project.   The first tool is a Product Vision Box which conveys this in a combination of graphic images and narrative content.

Process 1.3–Project Data Sheet

The second tool used to communicate the vision of what the product will be is called the Product Data Sheet (PDS), which is a one-page summary of the key objectives of the project, the capabilities that the product will have, and any additional information needed to understand the purpose of the project.

These tools are also used in the Communication knowledge area, but they are included separately as tools under the “External Stakeholders Engagement” knowledge area in the Initiate process group because these tools are especially useful in the initial dialogue with stakeholders.    It gives them something tangible to react to, with the Product Vision Box being obviously a more visual tool than the project data sheet.

Process 1.4–Active Listening

Have you ever seen an interview on TV by someone who is not quite skilled enough as an interviewer?   They will ask a question, the person will answer, the interviewer will say, “right” in a neutral voice, and then continue on with the next question.  They are focused on their list of questions, and the unenthusiastic response to the answer shows that they are not actively listening to it.   They are passively listening to it, and are interested only in when it ends, so they know that is their cue to tell the next question.

You cannot be a passive listener on an agile project; you must be an active listener.   In the case of the interviewer, if you have a series of questions you’ve written down, and the person responds with an answer that takes the interview in another direction, well then you respond to the person’s answer and make it seem like a conversation, which is what it should be.

Active listening in an agile framework means focusing on the stakeholder you are speaking to in order to craft your message specifically in a way that is going to be more meaningful to them, and then listening and making sure you understand what the stakeholder means.   This may mean paraphrasing what they are saying to you to make that you have really gotten the message they are sending you.

Although this last tool seems perfectly suited in the Communication knowledge area, it is nevertheless in the Stakeholders knowledge area because it is particularly important when speaking to stakeholders (and I would add, to management and team members as well).

The next post will cover the first process, Process 1.1 Stakeholders Identification, in more depth.

Filed under: Uncategorized |