There continues to be a lot of discussion about certification and the value of certification. Most recently at PM Hut with Certifications Don’t Make Project Managers. The article argues that PMP certification is not useful because we still fail at projects at an alarmingly high rate. I think it is a flawed argument in many regards (check my three or more comments) but I understand the underlying concerns. First, that hiring managers take certification to indicate an improbably high level of competence. Second, that there are talented people that can’t or choose not to pursue certification. Let me address both of these concerns.

What Does Certification Imply

From my experience, a PMP is like a recent college graduate, a medical resident, or a 16-year old who just got their license. They have shown interest in being project managers, have some situational awareness from having participated in projects, have been educated in the fundamentals and share a common language. But they are not prepared to be CEO of a business, an emergency room surgeon, or a cross country truck driver. I am not sure how big a problem this really is.

The Dreyfus Skill Acquisition Model identifies five stages of competence:

• Novice: Basic understanding of concepts. Adherence to rules. No discretionary judgment.
• Advanced Beginning: Situational perception. All aspects of work treated with equal importance.
• Competent: Coping with crowdedness. Formulating routines. Able to recognize patterns.
• Proficient: Holistic view. Senses deviations from the pattern.
• Expert: No longer relies on rules. Based on deep tacit knowledge. Vision of what is possible.

Certification takes you no higher than Advanced Beginner and probably doesn’t guarantee any more than Novice. But a Novice is way ahead of the competence curve from someone who has no idea what to do.  To be a great project manager who can run projects in complex organization unsupervised you probably need to rise to the level of Proficient or Expert. Additionally, Getting beyond Advanced Beginning requires more than just some knowledge. We talk about Knowledge, Skills, and Aptitudes. Beyond project management knowledge, there are soft skills and organizational aptitudes necessary to be successful leading complex projects.

I don’t think that the concern that hiring managers and HR departments place too much weight on the PMP is a real problem. In my conversations with HR managers and hiring managers, they aren’t assuming more than this. The fact that hiring managers are asking for PMP’s as an entry point means that they are looking for a common starting place and basic level of intent and awareness.  If they want to greater level of Skills and Aptitudes then they should interview for these. PMI supports this model through their Project Manager Competency Development Framework.

People Who Can’t or Won’t Earn Certification

I earned my PMP in 1998. I have been active with PMI since then including working as the Deputy Project Manager for OPM3 and my current work as a member of the OPM3 Services Advisory Group and on the board of the PMI Agile Virtual Community. My PMP lapsed in 2001. I have not renewed it. Why? At the time it was partially due to the neglect of not attaining and recording PDU’s and partially due to tilting at this certification windmill. I felt that the real value of PMI was in the community and in advocating for responsible project management. I put my money where my mouth is – I support the community and advocate for responsible project management. I don’t really need my PMP at this point to get a job. If I did, I would have it. In fact, I wish I had kept it as I gained nothing by tilting at the PMP windmill.

If you can’t get a job because you don’t have a PMP or can’t pass the PMP test, then you should get your PMP. Unless you want to be unreasonably stubborn – like I was – or want to continue to not be evaluated for a job. This argument just doesn’t hold water for me. While I have known plenty of super capable, super talented project managers that were PMP-less – they had the language, they had the hard and the soft skills, and they had the organizational aptitudes to be successful. It is a logic fallacy to say that because there are good project managers without PMP’s that you shouldn’t look for PMP’s to be your project managers.

Tilting at Windmills

The shame of this is that there are real issues with project management today. We don’t have a clear enough path for determining Agile Project Managers (ICAgile is looking to address this shortly). HR organization’s fail to interview effectively for situation appropriate Skills and Aptitudes. Many companies don’t invest in the developing project managers further up the Dreyfus model. Organization’s are still poorly designed for adapting to change and supporting project execution.

However, none of this has anything to with the value of the PMP or other types of certification. Certification is the beginning of the journey. It is the first driver’s license, the college degree, acceptance into the residency program. Certification is critically important. It sets the baseline. It establishes the basic body of knowledge that is expected. It creates awareness in HR departments and with hiring managers of what kinds of knowledge they should be looking for.

So, rather than tearing down certification and slandering organization’s that have promoted our profession and created great communities for us – let’s put our energy into:

• creating awareness of the need for further growth
• promoting to individuals and hiring managers the Knowledge, Skills, and Aptitudes needed to climb the Skills Acquisition Model.
• communicating the value that organization’s receive when they are organized to be adaptable and execute strategy well

There is power and benefit in these activities. The continual bashing of certification and the organization’s that support them is just useless tilting at windmills.

Alistair Cockburn, in the Oath of Non-Allegiance, has issued a call to action for the software development community to stop bickering and calling out contending methodologies. He has called for “discussion about whether an idea (agile plan-driven impure whatever) works well in the conditions of the moment.” As someone who has earned his PMP, CSM , received certificates from the Lean Enterprise Institute, and who completed David Anderson’s Kanban Coaching workshop – I have had the opportunity to see this bickering up close. I have occasionally even as the target of it.  Here is Alistair’s call to action:

I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.

This is becoming an increasing familiar theme. We see it in Laura Brandeburg’s Business Analyst Manifesto. It is expressed by by Liz Keogh, Jean Tabaka and Eric Willeke in “A Community of Thinkers”. I am involved in a PMI Agile team where we are trying to make sense out of the benefits associated with bringing together the PMI Body’s of Knowledge (Portfolio, Program, and Project) in the context of Agile. I am working with the IIBA’s Agile Business Analyst core team to express the Business Analysis Body of Knowledge in an Agile fashion. I also participate in various Yahoo and Google groups where we are working at having these kinds of conversations involving Kanban and Lean.

