Communicating project issues is challenging. Exactly when should we escalate? Who to, and how much of a chance to correct things should be given first? This is why some projects create control limits around critical parameters and develop escalation plans to communicate exceptions and agree on the next steps.

However, on most small to medium size projects, these escalation plans are often missing or left to the project manager's discretion. This creates further problems if the response is too late, not far-reaching enough, or not aligned with sponsor expectations.

Also, what are the expectations for communicating delays, risks and issues at the team level? Do we want to hear when something takes a couple of hours longer than planned (probably not), a couple of days (probably, yes), or a couple of weeks (no, we should have been informed much earlier!)

A "Definition of Broken" (DoB) helps identify and trigger previously agreed exception plans. It is a list of events that allows us to flag and start addressing a problem without the emotions and delays of arguing if it is significant, warrants immediate action, whose responsibility it is, etc.

Just as you do not want to invent a fire evacuation plan during an actual fire, so should exception plans be created before problems arise.

 

Origins

Agile approaches often use a "Definition of Done" (DoD) to describe the attributes that constitute acceptable. For an increment of software, this may include items such as:

• Coded
• Tested
• Refactored
• Integrated
• Reviewed
• Accepted by customer
• …

Some teams also use a "Definition of Ready" DoR to describe the desired state of requirements. For example, this could be an appropriately sized user story that meets the INVEST mnemonic attributes. Similarly, “Goldratt’s Rules of Flow” describes creating a Full-kit that lists all the items required before starting work on something. Then a sprint or iteration transforms the selected items that meet the DoR into increments that satisfy the DoD.

A Definition of Broken (DoB) is a shorthand way of referring to tolerances and exception procedures. Creating a DoB allows us to objectively describe future issues and resolutions before the stress of a problem clouds people's judgment. I have used DoBs with teams for over ten years and found them valuable shorthand terms for significant impediments.

PRINCE2 popularized tolerances and exception plans procedures in the 1990s. While PMI literature does reference risk tolerances and escalations, the PRINCE2 coverage is much broader. Tolerances can be set up around spending trends, quality metrics, sponsor confidence, widget output, or any project parameter you like. The example below shows a tolerance range around projected spend at +10% and -20%.

So, tolerance is an agreed range of variation, like a control range. However, unlike control ranges, tolerances are paired with an exception procedure to be executed if the tolerance range is breached.

 

The Downsides of Tolerances and Exception Plans

While it would be helpful to create tolerances and exception plans for a wide variety of project variables, project managers typically do not have time to document them all and get approval from the necessary stakeholders.

As a result, the good practice of defining tolerances and exception plans is often omitted from projects that do not mandate them for safety, regulatory compliance, or quality reasons. Project managers are too busy to create them, and sponsors don't want to review a long list of "What if this happens…" procedures.

 

Definition of Broken (DoB) Can Help

This is where a Definition of Broken (DoB) comes in, as a lightweight pre-approved emergency response plan. Without all the documentation and signoffs, critical issues that would require sponsor or steering committee intervention can be agreed to in advance. Then, should any of these events occur, there is much less debate before action is taken. This pre-approved action plan speeds remediation and increases the likelihood of recovering from a significant issue.

 

A Couple of Examples

On a project to implement a 3^rd party membership management software package and write new custom code to link the membership system to various in-house developed systems, DoBs were created for likely but high-consequence scenarios. These DoB situations triggered an escalation report to the project steering committee and automatic inclusion as a discussion item at the weekly sponsor review meeting.

Example 1: Vendor Schedule Delay

The vendor's implementation plan showed the core member billing module configured, installed and tested by the end of May.

DoB Trigger: "Billing module not operational on June 30^th" 