These teams and discussion groups bring together practioners and thought leaders from various communities working to understand and to share. Sometimes the discussions get heated. You have a lot of successful, intelligent people sharing their experiences and trying to make sense out of their successes while simultaneously trying to expand their world view. The awesome thing is that there is a lot of learning and connecting going on in these communities.

You may want to protect your turf -  but this is the future. The tools and resources that support software development have improved orders of magnitudes in the last two decades. It’s crazy to believe we don’t have a long way to go to figure out the best ways to deliver software – especially at the enterprise.  Tom Peters quotes General Eric Shinseki, Chief of Staff, U.S. Army – “If you don’t like change, you’re going to like irrelevance even less.” I choose to join the community who is looking for ways to honor the fundamental premise of the Agile Manifesto – We are uncovering better ways of developing software by doing it and helping others do it.

One of the Yahoo groups I belong to, pmiagile yahoo group, is exploring whether there is any synergy between Agile and the PMBOK. Its is an interesting yet somewhat frustrating discussion. I think we should try to avoid platitudes and clichés. I understand that there are many project managers that have interacted with development teams in ways that were destructive. I understand there have been agile teams that were not responsible in their approach to development. This discussion should not about how individuals or organizations have behaved badly. It is about looking at an established body of knowledge, the PMBOK, to see if there is anything worth learning from there that could help us in uncovering better ways of developing software by doing it and helping others do it. Todd Little recently posted:

“It would be more productive to look at what problems exist that current agile implementations do not support well. Dennis is suggesting that there are gaps that agile does not answer. I’ll buy that there may be some gaps. What are those gaps? What are the user problems that need to be solved? What are the user stories and acceptance tests for those problems? Maybe then we can look at the PMBOK as a potential source of solutions to users that have those problems.”