(This was a month after the vendor planned to do it. So the vendor was happy to agree to the DoB trigger. Predictably, come June 30^th, the billing module was installed but still not operational. Having the DoB clause with an approved escalation plan meant no debate or weaseling opportunities for the vendor. The item was escalated, bringing in new vendor staff to expedite the issue resolution.

Example 2: Integration Team not Available

Since the micro-services group was a critical dependency, it seemed prudent to get pre-approval to resolve any delays.

DoB Trigger: "The project team waits more than two weeks for an integration or test- environment to be created."

(In this event, the issue will be raised with the Integration director and escalated to the steering committee. Due to many projects requiring work from the Micro-services team, this happened on three occasions. Fortunately, the team anticipated the delays, and the escalation resulted and quicker turnarounds than other projects experienced.

 

How is this Different from Basic Risk Management?

DoBs certainly overlap with risk management. The critical difference lies in the socialization and pre-approval of the escalation procedures to expedite action. Having a risk occur and turn into an issue then requires communication and issue escalation.

Using the risk response route is akin to sending a high-importance email to everyone at the affected location that there is a fire and they must evacuate. Then hope they read it, take it to heart, and act on it with the appropriate urgency. Having a DoB with a pre-approved escalation plan is more like sounding the fire alarm. It has been discussed and approved before; now we just need to do what was agreed. Since issues are like fish smells (they get worse the longer you leave them), things we can create upfront to speed resolution are often worthwhile. 

 

How to Implement DoBs

First of all, we need to be realistic about the effectiveness of DoBs. If we try to create too many, we will not gain the agreement or buy-in for the resolution we need to make them effective. I suggest no more than 5-10. Likewise, they need to be based on critical-consequence threats, not minor impact problems. If we cry-wolf too often, we will be correctly ignored. So, only use them for issues that would threaten the success of the project.

For serial, plan-driven projects, DoBs can be added to the project charter and updated at phase boundaries. Wording can be as simple as:

"The following Definition of Broken (DoB) items identify scenarios that would trigger immediate escalation to the sponsor and addition to the issues list reviewed at biweekly steering committee meeting:

• Building permits not obtained by June 15^th
• The pumping station is not operational at full capacity by year-end
• Telemetry software not completed and accepted by Feb. 28^th“

For hybrid and agile projects, DOBs can be drafted alongside the Definition of Done (DoD) and reviewed and updated at retrospectives as necessary. They can be recorded in the team charter you posted somewhere visible. "Our Definition of Broken (DoB) items that signifies immediate team resolution comprises:

• Customer satisfaction ratings less than 80%
• Servers not installed and acceptance tested by May 1^st
• Page load speeds over 3 seconds
• Critical bug cycle time > 2 days
• Team eNPS below 30”

 

Parting Thoughts

If the Definition of Done (DoD) is a broadly accepted and understood concept in your organization, consider discussing a DoB. Maybe it makes sense to try them? The criteria can be agreed upon with vendors and team members, product owners, business representatives and any group with a stake in the project.

The goal is not to set traps for future punishment but to promote constructive dialog and consensus about what constitutes a significant problem. Then collaboratively define the escalation procedure and gain agreement to expedite these issues, should they ever occur.

The process has a subtly different effect than documenting risks which is often not a collaborative process agreed to by both the triggering and impacted stakeholders. Creating a list of DoBs and making it visible can change behavior and impact outcomes.

Also, discussing issues and escalation plans with sponsors can uncover priorities not identified in the chartering process. The more we learn about what constitutes success, acceptable variation, or failure, the better we can navigate project decisions and direction to better outcomes. 

 

Note: I first wrote about the Definition of Broken (DoB) in my book Beyond Agile.

This article explains what a risk-adjusted backlog is, why they are useful, how to create one and how teams work with them.

What is a Risk-Adjusted Backlog?

A risk-adjusted backlog is a backlog that contains activities relating to managing risk in addition to the usual features associated with delivering value.

Agile projects typically prioritize the backlog based on business value or perceived needs. The Product Owner or business representative prioritizes the backlog elevating the highest value features to the top, so they get delivered first.

Taking an Economic View of Decision Making

Prioritizing based on business value is an example of the lean concept of 'Taking an Economic View of Decision Making.' In deciding which feature to develop first, those with the highest economic value are selected. Taking an economic view of decision making has a couple of advantages.

It is a dilemma. We need to move forward. Not just to make progress on projects, but also to give people something else to focus on beyond the tragedy and fear filling the news.

At the same time, we need to be sensitive to how people have been impacted. We need to demonstrate support and empathy. We need to be available to listen and help wherever we can. We need to step up and be professionals.

Context
More than ever, context is king. How to respond and lead in your environment will depend on how your project and stakeholders have been impacted. There is no universal best response. All I can do is offer some tips for consideration. You can then decide if they apply—and how to implement them for your environment.

Some fundamental changes are coming to the PMP® exam. Currently slated for January 2021, the content and composition of the exam will be completely revamped. As described in the new PMP Exam Content Outline, PMI commissioned a research study into trends in the project management profession. This study, called the Global Practice Analysis, investigated which job tasks and approaches people frequently use.

The job task analysis identified the knowledge and skills required to function as a project management practitioner. Now the PMP is changing to better reflect these practices; here are some of the major changes:  

Phew, the wait is over! I have been wanting to talk about this for what seems like ages and now the official announcement is out! If you have ever been frustrated by the PMBOK Guide now here’s your chance to fix it.

We are looking for volunteers to write and review the next edition of the PMBOK Guide. However, this will not be just an update, instead a radical departure from all previous editions aligned with PMI’s new digital transformation strategy. That’s all I can explain for now, but more details will be announced when I can say more.

Meanwhile, we would like people with knowledge of the full value delivery spectrum (waterfall, hybrid, agile, lean, etc.) to participate.

Creating a great project charter is an art and a science. Anyone new to the profession of project management needs to learn how to create a project charter. It is not only an important early project deliverable, but it also sets the tone and lays out the foundation for the rest of the project.

While we can spend our careers improving our ability to craft effective project charters, we can get to a 70% good-enough state by addressing some basic topics. This article explains those basics.

(Over at ProjectManagement.com January’s theme was “New PMs”. I wrote this article about the choices of approach we have and ways for new PMs to navigate them.)

These days, new project managers are exposed to conflicting guidance. On the one hand, there is a plethora of traditional “Plan the work, work the plan” literature. On the other, media is full of light-touch, self-organizing team advice. These sets of recommendations often appear to be at odds, so what is the new PM to do? Consultants will say, “Oh, it depends…” and start a lengthy (aka expensive) conversation. I say let’s examine the basics so we can make an informed decision ourselves.

Let’s explore what you do and do not put in a backlog. How do these sound?

• Features and non-functional requirements – Absolutely
• Bug fixes and change requests – Yes, probably
• Risk avoidance and risk reduction activities – Sure, maybe
• Opportunity exploitation activities and marketing ideas – Now you’re just getting weird!
• Team building and social events – Erm, no!

Yet, if it’s all just stuff for the team to do, then why not put it in the backlog? Maybe because the customer has not asked for it and the product owner has to own and order it, but let’s look further.

If we used a backlog metaphor for prioritizing backlog work items. It may look like this.

I am not suggesting these are the correct elements for including in a backlog, I am just showing the common ones. However, I am probably getting too abstract too quickly. Let’s start at the beginning.

My PMXPO webinar has now been watched by > 11,000 people and received lots of positive feedback. It is hosted at ProjectManagement.com here.

(For people collecting Professional Development Units (PDUs), it also auto-records 1.25 credits for you.)

The webinar reviews problem-solving through the ages and shows how agile is the rediscovery of many old approaches. Wicked problems are those that cannot be solved with traditional methods or ways of thinking. They are the unique challenges never seen before in your organization, region or industry.

As companies race to innovate and compete in a global market, we are seeing wicked problems more and more often. While the solution may be new, some common steps repeat in the stories of novel problem-solving successes through history. This presentation combines a fast-paced view of wicked problems and solutions through history—with a slower reveal of the common steps for solving challenging projects.

It is ideal for anyone faced with managing projects with lots of uncertainty—or people looking to understand the links between lean, leadership, building collaborative teams and problem-solving.

Watch Now.

I am excited to be presenting on the Enterprise Agile track at the Agile 2018 conference in San Diego, August 7. I have worked with several organizations this year that had issues with work dependencies between teams. My session called “Two-Pizza Team Heartburn Relief: Solutions to Team Dependencies” highlights the shift to global rather than local optimization.

We will investigate dependency problems through animations and simulations and then explore some candidate solutions. Each brings their own issues – if these problems were solvable they would have been already, but the suggestions do help considerably. Here is the description from the conference program:

Small teams are great - until they cause bigger problems than they solve. Small teams can communicate more effectively than large teams. They can leverage face-to-face communications more readily and share tacit knowledge without the need for so much written communication. However, for large endeavours, using many small teams present their own problems. Work dependencies between teams can cause major delays through costly hand-offs, mismatched priorities, and blocked tasks.

This workshop introduces strategies for structuring teams to reduce hand-offs and dependencies that create blocked work and delays. By investigating the (lack of) flow through multiple teams we can diagnose the cost of hand-offs and culprits of delays. We examine tools for making hand-offs and dependencies visible to highlight and bring collective attention to the problems. We then explore resolution patterns and work structures that maximize small team communications but limit negative aspects of managing multiple, inter-dependent project teams.

Learning Objectives

• Understand the time and cost penalties of team dependencies and hand-offs
• Gain tools for making dependencies, queues, and blocked work visible
• Learn how and when to balance small team benefits with more dependency issues
• Share implementation patterns and strategies to maximize team throughput
• Examine the pros and cons of larger teams, feature teams, and product vs. project development.

That probably sounds more technical than it really is. It is a workshop to show people how teams often get stuck with work items when they rely on work from other groups. It combines anecdotes and experiences from 20+ years of agile consulting along with some insights from Troy Magennis on dependency delays, and Dominica DeGrandis, author of Making Work Visible.

Through case studies and exercises, we explore the hidden impacts of well-intentioned small teams. First, we’ll explore the “mostly harmless” two and three team dependencies, and then see the impacts when five or six dependant teams try to get work done. Please come along if you are attending the conference and have issues with dependencies between teams.

I am pleased to announce the availability of my new PMI-ACP Workbook. This new workbook focusses on a smaller subset of 50 key topics.   My original PMI-ACP Exam Prep book distilled all the relevant content from the 11 books on the PMI-ACP recommended reading list in a common voice. The workbook is also different by providing lots of exercises and many situational questions like you will find in the exam.

So, while my PMI-ACP Exam Prep book covers all the background and theory – ideal for a comprehensive coverage of everything in the exam, the new PMI-ACP Workbook is a practical, hands-on study tool that focusses on the core topics needed to pass the exam. If you already have your CSM credential or 3+ years of agile experience you likely know the agile mindset, values and principles material already. However, you may not have the lean, kanban, and team development knowledge needed to pass the PMI-ACP exam so the workbook can fill those gaps.

To help determine which book is best for you I created the following flowchart:

Hands-on learners and people who do not want to read all about how the approaches fit together will find the 50 key topics of the new workbook a simpler way to navigate the material. Also, since the content is arranged by topic alphabetically you can easily jump around and create your own study plan based on just the topics you need.

While the workbook coverage of topics is less than the prep-book, the emphasis on exercises and situational questions is much higher and accounts for the slightly higher page count (457 pages). There is white space for writing notes and the whole thing is spiral bound so it lays flat when you are working in it. The content changes are summarized by these rough page count graphs:

I think it fills an important need. A workbook for hands-on learners looking to build their own study plan and gain access to high-quality situational questions. It also provides access to a free online quiz. Readers can order and get an early-bird discount from RMC here.

 

 

This article aims to dispel the myth that agile projects somehow magical manage risks for us, and outlines a couple of practical tools that can be used to start improving risk management approaches. 

Agile is Not a Risk Management Approach

Some people believe agile approaches with their short cycles and regular feedback have a risk management approach naturally built into the process. It is easy to see why, the building blocks and attachment points for plugging in an effective risk management process are certainly present, but unfortunately just building something iteratively or incrementally does not ensure risks are managed. 

It is all too easy to develop iteratively missing opportunities to actively address threats or exploit opportunities. Many agile teams also fail to actively look for risks, discuss and decide on appropriate actions, undertake those actions and reassess the risks and evaluate if the risk management process is even working. 

It is a shame because in many ways agile methods provide an ideal framework for introducing effective risk management practices. They have short timeframes, active reprioritization of work, frequent review points, high team member and business engagement in planning, etc. However, similar to having a group of people to help you find something, “a beach-party is not the same as a search-party”. We need a conscious effort, coordination and cooperation to make it effective.

 

Consciously Adding Risk Management to Agile Approaches

The good news is, that when organizations and their participating teams decide to layer risk management onto agile approaches there are many self-reinforcing cycles and mechanisms to make use of. For instance, the frequent consideration of change requests and reprioritization of work in the backlog makes the insertion risk avoidance or risk mitigation tasks an easier process to handle. 

Likewise, the regular retrospectives that review progress and process are great points to examine the effectiveness of risk management strategies and take corrective actions. Daily standup meetings that surface issues and blockers can also act as early warnings for potential new risks, etc. 

For anyone interested in linking agile approaches to risk management steps, here’s a White Paper on Collaborative Games for Risk Management that was presented at the 2012 Agile conference and PMI Global Congress. These ideas and their development more into Opportunity Management were explored at this 2015 Agile Conference Session. However, the mechanics of doing the work and linking it into an agile lifecycle are the easy parts, getting people to take a risk-based view to project work is where the real work is needed.

 

Thinking about Risk Management

Education and acceptance are the keys to successfully adding risk management to agile practices. We need to get people engaged in the process and instill a common understanding of threats as the possibility of negative value. Once people understand this they can answer the question “Where is the next best dollar spent?” more effectively. It might not be on building the next feature from the backlog, but instead avoiding a risk or exploiting an opportunity. 

Disclaimer: This article is based on my personal experience of software project development work over a 25 year period running a mixture of local projects, outsourced projects and hybrid models. The data is my own and subjective, but supported by 1,000’s of industry peers I question while delivering training courses for the PMI. I do not work for a local based or outsourcing based company, I have nothing to gain from favoring either approach, but I hope these thoughts are useful for determining some of the pro’s, con’s, true costs and circumstances when outsourcing is better or worse than local development.

To the uninitiated, outsourcing seems like a great idea. Software engineers are expensive in many countries but much cheaper in other parts of the world. So, since software requirements and completed software can be shipped free of charge via email and web sites, why not get it developed where labor rates are much lower?

Coding vs Collaboration Costs

The flaw in this plan comes in the execution of it when it becomes apparent that software development projects typically entail more than just the development of software. Writing code is certainly part of it, but understanding the problem, agreeing on a design, discovering and solving unforeseen issues, making smart decisions and compromises to optimize value and schedule are big parts of it too. This is the collaboration effort part of a project. Also, while the coding part might represent 30-50% of the overall project costs, these shrink to 20-30% when a 3-year ownership cost view is considered that includes support, maintenance and enhancements.

Sticking with just development costs for now, let’s examine a scenario. The business case pitched to executives by outsourcing companies initially seems very compelling: Project Alpha needs 9 months of software development by a team of 5 people. If you work in an expensive labor market, like North America, we can assume fully-loaded hourly rates of $100 per hour, yet highly qualified consultants from our fictional outsourcing country of TechLand cost only $25 per hour. So, the project for 9 months x 160 hours per month x 5 people at $100 per hour in an expensive market costs $720,000. For a TechLand team this would cost 9mths x 160hrs x 5pl x $25hr = $180,000, that’s a cool $540,00 saving, right?

Let’s revisit this scenario based on the acknowledgment that the actual software writing part of a project is closer to a 30-50% of the total effort. This leaves the remaining 50-70% of the work as the communications heavy collaboration part. It should come as no surprise that separating people via distance, time zones, and potentially language and cultural barriers increase communications effort and propagates issues up the cost-of-change-curve. 

So, when 50-70% of the communication-heavy collaboration work takes longer, how do we quantify that? Agile methods recommend Face-to-Face communications because it is the quickest, conveys body-language and provides an opportunity for immediate Q&A only for the issues that need it. Switching from Face-to-Face to video, conference call, email or paper create barriers and adds significant time and opportunity for confusion. A 2-3 X increase in effort likely downplays the true impact when considering the costs of fixing things that go awry because of inevitable misunderstandings, but let’s use that number.

Redoing our project Alpha costs with, say, 40% as the actual coding effort and 60% effort communications heavy collaboration work that takes 2.5 X as much effort we get: 9mths x 160hrs x 5pl x $25 hr x 40% = $72K Coding + 9mths x 160hrs x 5pl x $25 hr x 60% x 2.5 = $270K Collaboration giving $342,000 in total. However, this is less than half the costs of the $720,000 locally developed project so we are still good, right?

The Compounding Costs of Delay

An error in the logic applied so far is that this 2.5 X communication and collaboration penalty on 60% of the work can somehow be magically absorbed into the same 9 month timeline. In reality these outsourced projects take longer because of the increased communication and collaboration effort and 2.5 x 60% = 1.5 X as long is consistent with my experience from 25 years of mixed local and outsourced projects.

I am testing demand for another Calgary based PMI-ACP Exam Prep course. Please let me know via email to Mike <at> LeadingAnswers.com if you are interested in attending a 3-day Calgary based PMI-ACP Exam preparation course. 

 

Evolution of the PMI-ACP Credential

I ran a couple of Calgary based PMI-ACP courses three years ago when the exam first came out. Since then the certification has grown in popularity from niche to mainstream with over 10,000 people now holding the credential. This makes it the most popular experience based agile certification and the credential of choice for hiring managers looking for the rigor of a ISO 17024 backed PMI credential. 

In October 2015 the PMI rolled out the updated version of the PMI-ACP exam, based on feedback from hundreds of existing credential holders and agile practitioners. The new Exam Content Outline has been restructured with the addition of a new domain “Agile Principles and Mindset” to focus on thinking and acting in an agile way as opposed to simply implementing agile processes and hoping for improved results.

 

My Involvement in the PMI-ACP Credential

I was a founding member of the steering committee that designed and developed the exam content outline. We based the exam on what agile practitioners with a year or two’s experience should know to be effective. We wanted a methodology agnostic credential that captured the agile practices used on most projects most of the time. The exam covers Lean, Kanban and agile methods such as Scrum and XP. 

I worked with RMC to write their best-selling PMI-ACP Exam Preparation book. I recently updated this book to restructure it to the new Exam Content Outline. The book is currently available for 30% off from RMC here and is also included in the course.

 

Details about the Course

The course will be capped to 15 people for better Q&A and will take place at historic Fort Calgary which is close to downtown on 9^th Avenue and has free parking. It includes the second edition of my book, colour printed workbook, sample exam questions, and USB stick of additional materials. 

The course has a 100% pass rate and uses Turning Technologies audience response technology. Following the course each participant receives a personalized follow-up study plan based on their sample question performances. For more details see the Course Outline.  To express an interest and get pricing information please contact Mike <at> @LeadingAnswers.com.

Psst, this is your conscious, I am here to remind you about something you have thought about, but then hid away in the back of your mind. Lots of this agile stuff is hypocritical, it preaches evolution and change, but then we ask the same old three questions at standup every day. Also, why must we have standup every day, isn’t that kind of prescriptive? Agile methods are supposed to facilitate innovation through iterative development followed by inspection and adaption. They practice the scientific method of measurement and feedback on products and team work; so why are the agile practices themselves magically exempt from this precious evolution?

I believe there are two main reasons; first off, it is to protect inexperienced agile practitioners from themselves. With a free rein to morph product and process there is a strong likelihood that by six months into a project the practices followed by the team would have deviated from the proven and tested methods of most successful teams. The risk of failure would increase and every project in a company would be using a radically different approach making integration, scaling and team member transfers a major problem.

The other reason is a little more sinister. Most of the creators, proponents and promotors of agile methods have interests in keeping the methods pure vanilla. This is so they can create training courses, certifications and web sites for them. While scrum, as one example, has its specialized ceremony names and products you can neatly market services for it. If you allow or encourage people to change it then the result is not so proprietary and more difficult to defend, promote and assert ownership over.

I am not suggesting we should be changing agile methods willy-nilly, I think a basic suggestion to try them out-of-the-box for a couple of years is sound advice. However, beyond that I believe there are great opportunities for growth and deviation outside the standard agile models for stable teams who want to evolve further. This article tells the story of one team that did just that and what other people can learn from it.

This month’s theme at ProjectManagement.com is “Strategy Alignment/IT Strategy.” This can seem at odds for agile teams who organically grow solutions towards evolving requirements. Where’s the strategy in that, and how do we promote empowered teams while preventing chaos? Most organizations spend considerable time and effort developing strategic roadmaps and they don’t want this work undermined by unordered development.

Fortunately, hope is at hand with some well proven models. While the common kernel of agile practices make little mention of strategy or architecture, many of the supporting guides and scaling approaches handle the topic well. So, when faced with a criticism of no place for IT strategy or struggling to link an existing strategy to an autonomous team we can turn to these agile “wrappers” for inspiration and guidance.

You do not have to be using these approaches as standards at your organization to make use of the integration points and approaches they recommend. Instead see how strategy and architecture are handled and then apply a similar approach in your project and organization.

DSDM

Dynamic Systems Development Method (DSDM) is an agile approach that started in Europe and covers a broader project lifecycle timeline than most agile methods. It starts early with Feasibility and Business Study phases goes beyond deployment to handle Post Project work. Unlike most agile methods that don’t mention architecture DSDM has an architectural deliverable called the System Architecture Definition (SAD) that is created early on in the Business Study phase.

Agile projects struggling to appease architecture groups and facing criticisms of lacking strategic alignment, could look to the DSDM System Architecture Definition as a template for an early project, light-weight solution. DSDM also fits well with The Open Group Architecture Framework (TOGAF) standard and there is a White Paper on DSDM and TOGAF Integration White Paper here.

SAFe

The Scaled Agile Framework (SAFe) is a knowledge base for implementing agile practices at enterprise scale. It presents this information through a Big Picture View that shows how the work of agile project teams can be rolled up into programs with their own program backlogs. Then explains how programs fit into larger portfolios that implement product investment and strategic themes.

Knowledge transfer and sharing on agile teams differs from traditional approaches in both form and the internal vs external focus. Agile teams produce few of the traditional knowledge transfer documents yet their daily practices focus on knowledge transfer. While agile teams spend much of their time transferring information internally they share little with external groups other than the evolving product or service they create. These differences lead to some polarizing views of knowledge sharing and transfer on agile projects.

Some people see agile projects as knowledge transfer deserts where information is hoarded by key individuals and no useful documentation produced. Others believe agile projects are all about knowledge transfer.  So why the disagreement, how can smart, experienced people have such different views about the same topic? It comes down to what we consider knowledge transfer and sharing to be.

A requirements specification document should be a great vehicle for sharing knowledge and transferring it from analysts to developers. It is a permanent record of requirements that can be read by many people and referred back to when needed. If questions or the need for clarifications arise – go look in the requirements specification. This works well for stable, unchanging requirements that can be gathered comprehensively up front.

Baselined plans are great knowledge sharing tools too. They lay out what should happen, when and by whom and paint a clear picture for all to see. Plans illuminate the path forward and communicate this to all involved stakeholders. Lessons Learned documents gathered at the end of a project are classic knowledge transfer and sharing tools also. Recording what went well, what did not go well and recommendations for similar projects to follow seems the epitome of knowledge transfer.

Agile projects down play the value of upfront plans, avoid detailed requirement specifications declaring them unreliable and wasteful. They often spurn Lessons Learned documents too, instead performing retrospectives amongst themselves. It is no wonder then, that to some people agile projects appear to lack the basics of knowledge sharing and transfer. However these people are measuring with the wrong yardstick, or fishing with the wrong size net and missing the knowledge rich plankton that feeds agile teams. When you “see the matrix” of agile projects you immediately realize the whole process is about knowledge transfer.

My presentation outline “Eat Risks for Breakfast, Poop Awesomeness All Day!” was accepted for the Agile 2015 Conference in Washington D.C., August 3-7. As much of the agile community seems engaged in scaling debates I am really happy to share some useful tools that can be used on any project, regardless of approach.

The learning objectives for the session are:

• See why project managers are the least equipped to effectively identify and manage project risks.
• Learn engaging ways to educate team members about risk management including identifying threats to avoid and opportunities to exploit
• Preview 5 collaborative games for effective threat and opportunity management from planning and identification, through management, to reporting and closure
• Understand the untapped potential of an increased emphasis on opportunity management
• Review case studies of projects teams that have been using these practices for three years and are achieving measurably better results than teams that do not

Today we take a look at how the number of PMI Credential holders has grown over the last 10 years and speculate where they might go in the future. While 10 years is a good period to look back over, the PMI’s PMP ®(Project Management Professional) credential dates back much further, to 1984, making it 31 years old this year.

Growth of the PMP was slow in the 1980’s partly due to the different communication methods being used then. The Internet did not start becoming popular until the 1990’s, so information about the PMP certification was shared mainly through periodic journals and newsletters. Another factor was the self reinforcing nature of credentials. When credentials are new few people outside of the originators have heard of them so there is little external incentive to get one. Slowly, people wanting to demonstrate their skills and/or distinguish themselves from their peers obtain the credential. Then, once it reaches a critical mass, hiring managers start asking for it so more people are motivated to obtain it and growth increases rapidly.

By the mid 1990’s the PMP credential was picking up steam and by 2004, our 10 year look back starting point, the PMP had over 100,000 holders. By the end of 2014 this has grown to nearly 640,000 certificants and is by far the most popular credential offered by the PMI. 

During the last 10 years a number of new credentials have been launched to provide opportunities for both specialization (like the scheduling and risk credentials) and diversification (such as agile and business analysis credentials). The first credential after the PMP was the CAPM (Certified Associate in Project Management) introduced in 2004 that serves as a potential stepping-stone to the PMP and is targeted for people who have worked on and around projects, but do not have experience leading and directing  projects.

Since then there have been several more credentials launched that we will discuss in more detail later, but for now we can see from the stacked areas graph below in Figure 1 that the PMP and CAPM make up the majority (98%) of all PMI Credential holders.

I have submitted a presentation for Agile 2015 Conference about team based risk and opportunity management that may well get rejected based on its title alone!

It has always been a good practice to engage team members in the estimation process; then agile methods taught us how teams should do the local planning and decision making too. So it should come as no surprise that the best people to undertake effective risk management are team members. They possess the best technical insight and are closer to any execution issues than team leads or project managers.                                               

However, risk management as tackled by many organizations, is academic, boring, seemingly removed from real-work and it often ignores the maximization of positive risks (opportunities). My proposed workshop demonstrates how to turn teams into risk-consuming, opportunity-chasing beasts that that leave a trail of business value and delighted stakeholders.

 

At the Agile 2012 Conference I presented a session called “Collaborative Games for Agile Risk Management” that introduced fun, team based games to engage the team in risk and opportunity management. In the intervening years many teams have adopted these techniques and become much more effective at Risk Management. However it turns out I was focusing on the wrong end of the lever, the big news are the results teams are getting through Opportunity Management.

Teams using these approaches are not only driving out risks, but more surprisingly, building great inter-organization alliances, being given free passes on bureaucratic process and generally having an easier go of things. At first I was surprised at all the “good luck” these teams encountered but then I saw how small adjustments in team behaviour were being made towards freshly identified opportunities.

A little like the 18^th Century discovery linking germs to infections that gave rise to the introduction of hand washing in hospitals increasing survival rate dramatically. Putting teams in charge of opportunity management leads to changes in day to day behaviour that dramatically increased the execution effectiveness and success rates of their projects. 

Good leaders know the value of a powerful vision; it “Reveals a beckoning summit for others to chart their own course”. In other words once we know what our true goal is we can make our own micro adjustments. Getting teams to own opportunity exploitation causes them to behave differently and benefits start occurring all over the project.

My session proposal outlines the practices and reviews case studies so you can equip your team to be risk-consuming, opportunity-chasing beasts that leave a trail of business value and delighted stakeholders. However if the mental image of eating risks for breakfast and pooping awesomeness all day is too graphic to share in your organization, maybe a machine that harvests risks and opportunities and outputs business value is an easier sell, but not as much fun.

Related articles

"Solving Today's Complex Projects with Agility" Presentation

This article is less about agile techniques and more about the people related challenges of today’s agile projects. As work switches from industrial work to knowledge work, companies face a perfect storm of employee engagement and retention issues. On the one hand the time taken to learn a job is increasing as domains become more complex and new tools add layers of abstraction and integration problems. On the other hand the average time spent in a job is decreasing. Frequent job changes are now the norm and long term workers are a rarity. Two years is the new five years average tenure and six months is the new two years of young worker average placement. It may seem just as people become productive they leave and the training process has to repeat.

An additional problem is that it is often the best people who move on, since they are sought after by more organizations and there is now less stigma with short work assignments. Companies not paying attention to their workforce or offering appealing work environments find themselves subject to an involuntary Sedimentation-Effect as the best float to the top and depart leaving less capable people behind. The process has been accelerated by social media and online job sites that make finding good places to work and connecting strong candidates to great companies easier than ever.

Things are not going to get better any time soon either, as Baby Boomers and Gen X workers leave the workforce Generation Y and Millennial workers are entering the market place in increasing numbers and with new expectations. Paul Harvey, a University of New Hampshire professor says that Gen Y and Millennial workers “…have unrealistic expectations and a strong resistance toward accepting negative feedback" and "an inflated view of oneself." 

It is not all doom and gloom though; fortunately agile projects provide ample opportunities for tuning the workplace for better motivation and retention. Bill Pelster, principal of Deloitte Consulting, suggests that “Organizations need to understand that the world of work is changing. What millennials want — innovation, opportunities to grow and develop, mentors — aren’t overly demanding. They’re what every organization needs to succeed. All generations generally want what the millennials want, but what is different is the priority placed by millennials on development and core values versus, for example, a safe and secure job. Millennials are more inclined to take risks and change jobs much more quickly than other generations.”

In fact there are a number of things companies and managers can do to attract and retain the best talent.

Leaders, not managers - Forget trying to manage people, that’s too command-and-control and reactionary to cope with today’s speed of business changes, nor is it engaging. Today’s teams want leading. This involves communicating a vision of the desired end state, clearing the path of obstacles or bureaucracy, and providing mentorship with support.

There is a useful paradox that helps remind us of the leader role “We lead people by standing behind them” i.e. we back them up, provide support, encouragement, training and mentorship. Let them take any praise or glory and be a close, but in the background, supporting player.

Problems, not tasks – humans are hard wired to get a buzz from problem solving, that’s why many people play video games and do Sudoku puzzles in their spare time. Tap into this motivator and present the project’s goals as problems, don’t try to manage them away into tasks. Let the team see all the complexity then ask or challenge them to solve the project problems.

Engaged, self-organizing teams are incredibly resourceful and creative. The traditional model has solutions being designed by a small group of specialists and then selling the selected approach to the team for implementation. Agile leaders instead invert the model and engage the team in solutioning and have them “sell” their approach back to the project managers and business champions for approval.

This higher level of engagement builds a much stronger commitment to deliver and remove obstacles encountered along the way. It also taps into people’s reward mechanism of problem solving and helps build everyone’s sense of achievement rather than drudgery. Obviously some work will always be dull and we just have to grind it out, but that should be the exception not the norm.

Say “Yes” to time off requests – “kids school play”, “camping trip”, “whatever”,  if someone has enough of a reason to not want to be at work, especially contract staff who do not get paid when taking time off, why make them feel bad about asking or turn them down? The good-will and appreciation for having a flexible working environment ranks high among high achievers. Most people recognize when they have good working conditions and the small cost of reduced capacity is more than made up for by the benefits of retaining the best workers, reduced recruiting and training, etc.

Obviously if anyone abuses this goodwill guide and finds reasons not to work on a regular basis then there needs to be a separate discussion. Failing that I have only seen upsides from providing a very flexible work environment.

Leverage improv comedy’s “Yes, and…” – Responding to someone’s plan or suggestion with reasons why that won’t work here, or the famous “OK, but what about …” is demoralizing. “OK, but“ is often a thinly disguised “No” and after a series of these, people just stop suggesting ideas, shortly followed by stopping caring.  The first rule of improve comedy is build on ideas, not shut them down; it is the same with team work and co-creation in the work place.

So, if someone suggests an open house to demo the new system to customers, we can reply “Yes, and if we do a dry run with our business group first, we can iron out any kinks”. “Yes, and” promotes ideas and involvement rather than stifling them. We can always edit and improve plans later, but if the best suggestions never get made for fear of ridicule, no refinement can ever wish them into being.

Since collaboration and teamwork are so critical on knowledge worker projects, many forward thinking companies are looking to Improv training to help their employees. See these Forbes and FastCompany articles for more information.

Keep perspective and stay calm - remember our project issues are definitely first-world problems, a broken promise, buggy release, missed demo, or poor estimate are not worth getting truly upset about. Save the drama for where it is warranted, work compassionately and objectively.

Create projects, not roles – drawing from Deloitte’s Bill Pelster again: “It is important that organizations realize that millennials are looking to constantly gain new experiences and push their development. This means that organizations need to think through the velocity of developmental opportunities and the potential need to “re-recruit” millennials on a regular basis. Failure to do this will potentially lead to higher than expected turnover and more pressure on your recruiting organization to constantly source and on-board new talent.”

We can frequently re-recruit staff through exposing them to new projects with new problems to solve. Align people with key projects and mentors so that they are challenged and have an accelerated growth experience. This is good for the organization and their employees.

HippySh*t or Solid Sense?

To some people these recommendations may seem like indulgent panderings to a soppy workforce of over-entitled layabouts. They may seem to be overly generous, but the world is so connected now it is easier than ever for the best people to find good work. If your company undertakes industrial work involving the repetition of established process, you likely do not need the best and most talent workforce; instead reliable and cost effective staff are the way to go.

However if you are in the knowledge work space of solving novel problems then attracting and retaining the best staff you can is not a company differentiator, but the minimum required to stay in business. The suggestions outlined above, and others besides, do not replace standard work. Instead they get woven into our normal behaviour for leading teams, hopefully to effect subtle shifts towards a more desirable work place that retains the best talent and attracts more of the same.

The economics of compassion and empowerment might not sit easily with everyone from my generation. Like many people, I worked in junior, menial roles for decades before being given any opportunity to influence. But as the saying goes “If you don’t like change, you’re going to like irrelevance even less”. So, the question becomes what can we learn to stay up with the wave of change if we want to succeed?

Do any of these traditional PMO scenarios match your agile team experiences? Your traditional PMO is so laughably outdated that most agile projects ignoring them; other projects produce token deliverables to appease them, but these bear little resemblance to anything actually happening on the agile projects.

The PMO looks for conformance to BDUF (big design up front) methodologies with signoffs to premature speculations about requirements and scope definitions. It reports progress on traditional projects such as being 75% through Requirements Gathering or 50% through Analysis and Design as if these non-value delivering activities are actual progress. Finally, when projects have issues the PMO responds by creating more review and approval groups to ensure competence and adds gates and sign-offs to try and improve quality.

If these scenarios sound familiar to you I would like to ask a follow-on question: How is your agile roll out going? Is the PMO the last bastion of opposition or are you fighting pockets of resistance and misunderstanding throughout you organization? Is the once “no-brainer” decision to switch to agile actually causing some headaches and frustration? If you answered yes to this too, you are not alone.

It turns out the PMO is not usually the problem, but they are a good litmus or canary-in-the-coal-mine for how an agile transformation is going. The PMO’s focus is project execution process, so if you cannot convince this group that agile is the way to go, then how do you plan to convince groups who don’t care about process at all? How about the BA Center of Excellence or the Architecture group, have they fully bought in to your agile approach or are they requesting more formal practices?

Getting the PMO onboard is helpful in convincing these other, more problematic groups that agile methods can be a better way of working. So how do we do that? Well making agile more accessible is a good start. PMO’s often shy away from agile methods since the short iterations and repeating cycles of work do not offer the familiar phases and gates they are used to. In fact interacting with agile team iterations seems as appealing as putting your arm in a spinning concrete mixer.

However we can make the process less daunting by showing how the user story and backlog process works. Take some required deliverable, like a handover document, and create a story for it. Give it to the team and along with a customer proxy (a Product Owner for instance) the story will get prioritized and placed in the backlog. Since it is required for Go Live the story will get selected and worked on by the team prior to the release date – all with PMO limbs intact.

 

Another point of confusion around agile methods for some PMO groups is the lack of a visible end point or meaningful progress reporting. They may wonder if iterations just repeat until the customer is happy rather than the specification is complete? Gaining visibility into the process can help by providing retrospective data to the PMO along with story points and feature metrics. By explaining the cadence of reviews and tracking metrics PMOs are assured progress is measurable and all the old favorites like Budget At Completion (BAC) and Schedule Performance Indexes (SPI) can still be obtained.

Helping the PMO helps agile adoption by creating another advocate group. It may be a surprise to some PMs and teams but PMO’s are under a lot of pressure to justify their existence and demonstrate their value add. They are usually very receptive to ways to stay current and support emerging practices.

Investing some time to train them in Product Owner training or Retrospective Facilitation pays dividends since now they can offer these new project services. Project teams will benefit from a more educated and aligned business community and gain impartial facilitators making it easier for all to contribute ideas at retrospectives.

Rather than unaligned PMOs representing an obstacle to agile teams, they really represent missed opportunities for further agile adoption and an indicator that the agile message might be miscommunicated to other stakeholder groups. Spending some time to address their concerns, explain the risk reduction goals of early feedback, and equip them with useful services will pay dividends and ease the larger adoption of agile and lean principles.

(I first published this artice at ProjectManagement.com here)

On May 5^th I will be presenting at the PMI-NAC Conference on the following topics:

1. 21^st Century Risk Management: Supporting mathematical analysis with social influence
2. PMO Evolution: Frameworks to Support a Mix of Traditional, Agile and Lean Project Approaches

I am looking forward to the event and will share thoughts and feedback on the sessions here afterwards. Until then here are the presentation outlines:

Presentation 1: ”21^st Century Risk Management: Supporting mathematical analysis with social influence”

Today’s complex projects need proactive risk management to stand any chance of executing successfully. Yet, all the steps of: identifying, classifying, analyzing and prioritizing are for nothing if the risks cannot be effectively avoided, transferred, or reduced. These risk avoidance and reduction steps are largely human led activities with success criteria closely linked to social influence.

While the project manager is key to project co-ordination and success, they are rarely the domain experts and instead bring subject matter experts (SMEs) together to collaborate on novel solutions. These knowledge worker projects require a whole team approach to not only risk finding, but also risk resolving.

This session explains the need for proactive risk management and the importance of social influence on risk management. Using case studies, a team approach to risk management to collaborative workshops, new risk visualization techniques, and examples of team risk avoidance and risk mitigation actions are examined.

Presentation 2: ”PMO Evolution: Frameworks to Support a Mix of Traditional, Agile and Lean Project Approaches”

Agile, lean and kanban approaches are a part of the new project delivery toolkit, especially for projects with IT components. The PMBOK Guide v5 published in January 2013 now describes a lifecycle spectrum spanning “Predictive, Iterative & Incremental and Adaptive” approaches. The new “Software Extension to the PMBOK Guide” expands this model with further agile related guidance for project execution.  Gartner Research claims 80% of today’s software projects employ agile methods. So, is your PMO living in denial, or simply living in the past?

Fortunately, a new class of PMO has evolved to support a dynamic mix of traditional, agile and lean project approaches that we can learn from. Using case studies from award winning PMOs, this presentation examines how proactive organizations are tracking diverse project types with common metrics and enablers.

I know it is Christmas time not Halloween, but think of it as holiday re-gifting. Here is an article on agile horrors I wrote for ProjectManagement.com Halloween Edition that we should be on the lookout for on our projects in 2014.

Frankenstein Process – This is the methodology designed by committee that tries to combine iterative, empowered development with linear scheduling and command-and-control task assignment. Perhaps created in an attempt to satisfy the desires of competing groups, but this half goose, half salmon abomination neither flies nor swims.

Agile practices are in a balanced network. Ruthless testing balances the need for comprehensive documentation; colocation, demos and daily stand ups reduce the need for detailed status reporting. Changes made to this web of practices can easily create risks, gaps and duplications if they are not carefully considered.

Think candy apples not pumpkin pie; hybrid methods work best when there is a core of agile for the team to own and execute, surrounded by a wrapper of more traditional process to buffer and integrate into a less agile aware environment. Don’t try and glom disparate process pieces together, it becomes a monster nobody loves or defends.

Zombie Projects – some projects should just die but won’t seem to. Doomed from the outset with unrealistic deadlines, overly ambitious scope, or ill equipped skills and support; everybody knows it will not end well, but nobody seems willing or able to kill it.

These death marches to eventual failure or cancelation are damaging to the people working on them who see the futility and mismatch of progress to targets. However, like the emperor’s new clothes there is a shared acceptance that this is unlikely to work, but nobody seems to speak out. Perhaps thinking that the “higher ups” must know what they are doing and would intervene if there are problems; they continue shuffling forward like an army of undead looking for brains.

Unfortunately, there are no brains here and the higher-ups rarely have some cunning plan that turns struggling forward progress into an elegant solution. More often if it looks, smells, and behaves like an undead zombie, it is one. Just like in the movies, it is best not to start shouting and bring attention to yourself if you are surrounded by zombies. Instead try to find an opportunity to exit quietly, see if there is a reset or restart initiative planned. Offer to be part of the solution, instead of bitching about the issues, usually others have reached the same conclusion and are looking for support to fix things.    

Vampire Scrum Masters and Project Managers – These people just suck the life out of things and never give back. Scrum Masters who look for process compliance but do not own or remove impediments; or project managers who push for velocity improvements, but don’t want to hear about quality improvements or refactoring plans.

Agile teams generally work very hard to deliver as many high quality features as they can. When they report problems or ask permission to undertake maintenance work it is so they can be better equipped to deliver high quality features long into the future. Like ignoring a Check-Engine light in your car or missing regular maintenance, you might save some money in the short term but it is a false economy longer term.

Scrum Masters and project managers need to learn enough about their teams and their technical domain to distinguish genuine reports of problems and requests for investment from everyday complaints and unnecessary requests for resume boosting technology upgrades.

Teams who routinely get their requests ignored by leads that just want results without investment will correctly draw the conclusion that they are not valued. When this occurs, the motivation to try hard, delight customers and go the extra mile to overcome an obstacle is removed. The delivery of results will decline and then the whole process sucks.

So, show some interest, ask people to explain why issues and requests are important. If all the solutions are not possible ask them to prioritize. Try as hard as you can to fulfill these requests and usually the teams will reciprocate with improved effort and results.

Product Owner Ghosts – these are business representatives that are kind of there, but not really, they tend to vanish or dissolve when pressed on anything. Whether it is a tough decision on a product feature, or their attendance at a demo; product owner ghosts are unreliable.

The product owner / business representative role is integral to agile processes. They are needed to ensure requirements are understood, refined and prioritized, along with providing prototype feedback and resolving design decisions. Like missing or getting a poor developer or QA person, a project with a “hardly there” product owner will suffer tremendously.

So, look out for signs of less than real product ownership. Warning signs of a non-committed or weak business involvement include:

C - Contrary – decisions flip-flop with no clear explanation

A - Absent – you cannot find them or get their time when needed

S - Switching – the person changes, no dedicated product owner is assigned

P - Passive – without prompting we would not hear from them for long periods

E - Elusive – they will not provide clear feedback on the suitability of a prototype

R - Reclusive – they withdraw from priority discussions and decisions

Instead try to staff projects with product owners who exhibit more solid, proactive business representations.

C – Collaborative – willing to discuss and evaluate alternative solutions

O – Owners – owning the backlog of work, taking reasonability for its grooming

N – Nearby – available when required to ask questions and get clarifications

C – Committed – having the same person or people throughout the project

R – Representative – representing the group we are building for, not personal goals

E – Expert – knowledgeable about the domain at hand to answer team questions

T – Traceable – contactable when needed or with a proxy available if away

E – Experienced – experienced in the field to warn of outliers and exceptions

(I prefer these attributes over Barry Boehm's CRACK mnemonic that does not emphasize the Nearby, Experienced and Expert qualities that can really save teams time.)

Getting the best users is always difficult since the best people are busy doing real work. Try to explain the costs and risks of building the wrong or a sub-optimal solution. Offer to back fill admin work from the project for the best people even just to free up some of their time each week for input and feedback.

Summary

Hopefully this light hearted view of some agile anti-patterns in the guise of Halloween ghouls reminds us of things to be on the lookout for. Unlike Halloween these problems are year round threats. More than just something that goes bump in the night, these problems are ever present in our lights-on projects. Look out for them and use your garlic and silver bullet awareness to keep them from impacting your projects.

 

I have had a busy autumn and it has been too long since I posted here. I did some consulting in Europe and attended the PMI Global Congress in New Orleans to present on “21^st Century Risk Management” with Dennis Stevens.

More recently our local PMI Chapter won the “Chapter of the Year” award and held their excellent Professional Development Conference that I gave a couple of presentations at. The first on “PMO Evolution: Frameworks for Integrating Lean, Agile and Traditional Projects” and one on “Surviving Agile Projects” aimed at traditional project managers transitioning to manage their first agile project.

The consulting and conference interactions led to a number of ideas for application on agile projects that I will be sharing here in upcoming posts. At our local PMI conference in Calgary last week Bob Lutz, Retired Vice Chairman of General Motors Corporation gave a great talk on design and project management.

He was discussing the importance of defined, repeatable process for efficient, high quality production. Strict compliance and rigorous process controls certainly help improve the manufacturing process. What was interesting was his cautions about applying defined, repeatable processes to design work. He said it flat out does not work and can lead to terrible products.

Bob recounted how upon rejoining General Motors in 2001 he asked “Who the hell designed the Pontiac Aztek?” (which appears on many Top 10 worst car design lists and is generally slammed from a design perspective – although liked by some loyal owners.) The Pontiac engineers were very defensive claiming that in fact the design of the Aztek was one of the best executed vehicle design projects that had run, hitting each of its targets and assessment milestones during the process. Lutz went on to say while some processes need rigour, design processes need collaboration, feedback and frequent verification to ensure we are on the right track.

As we execute our projects I think there is great value in determining if we are designing something or manufacturing something. The creation of software solutions is like car design, we are trying to understand the problem space and create candidate prototypes for evaluation and evolution towards the best available solution. This requires collaboration, feedback and frequent verification.

Other projects like upgrading servers and training 500 people are more defined, repeatable activities that can benefit from well defined process and strict controls. Most projects I have worked on have elements of both work types mixed together. An important skill for project managers is to know when to employ strict process and when to encourage less structured collaboration where designs evolve based on build-feedback cycles.

I really enjoyed Bob’s talk; he is an engaging speaker who tells things as he sees them and I look forward to reading his latest book “Icons and Idiots”. Over the coming weeks and months I intend to post here more frequently and continue the dialog on the smart application of process and pragmatism.

It may not always be apparent but the goals of the Project Management Office (PMO) and agile teams are well aligned. Both groups want to get to the same destination: namely successful projects and happy stakeholders. However, things often come adrift as soon as the best direction to travel in to get there is discussed. The PMO might expect lots of planning and some documentation to confirm everyone understands the approach. An agile project team might want to build some proof-of-concept models to test feasibility and get confirmation of understanding. So, very quickly the two groups can disengage and have difficulty generating alignment again.

This is one reason agile teams don’t always see the Project Management Office (PMO) as a source of assistance. All too often a traditional PMO can Present Multiple Obstacles, but it does not have to be that way.

First let’s examine what PMO’s are supposed to do. The old roles of: “Rules”, “Tools” & “Schools” goes some way to describing their functions, but a more complete set of offerings was provided in the 2010 PMI Project Management Journal article “Identifying Forces Driving PMO Changes”. These are:

1. Monitor and control project performance
2. Develop and implement standard methodologies, processes, and tools
3. Develop the competency of project personnel, with training and mentoring
4. Multiproject management, including program and portfolio management, coordination and allocation of resources between projects
5. Strategic management, including participation in strategic planning and benefits management
6. Organizational learning, including the management of lessons learned, audits, and monitoring of PMO performance
7. Management of customer interfaces
8. Recruit, select, and evaluate project managers
9. Execute specialized tasks for project managers (e.g. preparation of schedulers)

  For organizations using agile methods, these services can be delivered as follows:

1. Monitor and control project performance – Help teams track their velocity. Assist with tracking team and sponsor satisfaction ratings. Look out for and alert teams of dangerous velocity trends, check backlog size, and offer reviews of iteration and release plans.

2. Develop and implement standards – Provide templates for user stories, test cases, cumulative flow diagrams, etc. Provide agile PM tools, educate supporting groups on iterative development concepts.

3. Develop personnel with training and mentoring – Provide agile training courses, coaches, and mentors to help project mangers transition to agile projects and upgrade their skills. Send people to local agile events.

4. Multiproject management – Coordinate between agile teams, communicate between projects including items such as outlining progress, issues and retrospective findings. Help manage Release Trains at the program level and Investment Themes at the portfolio level using frameworks like the Scaled Agile Framework (SAFe).

5. Strategic management – Identify projects with opportunities for early ROI or competitive advantage.

6. Facilitate organizational learning – Gather project velocity profiles, capture, store and index retrospective findings. Include perceived PMO cost vs. value in project metrics.

7. Manage Stakeholders – Provide Product Owner training, guidance on acceptance testing and how to evaluate and give feedback on systems. Champion the importance of Subject Matter Experts (SMEs) to projects.

8. Recruit, select, and evaluate project managers – Develop guidelines for interviewing agile project managers.

9. Execute specialized tasks for project managers – train and provide retrospective facilitators, create agreements with agile project trouble shooters, provide mentors and coaches.

Understanding the role of a PMO and translating the goals into an agile setting helps create alignment rather than conflict between the groups. These items may sound a tall order for your average old-school PMO. However PMO’s are under pressure to remain current and demonstrate their value in a climate of fast moving projects, cost cutting and increased scrutiny.

In the September 2009 PMI Community Post magazine Jack Duggal published an article called “Teaching PMOs to DANCE” that dealt with the issue that many of today’s projects are moving quicker than PMO’s can respond. Many PMO’s struggle assisting projects that DANCE:

Dynamic and changing

Ambiguous and uncertain

Non-linear and unpredictable

Complex

Emergent nature of projects that causes instability

The agile community calls projects like these “a good fit for agile” and this is the synergy. When we can explain agile approaches are not just non-conformist, ill-planned projects, but instead a proven approach for these tricky new project types then a win-win is possible for both camps.

Jack Duggal also gave a presentation at the 2011 PMI Global Congress entitled “Reinventing the PMO” which was quite agile manifesto like. Jack outlined a need for PMO’s to shift:

1. From Delivery of Projects to Benefits Realization and Business Value
No longer is delivery of on-time, on-budget projects considered successful. It is necessary but not enough. PMOs need to cultivate a mindset to shift to a benefits and outcomes focus and establish measures to ensure benefits realization and achievement of business value.

2. From Delivery to Adoption and Usability
Typically, PMOs are focused on improving execution capabilities. Projects are implemented well, but often the outputs and deliverables are not used or adopted. With a shift to an adoption and usability mindset, PMOs can promote and plan for adoption throughout the project lifecycle to ensure intended realization of projects’ benefits and value.

3. From Diffused and Disjointed Focus to Holistic and Balanced Adaptive Approach
Often PMOs are pulled to address the current pain or fix the problem of the day. This results in a diffused and disjointed PMO focus and limits the ability of the PMO to provide a balanced approach.

4. From Change Management to Change Leadership
Change management in the PMO realm has focused on configuration management and procedural changes. Evolving PMOs understand the need for organizational and behavioural change and get involved in change-readiness assessments and preparation. PMOs can play a key role in understanding, leveraging and leading change.

The “Next Generation PMO” as Duggal names it will have a mindset viewing the organization as a complex adaptive system. The PMO’s purpose becomes more focused on linking tactical & strategic help with business value. Success will be measured via benefits realization and business value rather than project delivery. All of which are very much aligned with agile concepts.

So, rather than PMO’s being unsupportive of agile, I have found most to be very co-operative when alignment with agile helps them address challenging projects, deliver value and stay current. Also as project managers experienced in agile take roles in the PMO I think this transition will accelerate. With some education and buy-in a good PMO can Provide Many Opportunities for agile teams.

(This article first appeared at projectManagement.com here)

My next PMI-ACP Exam Preparation course will be November 18, 19, 20 in Calgary, Alberta. The course will be capped to 15 people for better Q&A and will take place at historic Fort Calgary which is close to downtown on 9^th Avenue and has free parking.

Since I am offering the class in my home town I have no travel costs and can offer the course for a discounted price of $1,290 for 3 days including lunches and snacks, my book, color printed workbook, sample exam questions, and USB stick of additional materials. (You can deduct another $60 if you already have a copy of my PMI-ACP Prep book).

The course has a 100% pass rate and uses Turning Technologies audience response technology. Following the course each participant receives a personalized follow-up study plan based on their sample question performances. For more details see the Course Outline.  To reserve your place or ask questions please contact [email protected].

Apologies for the slow rate of articles here at LeadingAnswers.com recently, but I moved to Canada to enjoy the outdoors and it is prime hiking and biking season. Normal posting frequency (which is still not that frequent) will return after our all too short summer.

Meanwhile I will repost some articles I wrote for ProjectManagement.com to fill the void. First a couple of pictures from last weekend’s 24 Hours of Adrenaline bike race in Canmore.

I will be presenting a paper at the PMI Global Congress in New Orleans, October 27-29. Entitled “21^st Century Risk Management: Supporting Mathematical Analysis with Social Influence” it is about bringing the local influence of people and persuasion to the analytical world of risk management.

All too often risk management is treated as a dispassionate science of probabilities. However projects are people oriented with risks (and opportunities in particular) being greatly influenced by behaviour. Experiments made in moving risks and opportunities from the methodical risk analysts and project managers to social “project charmers” have shown great results in risk reduction and opportunity exploitation. This partnership between math and social influence seems to be a winning combination and the presentation explains some case studies where this has been applied with great success.

I hope to be presenting the session with Dennis Stevens who shares many of my views on agile risk management. I have worked with Dennis on a number of initiatives including the PMI-ACP certification and the Software Extension to the PMBOK Guide. I enjoy Dennis’ sense of humor and depth of knowledge. I am really looking forward to the event.

Shown below is the outline description for the paper:

21^st Century Risk Management: Supporting Mathematical Analysis with Social Influence

Today’s complex projects need proactive risk management to stand any chance of executing successfully. Yet, all the steps of: identifying, classifying, analyzing and prioritizing in the world are for nothing if the risks cannot be effectively avoided, transferred, or reduced. These risk avoidance and reduction steps are largely human led activities with success criteria closely linked to social influence, communications and campaigning. 

While the project manager is critical to project co-ordination and success, they are rarely the domain experts on modern projects and instead bring subject matter experts (SMEs) together to collaborate on novel solutions. These knowledge worker projects require a whole team approach to not only risk finding, but also risk resolving.

This session explains the need for proactive risk management through an examination of the “Flaw of Averages”, it walks through the risk management process examining traditional and lean/agile based processes. Then the importance of social influence in risk mitigation is explored. Using case studies, a shared team approach to risk management is described. Through collaborative games, new risk visualization techniques, and empowered teams, examples of risk avoidance and risk mitigation actions are examined.

21^st Century risk management should be a whole team activity facilitated by the project manger or risk analyst. Not only is relying on a single person to identify and analyze risks and opportunities inadequate, it also represents an unacceptable risk of its own.  Also, often there is a mismatch in personalities between the people best able to analyze risks and those best able to influence them. A new framework that leverages people’s strengths while optimizing the whole value stream is presented. 

My PMI-ACP Exam Preparation course will be April 15, 16, 17 in Calgary, Alberta. The course will be capped to 15 people for better Q&A and will take place at Fort Calgary which is close to downtown on 9^th Avenue and has free parking.

Since I am offering the class in my home town I have no travel costs and can offer the course for a discounted price of $1,290 for 3 days including lunches and snacks, my book, color printed workbook, sample exam questions, and USB stick of additional materials. (You can deduct another $60 if you already have a copy of my PMI-ACP Prep book). To reserve your place or questions please contact [email protected].

Continue reading to see further details from the Course Outline

The Project Zone Congress will be taking place in Frankfurt, March 18-19. I attended the Project Zone Congress last year and was impressed by the quality of sessions and access to speakers for Q & A. This year’s conference is set to repeat the format and has some great speakers including Jurgen Appelo author of “Management 3.0: Leading Agile Developers, Developing Agile Leaders”. I love this title and wish I’d come up with it myself!

Readers of LeadingAnswers can receive a 10% discount from the conference by using the code “PZ2012_MEDIA03B869C8” when they register. It promises to be a high caliber conference with sessions on practical agile, the PMO and agile, strategy and leadership, see the schedule for full details.

To many people, agile is the opposite of sound theory. Instead of proceeding in a structured, well-planned manner, teams “self organize” and iterate through prototypes to try and create something. Ants can self organize and create transportation systems and large, complex community structures. Yet when people self-organize, we tend to get slum ghettos with no sanitation. Which outcome do your projects most resemble?

Planning is a slow, boring, unpopular exercise that attributes accountability to the planning group; if something goes wrong, we know who to blame. If everyone has a go at creating something and it does not turn out, then the blame is harder to pin on someone; excuses can be made around the project being complex and requirements not clearly articulated, etc.

So, is it laziness and dodging accountability that drives the huge growth of agile approaches, or is there something else to it? The Standish Group, which studies software project failure and success rates, recently reported:

“The agile process is the universal remedy for software development project failure. Software applications developed through the agile process have three times the success rate of the traditional waterfall method and a much lower percentage of time and cost overruns.”[1]

They sound pretty impressed, so what’s behind it? It turns out there’s plenty, but in the human resources domain, not the project execution domain. Projects are undertaken by people for people; they involve getting people to work together on things, collaborate, create consensus and sometimes compromise. As such, it is only right that the real key to project success should come from “people science” rather than “scheduling science”. Don’t get me wrong: work breakdown structures, Gantt charts and network diagrams have their place, but they are not the right place to start your journey for successful projects.

As a PM, what is the most effective thing you can do for your project in the next hour? (After finishing this article, of course!) I would suggest speaking to your project team members and business representatives about where their concerns lie and what they believe the biggest risks for the project are. The reason being that while tarting up a WBS or re-leveling a project plan might be familiar and comfortable (where you are a master of your own domain), it really amounts to nothing if your project is heading for trouble. Like rearranging deck chairs when you should be looking for icebergs, there are better uses of your time.

The frequency and magnitude of IT project failures are so prevalent and epic that people can appear in denial of their ability to influence, or “in acceptance” that a certain percentage of projects just go south. Does it need to be that way? If we spent more time asking people where stuff could go wrong rather than making ever more polished models of flawed project plans, could we change the statistics (even a little bit)?

According to research by Roger Sessions of ObjectWatch, 66 percent of projects are classified as “at risk” of failure or severe shortcomings. Of these 66 percent, between 50 and 80 percent of these projects will fail. So, if 66 percent of projects are at risk, let’s say 65 percent of these projects will fail; that’s .66 x .66, meaning 43 percent of projects fail. (Despite the grim projection, these numbers are actually slightly better than the Standish Chaos report findings). What would happen if we could prevent just, say, 5 percent of those from failing?

The impacts would be huge, because the amount of money spent on IT projects now is truly monumental. Of all these failing projects, there must be many that flirt on the edge of success versus failure--wobbling between being able to be saved and past the point of no return. These are my targets--not the doomed-from-the-start death marches to oblivion but the appropriately staffed, well-intentioned projects that just don’t quite make it. I bet there was a point in the path to failure when some more dialogue around risks and issues could have provided the opportunity to take corrective action.

The trouble is that we don’t know if we are on an ultimately successful or unsuccessful project until its path may be irreversible. So we need to be acting as if we could be heading for trouble at regular intervals. We should also examine the economics behind this suggestion to change PM behavior. How much is it really worth to maybe sway the outcome of just 5 percent of the projects that are headed to failure?

According to The New York Times, industrialized countries spend 6.4 percent of the GDP on IT projects. Of that, 57 percent typically goes to hardware and communication costs and 43 percent to software development. Of these, 66 percent are classed as “at risk” and 65 percent of them ultimately fail. The cost of failed projects is two-fold: There is the direct project cost, but also a series of related indirect costs. These include the cost of replacing the failed system, the disruption costs to the business, lost revenue due to the failed system, the disruption costs to the business, lost opportunity costs, lost market share and so on.

An investigation into a failed Internal Revenue System project showed a 9.6:1 ration of indirect costs to direct project costs. For our purposes, we will use a more modest ratio of 7.5:1. Let’s see how these figure pan out:

So it turns out that the failing SW projects cost the world about $6 trillion dollars annually, and over $1.3 trillion in the United States alone. That’s a chunk of change, and saving just the 5 percent of projects wobbling on the edge of failure in the States would amount to $1,336B x 0.05 = $66.8B (or $1.28B per week).

How do we do it? Well, socializing the problem is a start. Let’s talk about project risks more often and raise them from the clinical world of reviews and audits up to the more human, approachable world of predictions and wagers. Ask team members to predict why the project may fail or get stuck. Ask our sponsors where they think the biggest obstacles lie. Follow up with “How do we avoid that?” and “What would have to happen to prevent that?” type questions, and follow through on the recommendations.

Just the act of discussing these issues can influence behavior. Armed with knowledge of where the really large icebergs are, people tend to steer and behave differently. To reiterate, we are not trying to prevent all project failures; just keep an extra 5 percent on track through frequent, honest dialog about the issues and a broader stakeholder awareness of the major project risks is a great way to start. So what are you waiting for? 

(I wrote this article first for Gantthead, here )

 

Linked below are my presentations from the Agile 2012 Conference in Grapevine, Texas. My slides are really just prompts and pictures to accompany the explanations and stories I tell , but if you were at the conference you will get the idea. For the longer “Collaborative Games for Risk Management” session I have also attached a full 20 page White Paper explaining agile risk management, and the games involved in more detail.  

Thanks to everyone who attended my presentations and, as ever, you are always welcome to contact me if you have an additional questions.

Download File: "Cowboys Presentation"

Download File: "Risk Slides"

Download File: "Collaborative Games for Agile Risk Management - White Paper"

This is the last post in a series on agile risk management. The first looked at the opportunities agile methods offer for proactive risk management, while the second examined the benefits of engaging the whole team in risk management through collaborative games. The last instalment walked through the first three games covering:

1. Risk management planning
2. Risk Identification
3. Qualitative Risk Analysis

This month we look at the final three sets of collaborative team activities that cover:

4. Quantitative Risk Analysis
5. Risk Response Planning (and Doing!)
6. Monitoring and Controlling Risks

The exercises we will examine are

• Today’s Forecast -- Quantitative Risk Analysis
  • Dragons’ Den -- next best dollar spent
  • Battle Bots -- simulations
• Backlog Injector -- Plan Risk Responses
  • Junction Function -- choose the risk response path
  • Dollar Balance -- Risk/Opportunity EVM to ROI comparison
  • Report Card -- Customer/Product owner engagement
  • Inoculator -- inject risk avoidance/mitigation and opportunity stories into backlog
• Risk Radar -- Monitoring and Controlling Risks
  • Risk Burn Down Graphs -- Tracking and monitoring
  • Risk Retrospectives -- Evaluating the effectiveness of the risk management plan
  • Rinse and Repeat -- Updating risk management artifacts, revisiting process

This is the third part in a series on agile risk management; Part 1 looked at the opportunities agile methods offer for proactive risk management, while Part 2 examined the benefits of engaging the whole team in risk management through collaborative games and cautioned us about groupthink. This article walks through those games and explains how to engage a team in the first three of the six risk management steps.

The PMI risk management lifecycle comprises of:

1. Plan Risk Management
2. Identify Risks
3. Perform Qualitative Risk Analysis
4. Perform Quantitative Risk Analysis
5. Plan Risk Responses
6. Control Risks

These phases can be addressed collaboratively via the following team exercises:

• Plan Your Trip (Plan Risk Management)
  • 4Cs: Consider the Costs, Consequences, Context and Choices
  • Are we buying a Coffee, Couch, Car or a Condo? How much rigor is appropriate and what is the best approach?
  • Deposits and Bank Fees – understanding features and risks

• Find Friends and Foes (Risk and Opportunity Identification)
  • Doomsday clock
  • Karma-day
  • Other risk identification forms (risk profiles, project risk lists, retrospectives, user story analysis, Waltzing with Bears - Top 5-10 for software)

• Post Your Ad (Qualitative Risk Analysis)
  • Investors and Help Wanted – classification and visualization of opportunities and risks
  • Tug of War – project categorization

• Today’s Forecast (Quantitative Risk Analysis)
  • Dragons Den – next best dollar spent
  • Battle Bots – simulations

• Backlog Injector (Plan Risk Responses)
  • Junction Function – choose the risk response path
  • Dollar Balance – risk/opportunity EVM to ROI comparison
  • Report Card – customer/product owner engagement
  • Inoculator – inject risk avoidance/mitigation and opportunity stories into backlog

• Risk Radar (Monitor and Control Risks)
  • Risk Burn Down Graphs – tracking and monitoring
  • Risk Retrospectives – evaluating the effectiveness of the risk management plan
  • Rinse and Repeat – updating risk management artifacts, revisiting process

We will walk through the first three steps in this article and then the last three steps next month:

1. Plan Your Trip (Plan Risk Management)
This phase is about deciding and defining how to conduct risk management activities for the project. We want to tailor the process to ensure that the degree, type and visibility of risk management is commensurate with both the risks and the importance of the project to the organization. So we do not use a sledgehammer to crack a nut, or undertake a risky, critical endeavor with an inadequate process.

The other goal we have for this phase is to teach some risk basics to the team since they may not be familiar with the concepts or terminology. The name of the first exercise (“Plan your trip”) speaks to the goal of determining the appropriate level of rigor. Most people can associate with planning for a walk or hike, and this is the context we use for the activity called the 4Cs. Early in any collaborative workshop, I like to get people working. If you let them spectate for too long some will retreat into “observer” rather than “participator” mode.

Working individually (again to encourage active engagement, and avoid groupthink), ask the team to consider what they would pack for a two-mile hike in the country on a warm day. Give them a couple of minutes to create lists on Post-it notes and review their responses as a group. Some will suggest taking nothing, others just a bottle of water, rain jackets, bear spray (I live near the Rocky Mountains in Canada) and all sorts of other things. We then review the pros and cons of these items. They are useful if you need them, but a burden to carry. We then repeat the exercise changing some parameters such as making it a 10-mile hike or a multi-day trip in the mountains during winter. Now the lists get longer as people prepare for more eventualities.

For each situation, we review the 4Cs: the Costs, Consequences, Context and Choices. What we bring (and how we prepare for risk management) varies based on the cost of bringing/using it, the consequence of not having it (rain coat: get wet; warm jacket : cold/hypothermia). We also examine the context we are talking about: preparations for elite ultra-marathoners who are hardy, capable and resourceful, or a kids’ group that needs more protection. Finally, the choices we make should be an informed balance of cost versus consequence in the frame of the context.

We need to understand these same elements in planning our risk management approach, too. Is this project domain our core competency? What are the costs and consequences of project risks occurring? What is our company’s risk tolerance and preferred risk management approach? Make sure people understand the environment.

Another tool to relate the need to tailor the process appropriately is to ask the team to consider the decision rigor they put into their purchases. The way we consider buying a coffee ($2), a couch ($2,000), a car ($20,000) or a condo ($200,000) varies as the figures involved escalate. For a coffee, we probably just find something close, maybe at our favorite store. For a couch, people will shop around and likely buy the one they like the best without much further research. When it gets up to car territory, safety, economy and resale factors are routinely examined. For a condo purchase, the stakes are so high that most people engage professional help from home inspectors and condo document review companies. We need to do the same for our projects, asking what is appropriate for the endeavor.

Finally, if the team is new to risk management then a discussion on the tradeoff between business value and risks might be necessary. We undertake projects usually for the potential upside (or for compliance projects to avoid the downside)--we are hoping for business benefits. Agile projects use business value as an input into work prioritization; we do the high-value items first. We want to deliver business value, and getting business value out of a project is like receiving deposits into our bank account--we want them as often as possible, and preferably as large as possible. Given the uncertainty in the world, we want the biggest gains as soon as possible before anything changes that may threaten future deposits.

In this bank analogy, risks are like withdrawals or bank fees--should they occur, they set the project back, take away resources from delivering business value and threaten the delivery of future value. So to get the most out of a project we need to maximize business value while avoiding or reducing risks. These exercises and discussions aim to get the team thinking about the appropriate level of risk management for the project and gain consensus and support for the strategy that is agreed upon. Without this shared understanding of “Why?” we will not get people invested in the process.

2. Find Friends and Foes (Risk and Opportunity Identification)
The next step in the process is to identify potential risks and opportunities. Opportunities are the “good” risks or fortuitous events that have a positive impact should they occur. We want to avoid risks and exploit opportunities. The IEEE have some good risk profile models for software projects. They were created by collecting risk information from thousands of completed software projects, then categorizing and ranking the common ones. These models can be used in a group setting or, as I prefer, used as the inspiration for a collaborative game. The “Doomsday Clock” exercise is based on a risk profile tool I have written about previously.

Using a clock view pre-drawn on a white board or flip chart, we ask team members to think of project risks associated with each of the topics represented by an hour line on the clock--12 in total. (For a detailed description of the types of risks within each category we would be asking the team to identify, see the spreadsheet attached to the risk profile article.)

This is the doomsday part: Wwe encourage the team members to think of and record as many risks as they can about that topic. We work topic by topic, but if thinking of risks triggers ideas in other areas as we progress, it is not unusual to get risks being added to previously discussed risk lines. Again, I prefer having people working individually for coming up with ideas. Then we put them all on the wall and consolidate and remove duplicates as a group, which also sometimes identifies new risks.

This process takes a while; spending just five minutes on each topic requires an hour to go through them. Discourage people’s tendencies to want to score, rank and solve the risks. This is risk identification--we will have plenty of time to process them later.

Last month we looked at how agile methods provide multiple opportunities for embracing proactive risk management. The prioritized backlog, short iterations, frequent inspections and adaptation of process map well to tackling risks early and checking on the effectiveness of our risk management approach.

We want to overcome many of the correct-but-not-sufficient aspects of risk management seen too often on projects:

    Poor engagement - dry, boring, academic, done by PM, does not drive enough change
    Done once – typically near the start, when we know least about the project
    Not revisited enough – often “parked” off to one side and not reviewed again
    Not integrated into project lifecycle – poor tools for task integration
    Not engaging, poor visibility – few stakeholders regularly review the project risks

This month’s article extends risk management beyond the project manager role and introduces the benefits of making it more of a collaborative team exercise. Next week we will walk through the team risk games one by one.

First of all, why collaborative team games? Just as techniques like Planning Poker and Iteration Planning effectively make estimation and scheduling a team activity and gain the technical insights of engaging people closer to the work. So too do collaborative games for risk management; after all, why leave risk management to the person who is furthest from the technical work – the project manager?

"...why leave risk management to the person who is furthest from the technical work – the project manager?"

Before I upset project managers worried about erosion of responsibilities we need to be clear on what the scope is here. I am advocating the closer and more effective engagement of the team members who have insights into technical and team related risks. I am not suggesting we throw the risk register to the team and tell them to get on with it. Instead we are looking for better quality risk identification and additional insights into risk avoidance and mitigation, not the wholesale displacement of the risk management function.

So why should we bother to engage the team? Why not let them get on with doing what they are supposed to be doing, namely building the solution? Well there are some reoccurring problems with how risk management is attempted on projects. Most software projects resemble problem solving exercises more than plan execution exercises. It is very difficult to separate out the experimentation and risk mitigation form the pure execution. Team members are actively engaged in risk management every day. We can benefit from their input in the risk management process and if they are more aware of the project risks (by being engaged in determining them) how they approach their work can be more risk aware and successful.

The benefits of collaboration are widely acknowledged, a study by Steven Yaffee from the University of Michigan cites the following benefits:

Trying to maximize business value while ignoring risks is a little like trying to heat your home with all the doors and windows open. Much harder work than it need be, unlikely to be successful, and just not very smart.

Risks and opportunities are ever present on complex projects. We can rely on them occurring much like we can rely on the tide coming in. How we choose to deal with them--our risk management strategy--greatly influences whether we rise with the inevitable tide of issues and navigate successfully, or become overwhelmed by them and don’t reach our goal.

Agile methods incorporate many mechanisms for dealing with late-breaking changes (an easily reprioritized backlog, short iterations, frequent inspection, replanning, etc.) that also lend themselves to proactively responding to risks. We can insert risk avoidance and risk reduction actions into the backlog to attack the risks before they have an impact on the project.

This can all be thought of as part of maximizing business value. The process of frequently asking: “What should we do next: build a business feature or reduce a project risk?” is valuable and often summarized by the term “The next best dollar spent.” It reminds us to think about risk avoidance and mitigation as part of the value proposition and agile planning cycle.

So when planning work for the next iteration, we balance delivering business value with reducing risks. Sometimes we select a feature since it is the best return on our investment; sometimes we will undertake a risk avoidance or risk mitigation step since the impact of the risk occurring would be greater than the ROI value of the next feature in the backlog. (This is a quick summary; to read more about putting risk reduction actions in the backlog see here.)

Over the course of the project, agile teams use tools such as risk burn-down graphs and risk profiles to illustrate the effectiveness of the risk-driven approach. The goal is to rapidly reduce risks on the project. (For more on these agile risk reduction techniques, see here.)

Another benefit of tackling risky work early is the cost of change-curve savings possible in software projects. By proactively undertaking risky work early, we can reduce the overall impact to the project compared to if those risks occurred later when their effect (in terms of rework or revision of approach) would be much higher. Simply put, risks solved early are more valuable than risks solved late.

Agile methods with their pull mechanisms and frequent reprioritization can readily take risk management actions as early as possible in the lifecycle, minimizing knock-on effects. Also, since testing is built into each iteration, toward the end of the project the chances of there being any risky elements not tested in the solution are greatly reduced. As such, agile methods can be called “risk-driven” since we are always looking to pull stories with risks forward in the backlog.

While agile methods provide some nice ways to proactively embrace good risk management practices, they do not “risk-proof” nor insulate projects from risks. Indeed, if the agile approach is new to your organization, then its introduction will be a risk itself--anything new represents a risk of misapplication, misunderstanding, confusion and failure. However, agile methods are hardly new anymore and adoption problems are well understood.

This post introduced how agile methods mesh well with the mechanics of risk management. Next time we will examine the next level of effectiveness in agile risk management: how engaging the team members in risk management through collaborative games brings far greater insight into project risks, and their avoidance and mitigation actions.

(Portions of this post first appeared in Gantthead.com here)

I picked up a copy of my PMI-ACP^SM Exam Prep book on a visit to RMC Project Management over the weekend. It was good to see it printed up for the first time, and with all the exercises and 120 sample exam questions, it was thicker than I expected at over 350 full-size pages.

The extra weight also comes from the case studies of agile projects I have worked on over the years and the additional materials I included to link the exam topics together. These items that are not in the exam are clearly marked so you can skip over them if you want. However, I am sure some people will find they add value by making the ideas more real. These additional materials also supply useful information to allow readers to fully understand the topics, rather than just memorize the information for the exam.

I am very grateful to the staff at RMC for pulling together my thoughts and ideas into this book, and for the people who reviewed it. Alistair Cockburn and Dennis Stevens were particularly helpful, and after reviewing it, they wrote the following quotes for the cover:

“As one of the authors of the Agile Manifesto, I am delighted to see this book by Mike Griffiths. It is great that such an exam guide was prepared by someone with a deep understanding of both project management and Agile development. Personally, I hope that everyone reads this book, not just to pass the PMI-ACP exam, but to learn Agile development safely and effectively!”

– Dr. Alistair Cockburn, Manifesto for Agile Software Development Co-Author, International Consortium for Agile Co-Founder, and Current Member of the PMI-ACP Steering Committee.

“This is a VERY enjoyable book to read, due to Mike's firm grasp of the underlying concepts of Agile, and his articulate and entertaining writing style. My favorite part is the fact that it is organized into a framework that helps all of the Agile concepts hang together, so they will be easier to recall when taking the PMI-ACP exam.

But Mike's book is more than just the best PMI-ACP prep book out there. It is also the best consolidated source of Agile knowledge, tools, and techniques available today. Even if you are not planning on sitting for the PMI-ACP exam in the near future you need to buy this book, read it, and keep it as a reference for how to responsibly be Agile!”

– Dennis Stevens, PMI-ACP Steering Committee Member, PMI Agile Community of Practice Council Leader, and Partner at Leading Agile.

Thanks to you both, working with you over the years has been a blast. I would also like to thank the visitors of my blog here, too, for reading my posts and submitting insightful comments that kept me motivated to write. RMC has provided me a limited time promotion code that gives readers a further $10 off their currently discounted price for the book. If you follow this link and enter promo code “XTENMGBD”, you can get the additional $10 discount up until May 18th 2012. This is a 25% reduction on the retail price.

SMEs, SM0s and the Deluded Developer Day

We all want Subject Matter Experts (SMEs), but what happens if we get a Subject Matter Zeros (SM0s)?  How does that impact your schedule, and what about team members who have “other project commitments”? Before you know it, that 6 month schedule that looked pretty comfortable, is looking like a fairy tale.

I recently attended a great presentation by Lee Lambert at my local PMI conference and while he was not talking about agile per say, his commentary on SMEs and part time resources struck a chord, which I would like to share.

The role of the customer, the business, the Subject Matter Expert (SME) on agile projects is vital. They not only help provide requirements, but also clarify details, validate prototypes, perform UAT, tell us about business changes, articulate the goal, prioritize, the list goes on. Great SMEs are like great multi-disciplined developers who can do BA work, architecture, development, and QA – they can just make projects happen. It is rare to get these mythical beings, but I have been fortunate to work with a few.

More commonly we work with SMEs with limited time who have a preference for one or two areas of work, such as providing requirements or testing increments of software. We obviously want the best SMEs we can get, but the best people are always busy since they “get-it” and can crank out work – so who wouldn’t want to engage them?

When SMEs are not available we can assign proxy customers, where perhaps a BA plays the role of the customer, or we get someone more junior from the business who may be less experienced in the role than ideal. These are just the realities of working in companies today and as the Rolling Stones said, “You can't always get what you want, But if you try sometimes you just might find, You get what you need”. When this happens we just need to be sure we understand the consequences to our schedule.

The other factor is team member availability, ideally this is 100%. This makes face-to-face meetings easy, resource leveling a breeze, and a one day task often does actually get done in one day, imagine that! “You, you may say I'm a dreamer, but I'm not the only one”, many project schedules are planned this way even when commitments for support and other projects take availability from the project.

Overall Task Duration is dictated by the productivity of our resources along with their availability, as follows:
So if a task was estimated at 8 hours (one day) for our SME & Dev combo, but we did not get the SME we wanted and instead got a SM0 who, lets optimistically assume is 50% as productive as our SME. Also the developer is not 100% committed to the team, but split across 2 projects and also providing production support for those projects, then their true availability for new development on our project might be only 25%.

Using these figures for our 8 hour task we get: 
This result can be surprising, we instinctively knew it would take longer since the business involvement was not perfect and the developer had other work, most PMs factor in 3-4 times longer, maybe 5-6 times, but it is rare for the full 8 times longer to be properly incorporated.

This is why ideas like Yesterday’s Weather (gauging performance based on previous results) and measuring team capacity via Velocity are often better predictors of completion rates.  The other point it illustrates is the impact and significance of suboptimal resources and non-dedicated participants.

As always the best time to influence project durations and success factors is when selecting the people for the project. It is a too easy to overlook the true impact of a few small compromises and not properly explain the consequences that then accumulate to make projects late. We can use the Task Duration formula to illustrate this or rely on the Beatles “Help, I need somebody; Help, not just anybody, Help…”.

 

Bio: Mike Griffiths is a project manager who seriously needs to update his music collection. He has served on the board of the Agile Alliance and the APLN. Mike is a contributor to the PMBOK v5 Guide, the Software Extension to the PMBOK Guide, the PMI Agile CoP, and the PMI-ACP Steering Committees.

 This post first appeared in Gantthead.com here.

What is project success? Is it just on time, on budget, with required functionality, and to a high quality standard? Or is there more, some missing X factor, a good after-taste, or resonance that we just know is great?

I did some training for a client recently who is interested in measuring project success. The traditional constraint measures of on budget, on schedule, happy stakeholders were not cutting it for him. They were missing this unknown element he was really more keen to measure. We talked about other measures of success including how people feel about the project and the act of leaving a valuable legacy.

There are plenty of examples of projects that might be judged failures by the constraint measures of on budget, on schedule, etc, but successes in terms of how people felt about them and the act of leaving a legacy. They include the Apollo 13 mission, the Titanic Movie, Shackleton and the Endurance, and the Iridium Satellite Network. I wrote about how these “failed” by constraint measures were successes by other measures in a post a couple of years ago.

This still was not satisfactory and these measures were often only apparent long after the project was done. They were too late and retroactive, my client wanted something he could use right now to get a better handle on projects. It turns out what he was looking for might be better explained by Actor Networks with Convergent and Divergent behaviour, (but I did not know that then, so back to the story.)

Bothered by not fully answering his question, I attended the Agile on The Beach conference in Cornwall, UK. I flew into London, where I worked in the 1990’s at Canary Wharf and saw the Millennium Dome being built. Seen in films such as James Bond: The World is Not Enough, the Millennium Dome project that, while on schedule, has been widely labeled as a failure. The white elephant that hardly anyone wanted, and struggled to attract or please visitors. I was even a little surprised to see it was still there, since I knew it had been left empty for a while, used as a temporary homeless shelter, and other things.
 

(This post, a draft sample from my upcoming PMI-ACP Prep book, takes a look at the “Value Driven Delivery” domain.)

Value, specifically the delivery of business value, is a core component of agile methods. This concept is woven into the agile DNA with its inclusion in the Agile Values (“Working software over comprehensive documentation”) and the Agile Principles (“Working software is delivered frequently” and “Working software is the principal measure of progress”). The focus on delivering value drives much of the agile activities and decision making on a project, and it manifests itself in many of the Tools and Techniques (T&T) and Knowledge and Skills (K&S) used. The focus on value is such an essential component of agile methods that the “Value Driven Delivery” domain has the most T&T and K&S of any of the 6 domains. This means we are starting with the biggest section early in this book.

What Is Value Driven Delivery?
Let’s start by defining value-driven delivery. The reason projects are undertaken is to generate business value, be it to produce a benefit or improve a service. Even safety and regulatory compliance projects can be expressed in terms of business value by considering the business risk and impact of not undertaking them. If value then is the reason for doing projects, value driven delivery is the focus of the project throughout the project planning, execution, and control processes.

It is the big picture view, the wearing of the sponsor’s hat when making decisions. By the project manager and team assuming this viewpoint, there is an opportunity to incorporate unique technical insights, such as technical dependencies or risk reduction steps, into the selection of features for a release that the sponsor may not be aware of. However value driven delivery remains a guiding vision for much local decision making, the selecting of choices that maximize the value delivered to the business or customer.

Risks as Anti-value
Risks are closely related to value. We can think of project risks as anti-value, i.e., things that can erode, remove, or reduce value if they are to occur. If value is the heads side of a coin, then risks are the tails side. To maximize value we must also minimize risks, since risks potentially reduce value. This is why the Value Driven Delivery domain addresses many risk reduction concepts and techniques.

Malcolm Gladwell (author of Blink and Tipping Point) was in town a couple of weeks ago and I enjoyed a great presentation he gave on what happens when we think we have complete information on a subject.

The Problem
Gladwell asserts that the global economic crisis was largely caused by “Miscalibration Errors”. These are errors made by leaders who become over confident due to reliance on information. Those in charge of the major banks were smart, professional, and respected people at the top of their game; who, as it turns out, are prime candidates from miscalibration errors.

People who are incompetent make frequent, largely unimportant errors, and that is understandable. They are largely unimportant errors because people who are incompetent rarely get into positions of power. Yet those who are highly competent are susceptible to rare, but hugely significant errors. 

Think of the global economic crisis where bank CEOs were seemingly in denial of the impending collapse of the sub-prime mortgage market. (I don’t mean close to the end when they were secretly betting against the market while still recommending products to their clients, but earlier on when they were happy to bet their own firms on “AAA” rated derivatives that they knew were really just a collection of highly suspect subprime mortgages.)

Anyway, this phenomenon of educated, well informed leaders making rare, but catastrophic errors is not new and unlikely to go away soon, it seems to be a baked-in human flaw. When presented with increasing levels of information our perception of judgement accuracy increases when in reality their judgement may be very suspect. Let’s look at some examples:

Part 2 of my article on Agile contracts has been published on Gantthead.com. Part 1 reviewed the existing agile contract samples from the DSDM Consortium that speaks to “Fit for business purpose” acceptance criteria and “Passing Tests” rather than meeting specifications. Part 1 also examined the CoActivate Community sample Fixed Price agile contract and Jeff Sutherland’s suggestions on early termination and functionality swapping.

Part 2 highlights some of the ideas Jesse Fewell presented on agile contracts at the PMI Global Congress last year. These include Graduated Fixed Price and Fixed Price Work Packages as building blocks for creating agile contracts.

Clearly these contract options are not panaceas to possible engagement woes, but they do offer some examples of how organizations and suppliers have been able to utilize the flexibility of agile for mutual competitive advantage. 

The next occurrence of my Agile Project Management class will be in New Orleans on February 28 and March 1st (Feb 18 Update: and is now full ). After that there is:

Savannah, GA - April 11, 12
Dallas, TX  - October 26, 27
Anaheim, CA - November 7,8

I enjoy delivering these courses and people enjoy attending them too, here are some feedback comments:

"Mike delivers an exceptionally well reasoned and effective presentation of agile. Thoroughly appreciated" - Bill Palace, El Sugund, CA
“The best PMI class I have ever taken.” - Scott Hall, Marriot International
"This was a very well executed course. Instructor (Mike Griffiths) was very engaging!" – Ameila White, Boeing
"The instructor was very knowledgeable, class well organized, content at the right level of detail and very comprehensive. One of the best classes I have taken regarding PM topics" – James Bernard, Scottsdale
"Excellent course with great information" – Tom Gehret, JNJ Vision Care
"Excellent facilitator. Mike is respectful and knowledgeable" - Nghiem Pauline, San Diego, CA
"The course was fantastic " - Kimberly Kehoe, San Diego, CA
"Mike is an excellent instructor and I really appreciated his organized and clear, well researched presentation. His domain and project management experience is evident from his talk. Also I appreciate his exposure/experience to multiple approaches like PRINCE2, PMBOK, Scrum, DSDM etc." - Sarah Harris, OpenText
"Great content and delivery" – Andrea Williams, Fed Ex
"Great Stuff!, Really enjoyed instructor and real-world examples" - Don Brusasco, Northridge, CA
"The instructor did an excellent job of keeping the pace, - clearly explaining topics and providing practical applications" - Cathy MacKinnon, Schering Plough Corp
"Excellent!" – Peter Colquohoun, Australian Defence

All of these classes sold out last year so if you want to attend I suggest you book early; I hope to see you in New Orleans!

A big part of project management is working to grow a high performing team and then caring for that team so it stays healthy and productive. Agile concepts around empowered teams and team decision making support these goals and so there should be no surprise that agile project management aligns well with team development best practices.

However, it never hurts to better understand some of the things that can go wrong on teams so that we can quickly take action and hopefully resolve issues before they become full blown team problems. Patrick Lencioni’s book “The 5 Dysfunction of a Team” lists the following 5 common problems that build on from each other to undermine trust and eventually performance.

1) An absence of trust – an unwillingness to be vulnerable and honest within the group.

2) Fear of Conflict – Teams that lack trust cannot engage in unfiltered debate. Instead they resort to veiled discussions and guarded comments

3) Lack of commitment – without passionate debate, team members rarely if ever, buy in and commit to decisions, though they may feign agreement during meetings

4) Avoidance of Accountability – Due to the lack of commitment and buy-in most people will hesitate to call their peers on actions and behaviours that seem counterproductive to the good of the team.

5) Inattention to results – Failure to hold one another accountable leads to putting individual goals (or department goals) ahead of the project.

Fortunately agile methods and some common sense offer many tools and values to address these issues...

Agile methods are powerful approaches that bring many benefits to how we undertake project work. However, they are not immune to misuse or failure. The following list of 5 common pitfalls are often seen in organizations switching to agile. “To be forewarned is to be forearmed” as they say, so look out for these pitfalls and if you see any developing, a side step can be useful to help avoid the mistakes of others.

1) Agile as a silver bullet - Yes, agile methods can save time, increase business buy-in, and create a high quality product, but they are no silver bullet. They will not bend space or time and allow you to deliver more work that is possible within the constraints of limited time, budget, and resources.

Deciding to switch a doomed project to an agile approach will not make it succeed. You may fail faster, or at least discover realistic progress indicators (velocity) earlier than with a traditional approach, but unachievable goals will remain unachievable. By all means use an agile approach to salvage a core set of valuable functionality from a failing project, but don’t expect agile methods to miraculously make the impossible possible.

2) Agile as an excuse for no discipline – Contrary to some people’s beliefs, agile methods do not abandon discipline and jump straight to coding without the need for plans and estimates. Agile methods involve many high discipline activities and techniques like Test Driven Development, Wideband Delphi estimation, and bi-weekly iteration planning and estimation sessions take a lot of discipline.