I believe it is pretty important that the participants in this discussion have a pretty clear understanding of both Agile and the PMBOK if they are going to offer up opinions on one or the other. I have been involved in software development since 1985 (RPG2/3/400, C++, Perl, Java, C#). By the mid 1990’s I was leading development teams following an Incremental and Iterative development process. I purchased my version of Eliyahu Goldratt’s the Goal in 1994 and Critical Chain when it came out in 1997. I was busy reading and applying Larry Constantine’s Peopleware,  James Highsmith’s Adaptive Software Development, Kent Beck’s eXtreme Programming, and Alistair Cockburn’s Crystal methodology before I knew what the Agile movement was. I was explicitly applying value stream concepts, visualization, and limited WIP before 2000. I have always mixed and matched based on what made sense on my current project. I have actively been coaching and applying these ideas for over 15 years. I claim Agile chops.

I earned my PMP from PMI in 1998. I have produced hundreds of project artifacts including project plans, charters, and risk plans.  I was the Deputy Project Manager on the development of PMI’s Organizational Project Management Maturity Model (OPM3®). I have actually read through my PMBOK 4th Edition in detail. I am qualified to speak about the PMBOK.

The PMBOK

Let’s talk about the PMBOK for a few minutes. First off, the PMBOK describes good practices in project management that work for most companies most of the time. The PMBOK Guide also provides and promotes a common vocabulary within the project management profession for discussing, writing, and applying project management concepts. The PMBOK points out that the standard is neither complete nor all-inclusive. Additionally, the standard is a guide rather than a methodology. One can use different methodologies and tools to implement this project management framework. The PMBOK is not specific to software development – this language and this guide support all types of projects.

How The PMBOK is consistent with Agile

PMBOK supports self organizing. It is up to the organization and the team to determine what is appropriate for any given project.

PMBOK supports sprints and/or real-time planning. PMBOK doesn’t require big up front planning and then rigorous adherence to plan. PMBOK talks about iterations and progressive elaboration. Progressive elaboration is continuously improving and detailing a plan as more detailed and specific information and more accurate estimates become available as the project progresses, and therefore producing more more accurate and complete plans that result from the successive iterations of planning.

PMBOK supports continuous improvement. This is an iterative means of improving the quality of all processes, reduces waste, eliminates activities that do not add value, allows processes to operate at increasing levels of efficiency and effectiveness.

PMBOK supports overall adaptation of the product and the organizational processes. The Risk Management Section of the PMBOK calls for a continuous approach to identifying, monitoring and responding to risk. Technical Risks (including Requirements Risk and Quality Risk, External Risks (including Market and Customer Risk), Organizational Risks, and Project Management Risks.

How the PMBOK complements Agile

In many cases, software development takes place in a bigger context then just the software development team. This bigger complex can be messy, with lots of activities that have to be coordinated to deliver value to the customer. Here is a peak into that messy context.

In front of development this includes activities like market research, strategic planning, sales forecasts, budget forecasts, and making investment decisions.

During development activities need to be coordinated with development including procurement, vendor contracts, compliance research and documentation, legal evaluations, intellectual property protection, developing and implementing security, privacy and data protection controls, and designing changes to business process.

For each release of software, activities outside of development include, establishing sales and marketing readiness, updating customer service policies and procedures, updating business resilience procedures, updating impacted training and implementation procedures, updating customer service levels, re-aligning reward and recognition programs, and updating internal IT service level agreements. Then there are often launch activities around customer communication and product promotions and ICT coordination including licensing and production operations.

The importance of these activities will vary between contexts – but these are all real activities that I have had to handle on software development projects. In Agile, these are hidden behind the Production Owner or Onsite Customer abstractions. But in the process of delivering value to an organization or new product to a customer, these may exist, need to be coordinated, and aren’t particularly interesting to the software development team. This type of coordination needs to be done in a way that enables the Agile teams – to achieve the goal of delivery of value to the customer.

Barriers to Synergy

From the Agile perspective, barriers to synergy arise from the sense that PM’s will meddle in the performance of the team. This is based on historical experience and potentially a lack of understanding of real organizational constraints that result in obstacles for the team. The PM becomes the representative for these unreasonable constraints in a “shoot the messenger” fashion. The other big barrier to synergy is the prevalence of language in the PMBOK that is contrary to Agile values and principles. Make no mistake, from the definition of the project manager, through the use of words like directs, controls, and manages the language is an obstacle.

From the Project Management perspective, barriers to synergy arise from the primacy of developers and the development team in Agile talk. Project Managers also perceive the agile teams have a limited view of what “the product” is and what it takes to provide value to the customer. The project manager lives in that messy place behind the overly simplistic abstraction of the Product Owner.

How Do We Address These Barriers

Acknowledge that Agile and the PMBOK come from a different mindsets

Not regarding iterative and incremental development but from values and principles. We need to recognize this gap and start the discussion from the perspective that we are building on Agile values and principles.

Recognize that delivering value to the customer is often beyond the scope of the development team

The product is bigger than development. There is work to be done that isn’t best done by the development team. This becomes a bigger and more important deal when you are working in companies of any scale.

Acknowledge the Limitations of the Product Owner Abstraction Layer

Look back at How the PMBOK Complements Agile. That messy list of activities point out how big the set of issues are that the Product Owner is responsible for.

Distinguish between Project Management Practices and the Project Manager Role

The PMBOK is the Guide to the Project Management Body of Knowledge. It isn’t about project managers. In a small organization, with a limited number of products, with intimate access to customers, lots of automation, and a limited requirements for supporting infrastructure, the project management activities can likely be handled by a couple of people with very little coordination effort required. But in organizations of scale, the coordination effort will benefit from someone focusing on coordination. In both cases, the project management practices should be addressed – sometimes with a role and sometimes without.

Can Agile learn anything from the PMBoK?

Yes, by addressing the barriers. Start with Agile principles and values, look at the larger value stream from the customers perspective, understand the limitations of the product owner abstraction, and creating clarity about roles and authority regarding project management practices. Use the PMBoK as a placeholder for conversation about the Knowledge Areas and the purposes behind the tasks. As the PBMoK points out. the organization and/or team should decide what is appropriate for them for each project.

Here’s a starting point for the Ball in Court discussions

The conversation is about decisions rights and levels of authority. I have listed the PMBOK knowledge areas and some potential separation of authority as a starting point. I want to be clear about my perspective on this conversation. In a doubles tennis, everyone on the same side of the net is on the same team. Sometimes, the ball is in one person’s court and sometimes it is in the others person’s court. But when playing tennis the partners play the game to help set each other up for success and may back each other up if possible. I view these authority discussions as ball in court discussions.

Additionally, this starting point is going to be wrong for your organization. But making perspectives explicit helps start the conversation. This initial view is based on a discussion on the pmiagile board that I had with Ron Jeffries. I am not  claiming that Ron has endorsed this approach or these distinctions. What is important is that Ron Jeffries and Todd Little are willing to explore this line of thinking.

PMBOK Knowledge Area [potential authority]

Project Integration [development team inside development, project manager outside development]
Project Scope [product owner, project manager facilitation]
Project Time [development team]
Project Cost [product owner, project manager]
Project Quality [the development team, project manager facilitation]
Project Human Resource [project manager]
Project Communications [development team inside the team, project manager outside development]
Project Risk [product owner, development team, project manager]
Project Procurement Management [project manager]

A question that comes up a lot in Kanban is, “How can I know when this feature will be done?”.  First off, it is important to understand what makes estimating unpredictable – and then what steps Kanban presents to address this. Estimates are unreliable because the inherent variability work is compounded by the lack of flow in most teams and destructive behavior caused by fixed point estimates. Kanban, through a few simple techniques, a little bit of math, and the decoupling of planning and scheduling will give you the ability establish accurate estimates with minimal effort.

Cycle Time

The key metric we will use for estimating is Cycle Time. Cycle Time, in most Kanban and Lean contexts, is the time between when the team starts working on an item and when the item is delivered. Cycle Time is what is interesting to managing (whether managed by management or self managed) the team. This metric becomes a key management metric to reduce variability in the system, make reliable commitments, and provide insight into whether improvement efforts are delivering expected results. We are going to talk about using Cycle Time to make reliable Due Date Performance commitments.

Cycle Time is easy to capture. When a card is pulled into the first work queue – enter the date on the card next to Start. When the card is moved to the last queue, enter the date on the card next to Finish. Cycle time is Finish Date – Start Date. At the end of the week, when you pull cards off the board, capture the cycle time for each card into a spreadsheet or whatever tool you are using for tracking.

Distribution Curves

What you will most likely find after you have captured a little data is that lead times fall in a distribution that is skewed to the right. This shows the variability in the work that you perform – there is some absolute limit on the shortest time the work can take – but there are a lot of ways it takes longer. Take the Cycle Time data and find the Mean and the Standard Deviation. Then set the expectation to the Mean + 1 Standard Deviation.

In this chart the work items are taking from 5 to 15 days. The Mean is 8.6 days and the Standard Deviation is 2 days. You can set a Due Date expectation 11 days and and be sure that you will hit this date about 80% of the time without changing anything you do. So that’s the policy, we will deliver work within 11 days with an 80% due date performance expectation. Over time, we hope to be able to improve the 80% and the 11 days.

There are a few nice things about this Cycle Time number. It takes a lot of complexity into account. Your Cycle Time calculation will have already incorporated the impact of rework while in the system, the typical impact of disruption from expediting, and the impact of waiting in the ready/done queues.

What about the 20% that will be late? There are a couple of things you can do. First, you will begin to be able to identify early which stories are going to be late. These will be ones that are more complex or end up with lots of rework. You can address these with capacity, prioritizing and/or communication to the customer. Addressing it with capacity means swarming on the task to bring it in closer to the due date. Addressing it with prioritizing might mean moving the card up higher in the stack then one that is likely to be done early. The cost of swarming and prioritizing means that another card might be delayed – but if you are thoughtful about prioritizing and swarming you won’t cause delay outside of the Due Date promise. For some cards, you will communicate to the customer that the card will exceed the due date performance expectation – while not optimal this is within your delivery commitment as long as it doesn’t happen more than 20% of the time.

T-Shirt Sizing

Many teams are dealing with work of various sizes. If you do a frequency analysis of your data you will probably see clusters of data. In the picture below we have three clusters.  Rather than spending significant time in complex assessments to support estimating, the team can rapidly assign tasks into these clusters. We call this T-Shirt size estimating. Cluster like work into XS, S, M, L, and XL. You may decide that you don’t accept XL tasks without decomposition or require breaking them down. Then determine estimates for each size based on Mean + 1 Standard Deviation for each of the clusters. You can determine some simple process for assigning work into one of the T-Shirt sizes.

This won’t give you perfect estimates. Perfect estimates are almost impossible to determine. Additionally, Cycle Time Variability is probably impacted more by variation in the system like waiting and rework then anything else. It is impossible to determine the impact of the system by more deeply analyzing the task. With T-Shirt sizing and Cycle Time, you can get as accurate results in minutes as could you do in months. While not perfectly accurate – it’s as meaningful as anything you can do.

Schedule a Release

One of the interesting concepts in statistics is the concept of Regression Toward the Mean. What this means is that when you bring a lot of estimates together, you are likely to  have a final result where the average over time is close to the historical average. One example of this is driving to work. If you were asked to plan how long it would take to get to every stoplight on the way to work exactly, this would be impossible. But you have a pretty good idea what time you need to leave home each day to arrive at work at the right time.

Because of regression toward the mean and the actions we can take based on the visibility Kanban provides us, using T-Shirt sizes and cycle time to schedule a release will result in a pretty accurate estimate – and the cumulative estimate will be more precise than any individual estimate.

Decouple Planning and Scheduling

From a human nature standpoint, data can be a dangerous thing. The way we often couple planning with scheduling of resources is an example of this. With the way we have historically run projects, we put all the estimates together and then hold the team accountable to each individual estimate. This is unreasonable because we know that the estimate represents a range of possible outcomes. Five problems arise when we tightly couple estimating and scheduling of the work.

1. Bludgeoning: If we produce point estimates when outcomes are probabilistic – and then hold people accountable to hitting each individual estimate we are going get value destroying behavior. Bludgeoning people when they don’t hit 80% estimates means we are going to get 95% estimates. In most cases, the 95% estimate is about twice the duration of the likely outcome. This puts a lot of padding into the system.

2. Sandbagging: Another destructive management behavior when we couple planning and scheduling is accusing the team of sandbagging. This happens when the team delivers something in half the time of the estimate. Management will often want to go back and cut the “excessive padding” out of the rest of the estimates. First off, management drove the sandbagging behavior. Secondly, we know statistically that most work should be delivered earlier than an 80% or 95% estimate. The team learns not to deliver early because management charges them with sandbagging. So teams don’t deliver early and consume time that, on average, we need to accrue to the project.

3. Parkinson’s Law: Typical management techniques result in the team delaying delivery until the last moment. One outcome is that work expands so as to fill the time available for its completion. This is problematic because it leads to gold-plating of work that increases downstream efforts. It also ensure we don’t deliver a task that could be delivered early doesn’t get delivered early.

4. School boy Syndrome: The other behavior spawned by this is that the team doesn’t start as soon as possible because they wait until they think they need to start to deliver. This often means the team will start in time to deliver on the likely outcome – but deliver late when the task turns out to be more complicated or runs into a delay.

5. Murphy’s Law: If something can go wrong it will. We know that some work will take much longer than other work. This is Murphy’s Law. The behavior that arises from coupling planning to scheduling combined with Murphy’s Law ensures that projects will be delivered late – even against a 95% estimate. It is said that the losses accumulate and the gains are lost.

Kanban Helps Reliably Determine When Work Will Be Done

We can’t precisely predict how long work will take. Estimates represent a wide range of possible outcomes. In traditional project management, we ask for unreasonable estimates and then manage the work in such a way that we guarantee the project will be delivered late. Additionally, late delivery of work is as often driven by behavior that inhibits flow as the uncertainty around the work effort.

In Kanban we use Cycle Time data derived from the performance of the system to plan when work will be done. Then we decouple this planning effort from work scheduling – using the Kanban board to focus the team on flow. Kanban provides the team opportunities to make capacity and prioritization decisions that help address the innate variability of the work being performed to deliver within the policy. Cycle Time estimates, combined with limited WIP and a focus on flow, helps Kanban helps deliver predictable outcomes.

Last week I wrote a post on Iterative and Incremental development. In that post I pointed out that you can do iterative and incremental development without having time-boxed iterations. Mike Cottmeyer asked in a comment to clarify when time-boxed iterations made the most sense and when continuous flow made the most sense. This post answers that question.

When Time-boxed Iterations Make the Most Sense

Time-boxed iterations serve several purposes that are not well served in continuous flow. They create an opportunity for the team to stop and get feedback from the customer on their product.  They can help with chunking up work to support the planning process and validation of the design of the solution. There are times when this is really important.

So, time-boxed iterations work best:

1. When there is a lot of opportunity for feedback on current deliverables to significantly update subsequent work

2. When the planning horizon is stable enough that a subset of the backlog can be prioritized for at least the duration of the iteration

3. When the backlog items can fit in the iteration time-box

4. When dependent resources (for example, planning and testing) can not be available to support continuous flow

For example, time-boxed iterations work best at the outset with a new product, new technology, or substantially new set of features.

When Continuous Flow Makes the Most Sense

Continuous flow has some advantages over time-boxed iterations. Overtime, the level of resources available to do work is higher and the backlog is much more flexible and adaptive to variation in the arrival of work. For example, once the product architecture is stable and well defined and work is arriving in bursts with various levels of urgency.

So, continuous flow works best:

1. When the work is arriving continuously

2. When the planning window can be (or must be) very small

3. When the outcome is pretty clear and feedback is not as likely to impact subsequent work

4. When there are multiple work streams operating at different cadences

For example, continuous flow when working on defects and small enhancements in a stable product or working with technical support issues.

Non-relevant factors

Effective planning. Data can be gathered from both iterations (velocity) and continuous flow (lead time) to determine when a product can be delivered and to establish visibility into the current status of the project.

Retrospectives. Iterations create a natural break for retrospectives. There is no reason why retrospectives must be tied to iteration releases. Continuous flow teams can have retrospectives on either an event driven or calendar driven basis.

Motivation to get to done. Iterations create pressure to complete work in a specific time-box. Continuous flow creates pressure to met lead-time commitments (policies).

How they can work together

We are making a standard practice of combining Kanban at the strategic planning level to support continuous flow of strategic initiatives across the organization and Scrum (or Kanban) at the development team level. It doesn’t make sense to us to create time-boxed deliverables at the strategy execution deliverable level. We generate plenty of pressure to move forward from the time commitments on the tasks on the Kanban board. At the development level – when there is a lot of opportunity for feedback to update subsequent work – we (may) use iterations to keep the team focused. For defects and minor enhancements we continue to use a continuous flow model – maybe within the same team.

Iterations versus Continuous Flow?

I believe this is a hammer versus saw discussion. Each approach is suited to fit different scheduling and feedback needs. In many cases, time-boxed iterations make a lot of sense but would result in a less than optimized approach then in other cases. I believe that early on in a product (when there is a lot to be learned and a lot of risk to manage) iterations probably make the most sense. At some point, when the product has switched primarily to support, continuous flow makes the most sense. I hope this answers Mike’s question from my previous post.

Most of the studies that discuss failed software development projects find misunderstood requirements and inadequate change management among the leading causes of failure. These failures can’t be adequately addressed just through more rigorous documentation or web based tools. Generating shared understanding is a social act – therefore, one of the elements of improving requirements is through improving the related social interactions or conversations.

But how do we go about improving conversations? Where are the engineering practices or process improvement techniques we can apply to consistently achieve improved performance? John Searles has written several books that break down conversations into a series of speech acts and even has a notation for describing a conversation. I found Searles work on Speech Acts to be very interesting. There is value in classification and understanding of patterns in conversations. But I am not sure this translates to an easily digestible approach. I also believe that conversations have flows and states, but I am also not sure that a process flow is an effective way to represent a conversation.

I can’t break the process of the flows and states a cake baking in the oven goes through down to detailed steps. I can tell you when it might be appropriate to bake a cake, when we are ready to put the cake in the oven, what happens during the baking process, and I can tell you how to check to see if a cake is done. So the approach I am advocating here is to be able to know when a specific conversation is called for, what it takes to be prepared for a conversation, how to approach the conversation, and how to check and see if the conversation has been performed.

Conversations for Shared Understanding

A conversation for shared understanding often involves one person on the project learning something new from someone else on the project. Conversations for shared understanding are important between different functional groups and when defining expected outcomes. For example, requirements documents define what needs to be done on a project. The requirements documents by themselves are typically not adequate. The gap in understanding leaves room for the development organization to build something that is not optimal either from a development or a requirement standpoint.

I love college football. One Saturday when I first got married, I was watching a game on TV. I planned to head over to my friend Steve’s house later in the day to watch the afternoon game. My wife called down from upstairs to ask me to take out the trash. I agreed to do it, thinking I could grab it out of the kitchen on the way out the door after the current game before I went over to Steve’s house. Her context was very different from mine. She meant, right now – all the trash in every room of the house – and clean the bathroom’s while you are at it. So, while I agreed to her requirements, we didn’t have a shared understanding of the request.

When is a Conversation for Shared Understanding called for?

Anytime a lack of shared understanding slows down the project or creates rework or other waste. A lack of shared understanding happens all the time in projects – particularly between functional groups and early in a project. So a conversation for shared understanding is important early in a project. Typically, these early conversations should be around the overall context and objectives of the project. A conversation for shared understanding is also called for with each specific feature or request. On software development projects it is important everyone involved in delivering, verifying, or accepting a feature or project deliverable has a shared understanding. Conversations for shared understanding should be at the outcome and context level. They are not intended for the technical implementation details to be explained to business stakeholders. The point is to establish context and understanding of the outcomes necessary to optimize the performance of the project performers.

What does it take to be prepared for a Conversation for Shared Understanding?

The mood and perspective of the participants in the conversation will impact the ability to successfully perform these conversations. So each participant must have an intention to have a conversation that results in a shared understanding. They should be willing to put in the effort to review or understand any artifacts produced to seed the understanding. They must bring a belief that the other person’s context matters. Additionally, participants need to put some thought into the boundaries of the conversation. The performer will want to think about what they need to understand to be most effective in delivering this request. The requestor will want to consider what parts of the context, what outcomes, and what language is particularly important to ensure they get what they intended to ask for.

How do we approach a Conversation for Shared Understanding?

1. The participants present their expectations and boundaries for the conversation.
2. Each participant explains their understanding of the context, targeted outcomes, and significant language. The other participant(s) will note where their understanding varies.
3. The discrepancies should be discussed, evaluated and resolved. Sometimes, the details of one participant will not be important. Sometimes, more specific discussion is necessary to gain clarity.
4. The participants will agree when they have a shared understanding.

How can we check to see if the Conversation for Shared Understanding has been successful?

At the end of the conversation the participants should be able to present an understanding of context and outcomes in common language. As soon as either participant identifies a gap in understanding they should revisit the conversation. Over time, the participants establish a common background that reduces the effort required to establish a shared understanding.

Today, when my wife asks me to take out the trash I understand what she wants. We also have identified when it may be important to have a conversation for shared understanding. For example, when she sends me to the store for milk I ask her to take a minute and think about what else I should get while I am there. My experience is that she has a lot of background information that I am not aware of. If I go to get milk and don’t get the eggs and butter she needs I will be heading back to the store. Taking the time to have conversations for shared understanding will almost always accelerate the effective pace of the project.

Knowledge based projects, like software development,  are performed by people.  So the way people learn, collaborate and interact is more impactful in knowledge based projects than in traditional projects like building a bridge or a satellite. If Agile software development and Project Management 2.0 have introduced anything new, it is an explicit focus on the social aspects of performing projects. Traditionally project management methods focused explicitly on the processes, tools and techniques of projects.

The traditional tools and processes are still important to the success of projects. We still need to clearly define scope, coordinate project resources, and manage commitments and acceptance of work. But these are social endeavors – and they can’t be accomplished with tools and processes alone. They require an intentional focus on the social aspects of the project. The shift toward the social focus is reflected in the Agile Manifesto’s first value, “Focus on individuals and interactions over processes and tools”. This shift in explicit focus is not an abandoning of processes and tools – rather an intentional focus on achieving these purposes to include people and interactions.

Project Conversations

How do we manage these social aspects? It is through conversation. Conversations are the use of language to exchange thoughts, ideas, or information. Understanding, Coordination, and Commitment within the team arise through conversations. John Searles wrote about how conversations can be defined with clear outcomes and broken into specific series of acts. Gordon Pask wrote in Conversation Theory about how understanding arises based on our interpretation of another person’s behavior.

Using these approaches we can construct ways to improve project performance through improving conversations. But, this isn’t a touchy- feely effort. For each specific conversation there is a specific set of outcomes and a specific set of “speech acts”. Intentionally deciding what conversations need to occur, when they need to occur, and what they look like when they have been completed will  improve the performance of interactions on Agile teams. Over the next week I will be discussing various conversations around understanding, committing, and coordinating. I will present a starting point you can use within your teams to have the meta-conversation to improve these conversations. Then I will build on each of these conversations at each order of scaling (small team, multi-team, program, enterprise).

You may already know that Mike Cottmeyer and I signed a contract to produce a book that describes situation specific approaches to scaling Agile in the Enterprise. This book is based on the work Mike and I have done over the last 10 years or so in helping organizations improve their ability to deliver value to their customers. While we have done the customer engagements separately, we think about this in a similar way and have been able to consistently deliver results to our clients.

Mike and I need to write about 157,000 words over the next 9 months to produce the content for the book. We will be blogging most of the ideas as we write the book and really look forward to your comments and feedback on our approach. Learning to tell the story so it resonates is really important to achieving our goal of writing a book that is very valuable to managers in organizations who are facing the Scaling Agile challenge.

Common Capability Model

A Capability is “an ability or capacity the organization relies on for a specific purpose or outcome”. We focus on capabilities because we are initially interested in What and Why, not on How. Getting caught up in How without clarity on What and Why is common in methodology debates. We Call this the “How Trap”. Using a capability analysis approach we have been able to get people out of what we call the “How Trap” and get them thinking about purposes and outcomes.

As a core part of communicating how managers can develop situation specific strategies for scaling Agile, we are building out a common capability model. Why not use an existing model? Well, we are working from the understanding that there is no single model that is outcome/purpose focused that can be used to build out the scaling. We need to build that base – not by recreating it from scratch but by building on top of traditional models that have worked at the enterprise level, like CMMI and PMI, as well as Agile approaches that have worked at the team level like Open RUP, Scrum, and XP.

As I introduce this capability model, I will start from a Scrum/XP perspective even though those methods are based on practices and not Capabilities. For example, iterations in Scrum and short releases in XP are about Limiting Work in Progress. So is incremental development in Open RUP. I will introduce the Big Agile Capability Model in terms of  Agile practices. I will show how they are complementary to the traditional models and how this outcome-based understanding helps us develop a situation specific approach to scale. Finally, I will talk about common dysfunctions in organizations that limit effectiveness.

Capability Analysis

I have been working on this consolidated capability model for a few years. At a number of clients, I have used an approach based on a consolidation of CMMI, OPM3, XP, and Scrum. More recently I have included Kanban and the Open RUP in the model. At higher levels of scaling I rely on some other capability models like the Process Classification Framework, ITIL, Pragmatic Product Management, and the Business Architecture work I did at Microsoft. The goal is always to find a way to talk about outcomes and purposes before we talk about implementation.

The trick is in translating these jargon specific detailed models into something straight-forward that facilitates the development of situation specific strategies for scaling Agile. This is a challenge that Mike and I are working through now. Before everyone pukes on the idea of basing our approach on a capability based model, I want to cover a couple of important things.

First, I am not a big fan of staged models. I get the concept of CMMI’s levels of maturity – it is important to establish maturity in the lower level processes to gain benefit from the higher level processes. But I believe an organization can make progress on higher-level processes while they don’t have all the lower level processes in place. The capabilities are interdependent and so can’t be addressed in a linear manner.

In OPM3, the model is not staged. You pick an area of focus, such as project cost or program risk, and the model will walk your though capabilities related to that strategic area. Like OPM3, our model is not staged or prescriptive in nature. We talk about these in an order, but in reality, the team needs to be focused on improving capabilities based what makes the most sense for a specific situation.

Second, I don’t like the idea that Product Development, Project Management, and Software Engineering (http://www.dennisstevens.com/2009/03/12/project-management-product-management-and-agile/) are evaluated separately and independently of other the rest of the organization. They are too tightly integrated in real life once you get past the small team to be treated separately. At the end of the day, there is no point in getting better at any of these areas if it doesn’t result in an improvement in delivery of value to the customer.

Finally, one problem I have with formal capability models in adoption is that these models come off as overly complicated, prescriptive, and aren’t typically treated as situation specific. Typical models drive the conversation, “What do I have to do to pass an audit”. We want to change the conversations in the business to, “What is the next most important thing we can focus on to improve our ability to deliver value to my customers”.

The Big Agile Capability Model

The model that Mike and I are working on starts with Small Team Agile. We build this out to Horizontal Scaling, where you have multiple teams doing Agile development on distinct outputs. Then we build out to First Order Scaling, where multiple Agile teams are working together on a single product. At Second Order Scaling, multiple Agile teams are working on multiple products. At Third Order Scaling, we are working to leverage the ability to rapidly deliver working software across the Enterprise. Wrapped around this is a set of common capabilities that apply to every level of scaling. Over the next several days I am going to describe the capability model we have derived from our experience and research. As with everything else in the book, this model is subject to change.

I am going to describe the Small Team agile capabilities over the next few days. Over the next few weeks, I will go into the capabilities associated with Horizontal scaling, then First Order, Second Order, and Third Order scaling.

As we go through our approach, please share your thoughts – good and bad – with the approach and how it is being communicated. We need to make sure this is valuable contribution to the body of works hoping to improve our ability to deliver high quality products that meet the needs of customer.

Vasco Duarte over at Software Development Today has launched a grenade at the PMI Agile organization with his post PMI vs Agile, what is different, and why you should care.  He was responding to Lynda Bourne’s post Agile: The Great Debate. I started writing a comment that became really long so I decided to put this up as a blog post.

First, I must admit to having an advantage over Vasco in that I know Lynda Bourne. She is a talented and smart project manager who focuses on issues of engaging people in the right way. People in the Agile world would appreciate her sense of humor, empathy, and focus on treating people the right way. I don’t know Vasco. I like what he says on his blog for the most part, I see his tweets and comments on Twitter, and I think he is an intelligent experienced guy with a valuable point of view.

This conversation fascinates me for a number of reasons. First, one of the tenets of Agile is to value people and interactions over processes and tools. This manifests itself in respect for people and learning. One of the things I teach in my project conversation work is the importance of holding the other person as valid – believing what they have to say matters. Yet in this Agile vs PMI conversation there is a lot of not holding the other person in a very positive light. Another is seeking first to understand, the common approach is to point out what is wrong with the other persons world.

In her post, Lynda points out that there are three areas for discussion between PMI and Agile.

1. How do Project Management practices differ when interacting with Agile development vs. Waterfall development?
2. Can traditional Project Management learn from Agile?
3. What triggers choices between operational maintenance, development and projects and waterfall vs agile techniques.

I think these are good points for traditional Project Managers to understand as they make decisions about how to support a project with an Agile software component.

Vasco took offense about two points Lynda made in the first question regarding a PM moving to Agile from Waterfall. Remember as you read this that she is writing on PMI’s website to PMP’s.

• The need for robust change management and configuration management to track the evolution of the Agile project
• The critical importance of developing the correct strategy and architecture at the beginning of the Agile project

Vasco says these points reflect a lack of understanding at PMI regarding Agile. He claims her explanation to PMP’s that Agile projects have a strong dependency on change management and configuration management indicates she has no understanding of Agile. However, her reference to change management is in the same sentence as one to configuration management. She is absolutely referring to code. Since many PMI managers aren’t software development manager’s they likely don’t understand the critical nature a robust CI/CM infrastructure. In fact, many “agile” projects fail to implement these and this leads to project disasters. I feel her point is completely valid and Vasco’s retort is not helpful.

Vasco then says she is asking for BUFD. She didn’t say you need a Big Up Front Design. She said you need an Architecture and a strategy for delivery. Even the link Vasco refers us to agrees with Lynda. The first slide asks, “Architecture is a heavy-weight activity, and the magic of Agile makes it unnecessary to bother with up-front design, right?” Their response is, “False.” The presenters point out that this is a common misconception even among Agilists. I believe that Vasco’s retort reflects a bias against bad PM he has faced and does not reflect the validity of Lynda’s post.

Agile (Vasco refers specifically to Scrum) is about Software Development. In most organizations, software development is about 25% of the solution. People, processes, and management practices have to be addressed as well. And not just within the development and delivery of software, but across the entire organization. Project Management deals with this bigger world. The big opportunity is to learn from Agile how to align with and improve delivery outside of software and how to support Agile so the development team can deliver value to the organization with a minimal amount of friction.

I am not suggesting that PMI and all PMP’s have a clear understanding of Agile and how to implement it. I agree that there is a lot of discussion that needs to be held to make the two perspectives meet. I do think it is important that the perspectives meet. PMI is reaching out to the Agile community. They are making an attempt to understand and be understood. There is also a real need for us to bring these areas together in a way that drives value through our businesses.

Last week I became an OPM3® Certified Consultant. After spending almost three years as the Deputy Project Manager with the volunteer team developing OPM3 Second Edition, I spent a week taking the OPM3 Certified Consultant course and passed the final exam. I have received a lot of questions about what that means and whether there is any value in it. There are about 100 OPM3 Certified Consultants in the world. I want to talk about OPM3, project management standards, getting organizationally mature, and what being an OPM3 Certified Consultant means. This might not sound exciting, but hang with me. There are very few organizations that won’t benefit from getting better at implementing strategy.

What is OPM3?

OPM3 is a standard that was first published in December of 2003 by the Project Management Institute. OPM3 stands for Organizational Project Management Maturity Model. Per PMI, “Organizational project management is the systematic management of projects, programs, and portfolios in alignment with the achievement of strategic goals. The concept of organizational project management is based on the idea that there is a correlation between an organization’s capabilities in Project Management, Program Management, and Portfolio Management, and the organizations effectiveness in implementing strategy.”

[There is some conflict in the terms process and capability. I will use the term capability consistently through my discussion. A capability describes “what you do and why you do it”. A process describes “how”. PMI doesn’t describe “how” in their standards even though they call them processes.]

To put this simply, organization’s have to implement changes in their structure, processes, management practices, and/or technology to implement a strategy. This is difficult but there are some capabilities that have been show to support them in consistently implementing these changes.  These capabilities can be categorized into effectively and efficiently executing projects, the coordination of multiple projects to optimize resource utilization and project performance, and deciding which projects are the best ones for the organization to invest in based on the organizations strategy. These are Project Management, Program Management, and Portfolio Management respectively. OPM3 uses the capabilities identified in PMI’s Project Management Body of Knowledge-4^th Edition, The Standard for Program Management-Second Edition, and The Standard for Portfolio Management-Second Edition. More on standards in a minute.

OPM3 wraps a continuous process improvement approach around these capabilities. For example, when implementing a project you probably want to manage the scope of the project. Within most organizations -most of the time, that means you have to gather requirements, define the scope of the project, and create a work plan when planning a project. There are a lot of different ways to do this. It may make sense on some projects to do this once at the start of the project and on other projects, you should do it iteratively and in progressively more detail. What organizations that are good at executing strategy do is they define how they are going to manage scope. Then they pay attention to how well this works continue to improve their method over time. This is organizationally mature.  OPM3 breaks the capabilities down into Standardize, Measure, Control, and Improve.

OPM3 also includes a set of Organizational Enablers. These are the capabilities that must exist in an organization to support the implementation and ongoing existence of Project Management capabilities. These include things like project management training, project management sponsorship, and other structural, cultural, technological and human resource practices.

You can pick up a copy of the OPM3 standard from PMI’s website for about $100. This standard describes the approach in detail, lists all the capabilities, and includes a nice Self Assessment tool in the appendix.

Project Management Standards

The Project Management Body of Knowledge (PMBoK) is a catalog of capabilities (called “processes” by PMI)  related to the management of projects. When the first OPM3 standard was published, PMI had not published standards for Portfolio Management or Program Management.  These first versions came out in 2006 and have been significantly updated with the simultaneous release of new Editions of the standards for Project, Program, Portfolio, and OPM3 in December of 2008.

The new standards provide a comprehensive catalogue of the capabilities that cover Project, Program, and Portfolio Management. These standards show the capabilities that will work in most organizations most of the time. They are based on years of research and the input of thousands of volunteers. They give examples of existing practices within the capabilities.  Despite what some critics claim, they don’t tell you “how” to implement those capabilities, just “what” you should be thinking about. They also don’t tell you to do all the capabilities whether they make sense for you or not, follow a high ceremony waterfall process, or make the purpose of the organization about project management.

Getting Mature

Maturity is an interesting concept. It has a lot of meanings. Mature can be a show you wouldn’t like your kids to watch, a bill of exchange that is due, or a ripe or fully aged piece of fruit. The definition of maturity I am using here is fully developed. What makes organizational project management maturity an interesting concept in business is that fully developed is different in almost every business. It can also change over time within an organization as the needs for project management change.  The key to organizational project management maturity is not to try to implement every capability with a robust set of process maturity. But to implement the capabilities that are right for helping a specific organization implement their specific strategy. This includes implementing an appropriate level of continuous improvement and only the necessary organizational enablers.

I have written about this focused approach to improving project management performance here and here. Invest when it improves the organizations ability to drive value. The goal is not to get better at project management, it is to get better at profitably delivering value to your customers. Project Management maturity efforts should be tied directly to business results.

 OPM3 Certified Consultant

An OPM3 Certified Consultant isn’t just someone who understands the OPM3 standard. Just to get into the course OPM3 Certified Consultant course you must demonstrate comprehensive knowledge of the OPM3 standard through completion of a SAM assessment or an OPM3 fundamentals course. An OPM3 Certified Consultant has demonstrated significant program or project management experience, since a PMP or PgMP is an eligibility requirement. An OPM3 Certified Consultant also has significant assessing and/or consulting experience.

Once in the course, the consultant is trained on the OPM3 assessment methodology and tool set, and the improvement methodology and tool set. This is during an intense four day training course. The consultant must successfully complete an exam.  The handbook that walks you through this process can be found at the PMI website.

The Value of OPM3 Certified Consultants

Most businesses can benefit from getting better at executing their strategy. Improving Organizational Project Management Maturity is a method of improving the organization ability to execute their strategy. OPM3 provides a systematic approach to identify and implement Organizational Project Management improvements appropriate to each business. Project Management Maturity is a tricky thing – it requires insight and experience to focus improvements in project management so it improves the organizations ability to deliver value to its customers. An OPM3 Certified Consultant has an assessment and improvement methodology, a robust tool set, and has demonstrated the experience with identifying and implementing improvements based on PMI’s standards.

For me, the value of the certification includes the assessment and improvement methodology training I received, the time I have spent with other experienced Organization Project leaders, access to the assessment and improvement tools provided by PMI, and some branding. I can combine this with my experience in software development and IT Operations excellence and cost optimization to rapidly deliver value to organizations. For organizations looking for a way to rapidly improve the performance of thier projects, an OPM3 certified consultant with proven experience and expertise in your domain is a good option. Guided by a proven systematic approach, they can perform an assessment and create an improvement roadmap and tie the improvements to your business results.