If team members are pushing back on estimating or cannot explain the release plan, these are warning signs that they may not be following the agile practices. Instead they could be using agile’s preference for low ceremony documents as an excuse for avoiding doing the disciplined activities that make up each of the agile methods. Hold them accountable, ask for their estimates and request their retrospective findings.

If you don't like
What you got
Why don't you change it?
If your world is all screwed up
Rearrange it

The PMI is calling for volunteers to help write and shape PMBOK v5 Guide Link. Here is your chance to inject more recognition and support for agile methods. I was involved in The PMBOK v3 Guide rewrite and got two small changes accepted in 2004 when agile methods and the PMBOK were hardly being talk about and I was a bit of a lone voice at the party.
 
If you don't like what you see
Why don't you fight it
If you know there's something wrong
Why don't you right it
 
Since then the tides have changed and now the PMI Agile Community of Practice is the largest and fastest growing PMI community. In the last PMI Network Magazine sent to members there were two full articles on Agile project management. Of the PMI’s 340,000 members an estimated 65% are in IT and the demand for agile guidance that has proliferated in other disciplines of IT (development, analysis, QA) is very apparent to the PMI, who need to serve their members.

In the end it comes down to your thinking
And there's really nobody to blame
When it feels like your ship is sinking
And you're too tired to play the game

This article summarizes my “Lessons Learned in Project Metrics: Are your Metrics Dumb or Smart?” presentation. It covers the following six topics

 

2010 is shaping up to be a good year for training courses and events. I have the following public enrolment courses available through the PMI.


March 10-11 Anaheim, CA

April 13-14 Scottsdale, AZ

September 15-16 Las Vegas, NV

November 10-11 Scottsdale, AZ

December 15-16 San Diego, CA

 
My private courses are available year round, see here for a list and course outlines, and I am also hoping to head back to Alaska this summer to teach a class for the PMI Alaska Chapter there again.

As normal I’m keeping the bulk of the summer free to take full advantage of the short, but fantastic hiking and mountain biking season we get here around Calgary. I was hoping to attend the Agile 2010 Conference in Nashville, but the dates August 9-13 clash with the TransRockies Mountain Bike Race August 8-14 that comes right through my backyard of Kananaskis and is too good to pass up.

Instead of the Nashville agile conference, I hope to attend another agile conference in the fall, perhaps the Agile Business Conference in England again, or a Scrum Gathering event. Then of course there is the PMI Global Congress conference in Washington, DC in October. With the PMI Agile Community of Practice now the largest PMI community with >1700 members there will be a large Agile contingent attending and many great agile sessions to go to. Once again so many events and so little time!