They are “Lessons to be Learned”, not “Lessons Learned”

The suggestions, observations and ideas we capture at retrospectives are not Lessons Learned. That would imply we have already learned from them and will not make that mistake again. Instead, they are Lessons-to-be-Learned which is subtly different but stresses the most important part, which is we now need to learn something.

Learning involves several steps. David Kolb, an educational theorist, describes a 4-step learning process:

  1. Concrete Experiences (What we already know)
  2. Observation and Reflection (What our retrospectives help us identify)
  3. Abstract Conceptualization (Thinking about the problems and designing potential solutions)
  4. Active Experimentation (Trying something new)

These stages act as part of an experimental learning cycle. The last step, Active Experimentation, creates new concrete experiences and builds on what we already know. Experimental Learning Cycle

It is easy to confuse the retrospective actions of Observation and Reflection (Stage 2) as gathering lessons learned. However, this is not the case, instead it is just one step in the process. We then need to determine a solution (Stage 3) and run experiments to learn from them (Stage 4). Only then might we actually learn something.

To remind us that simply gathering ideas and suggestions for improvements is not the same as learning, I suggest we stop using the term “Lessons Learned” and instead useLessons to be learned”.


New PMI-ACP Workbook

PMI-ACP WorkbookI 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:

PMI-ACP Workbook 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:

PMI-ACP Book Contents

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.

 

 


Tapping the Base of the Talent Triangle for Hidden PDUs

Hidden PDUsWhen it comes to renewing your PMI credentials it can sometimes be a challenge to find the full complement of Professional Development Units (PDUs) you need. Now the PMI Talent Triangle has been introduced, PMP credential holders need 8 PDUs from each of the skill areas. I often hear of people mention that finding 8 PDUs in the “Strategic and Business Management” area at the base of the triangle seems the most difficult.

PMI Talent Triangle

This might be because some training providers struggle to generate content for this category. There are mountains of existing material for “Technical Project Management” and “Leadership”, but “Strategic and Business Management” seems a little more specialized.

However, once you dig into what it contains, not only is it relatively easy to get the minimum requirement of 8 PDUs, but it is also a fertile source for collecting the maximum 19 PDUs in this category. This article examines the “Strategic and Business Management” area and provides some examples and suggestions for work and study that qualifies here.

Let’s start by getting a better understanding of what “Strategic and Business Management” actually means. Put into other words, it means all the business and industry interactions on the boundary of your project. I like to think of it as the zone immediately surrounding the project you are managing.

Strategic and Business Management

Before your project became a project in your organization there was (hopefully) an idea, discussions around opportunities, feasibility, ROI, and maybe competitive analysis. All these models, interactions with sponsors and advisors fall within the PMI realm of “Strategic and Business Management”.

Then, as the project progresses, anything you do to track performance against these models (financial analysis, benefits analysis, competitor product tracking) and all the interactions with the people in your organization (or client) that are involved with this information also fits into this category. During execution, anything to do with regulatory compliance, legal or market place interactions like trade fairs or journals also fall under “Strategic and Business Management”.

A critical principle for maximizing your PDU eligibility in this area is understanding that any training you undertake to learn more about how your industry interacts with strategy or benefits management fits the “industry knowledge” criteria. So, if you are in the medical profession, medical courses that link to strategy and benefits management count towards this category. If you work in the automotive sector, then training that relates to market share and competitive analysis qualifies towards “Industry knowledge”.

Projects deliver benefits to customers so anything relating to customer relationship and customer satisfaction either during or after the project fit right in. So too does benefits management and benefits realization during and after the project.  Once you appreciate that this category spans all the “Why?” we undertake projects and “How?” we assess their viability, performance and benefits, you begin to realize it’s a treasure-trove of PDU opportunities rather than slim-pickings.

Here are some categories of work, published by the PMI as elements of the “Strategic and Business Management” talent triangle, along with suggestions for how to translate them to claiming PDUs:

  • Benefits management and realization – Training courses, reading and discussions around how we identify, categorize, and measure project benefits. This could include financial benefits, regulatory compliance needs, market share growth, and industry reputation.
  • Business acumen – Any courses, reading, discussions, listening to podcasts, etc (here after called “Learning”) about financial or strategic elements of your business or industry.
  • Business models and structures – Learning about how to assess, select, prioritize and track projects in your industry, company or business unit.
  • Competitive analysis – Learning about feature comparisons, products and services, pricing structures, market shares, sales volumes, growth rates, profit ratios. - Perhaps you can get PDUs for attending those monthly sales meetings!
  • Customer relationship and satisfaction – Learning about customer surveys, satisfaction scores, kano analysis, prototype feedback reviews, Niko-Niko charts, etc.
  • Industry knowledge and standards – Learning by attending industry conferences with strategy content. Site visits, and field work also improve your industry knowledge and exposure to standards.
  • Operational functions (finance, marketing) – Learning about interacting with these business units and functions in your company. Taking internal courses about them and expanding your skills.
  • Strategic planning, analysis, alignment – Learning about these processes and tools in your company and industry.
  • Market awareness and conditions – Learning about trends, markets, new technologies and opportunities.

When you tap into industry knowledge and market awareness you soon realize that training does not have to be about just project management. How projects add value and contribute to a company’s success and strategic vision also counts. You become more useful and valuable as a project manager when you better understand your industry. The PMI knows this and recognizes many forms of professional development in your domain of work.

This is the key to unlocking the base of the talent triangle, the “Strategic and Business Management” component. You just need to connect your training for work with the “Industry Knowledge” and “Market Awareness” hooks in the base of the talent triangle.

Everyone with a PMI credential (except CAPM) must maintain their credential through participation in the Continuing Certification Requirements (CCR) program. Now you know that the “Strategic and Business Management” portion of the talent triangle allows for a wide range of learning opportunities the whole process should get much easier.

 

(I first published this article on projectmanagement.com here)


PMI EMEA – Rome – PMI’s Agile Future

Emea17_rome_badge_800x400_v2I will be presenting at the PMI EMEA Congress May 1-3 in Rome on “PMI’s Agile Future”.

2017 marks an important year for embracing agile approaches by the PMI. The PMBOK® v6 Guide, set to be released in Q3 will have agile accommodation guidance for each of its Knowledge Areas and an Agile Appendix. I wrote these sections with Jesse Fewell and hope they enable practitioners to see how techniques can be tailored for agile environments.

Synchronized for release with the PMBOK® V6 Guide is the new Agile Practice Guide. A collaboration between the Agile Alliance and the PMI to create a guide for project practitioners working in the “messy middle-ground“ of agile teams and plan-driven environments.

I am chair of the author team for this book and just returned from our final meeting to edit the first draft of the guide. We had a huge number of comments from our SME reviewers. Some agile enthusiasts believed it was too lenient to tolerate hybrid approaches as a temporary stepping-stone to fully agile approaches. Some plan-driven enthusiasts believe it was too dismissive of plan-driven approaches to be endorsed by the PMI.

I think if we can equally upset “enthusiasts” at both ends of the agile and plan-driven scale we have probably found the sweet-spot for pragmatic practitioners looking to navigate the very real in-between world we often occupy.

Also, out this year is the BA Standard and BA Guide, similarly with agile coverage. I am grateful to Joy Beatty, chair of the BA Standard and Cyndi Dionisio, chair of the PMBOK® v6 Guide for the support they provided at the Agile Practice Guide - Development Workshop we ran at the PMI Global Congress in San Diego last September.

My “PMI’s Agile Future” presentation for Rome is not just a list of PMI agile products. Instead I will be telling the story of how people have managed uncertainty and complexity through history. I hope to dispel some myths around phase-gates, PERT, Gantt charts and waterfall lifecycles and introduce some unsung heroes of adaptive planning.  Then, to stay on track, I will introduce PMI’s agile developments and link them to the future trends indicating the importance of being able to manage uncertainty and complexity.

I am really looking forward to the event and particularly enjoy talking to people afterwards. Please bring your questions and I’ll see you there.


Boosting PMO's with Lean Thinking

Applying Lean Thinking to PMOLean Thinking, described and popularized in the book “Lean Thinking” by James Womack and Daniel Jones, is summarized as: “focusing on delivering the most value from a customer perspective, while reducing waste and fully utilizing the skills and knowledge of those doing the work”. These are all relevant goals for today’s Project Management Office (PMO) and the reason that increasingly organizations are using Lean Thinking to boost value and reduce waste in the PMO. 

Lean Thinking embodies a wide range of principles and techniques. I like to think of it as a philosophy plus a toolbox of techniques. For this article, we will focus on applying some basic principles for delivering value and identifying wastes to avoid within the PMO.

It’s about people first.

Unlike some other project management approaches, lean is human-centered not process-centered. Two overarching themes prevail over all the practices: 

  • Involve everyone – Always make sure everyone involved, impacted and perceived to be impacted is consulted and engaged in the process. This does not mean every font change of a Project Charter template needs CFO approval, but it does mean that all plans, initiatives and work are open and available for contribution or comment to anyone who is interested. Basically, be open and transparent, you never know who might have a great insight or spot a flaw before it impacts performance.
  • The Customer Defines Value – Rather than automatically acting to minimize costs or reduce time to market, lean specifically adds the step of asking the customer to define what value means to them. Some groups may focus more on quality at the expense of time or costs, others may value time-to-market and happily sacrifice some scope or cost over runs to get there. It sounds like common-sense, but all too often people get disappointed with a group because of mismatched values. Adding the “customer defines value” step helps avoid those mismatches before the can occur. 

Lean Thinking Principles and the PMO

Lean Thinking suggests five principles as starting points for a continuous cycle of delivery and improvement. Let’s review them one-by-one and see how a PMO can embody the concepts they represent: 

  • Specify what creates value from the customer – This principle takes the “Customer Defines Value” theme we just talked about and bakes it right into the first step of the process. PMO’s understand they serve multiple customers, typically including their sponsoring group who pays to put PMO’s in place. 

Value for the PMO sponsoring group likely includes helping projects be successful, ensuring good practices are followed, providing objective evaluation of performance and risk signs, providing help/training where required, etc. Another group of customers is the project teams and team leads / managers. These customers typically want low overheads for PMO compliance and timely responses to requests for support, training, etc. Both of these groups (and any others that apply) must be canvassed to determine what value means to them. 

  • Identify all steps - value adding and non-value adding across the whole value stream that bring a product or service to the customer – This is the process of analyzing how things actually operate to get work done. Some activities are necessary value-adding tasks, such as performing a review, while others will be non-value adding activities, like waiting for feedback. 

Lean thinking provides tools such as Value-Stream-Mapping to analyze processes and categorize value-adding and non-value-adding tasks. It also allows us to calculate metrics like cycle time and process efficiency. Using these tools to look at the current-state and future-states of PMO processes, groups can analyze and optimize how to best deliver value. 

  • Establish flow – The continuous movement of products, services and information from end to end through the process. Moving large batches of anything, whether its requirements in a specification document or artifact templates to a standards library creates consumption and improvement problems. 

It is better to move smaller batches more frequently. That way there is not a large delay while things are consumed and processed, also if defects or areas for improvement are found in an early batch the information can be sent back to the producing group and the issue addressed in later versions. Establishing flow improves efficiency, quality and the ability to manage changes. PMO’s can support this by encouraging the small batch flow of user stories and retrospectives vs specification documents and project lessons learned reports. 

  • Implement Pull – The idea that nothing is done by the upstream process until the downstream, customer signals the need. Stock piling products or service offerings ready for consumption or in-hope that they are consumed is wasteful. It consumes time and energy with in-progress work that has not yet delivered value and often people will want something slightly different. 

A preferable approach is to spend this effort on getting good at rapidly delivering what is asked for. Then establishing signaling mechanisms so that the need (or imminent need) for a product or service triggers its creation. With a stock pile of zero the next item you get is perfectly made for you rather than the next available.  PMO’s can embrace this principle by providing just in time reviews rather than standard readiness assessments. They can also create, say, charter templates based on project characteristics not boilerplate, also Steering Committee updates based on current questions not standard templates. 

  • Work to perfection – The goal is the complete elimination of waste so that all activities create value for the customer by continuous improvement. While perfection may be unreachable, the goal of this principle is to instill the idea that improvement is an ongoing process that does not stop. People should always be looking (and encouraged) to improve the delivery of value.

PMO’s can embrace and model this continuous improvement principle by highlighting their ongoing work in a “What’s New” section of their intranet site. They can help projects and teams by attending project reviews and retrospectives to endorse these activities, provide support and distribute the outcomes to a wider audience. Anything that promotes and encourages the continual pursuit of improvement. 

 

Eliminating DOWNTIME - The Common Forms of Waste

Lean thinking identifies 8 common sources of waste in an organization. Groups, including PMOs should be on the lookout for these forms of waste and avoid or reduce them wherever possible. This is not a one-off activity like a yearly Spring-clean of processes. Instead, it is an ongoing vigilance like work-site safety or maintaining a respectful workplace. People are encouraged to always be looking for forms of waste and then eliminating them if possible. 

Lean thinking has its roots in lean manufacturing and so several of the common forms of waste have titles that are associated with physical production, such as Over Production, Inventory and Transportation. However, versions of these wastes also occur in knowledge worker projects that are more commonly associated with manipulating ideas and information rather than physical goods. Listed below are the 8 common sources of waste and a description of how they apply to knowledge work projects along with advice on how PMOs can help reduce them. The forms of waste can be remembered by the relevant mnemonic DOWNTIME that stands for: 

  1. DOWNTIME 8 forms of wasteDefects
  2. Overproduction
  3. Waiting
  4. Non-Utilized Talent
  5. Transportation
  6. Inventory Excess
  7. Motion waste
  8. Extra processing  

Let’s look at each in a knowledge worker setting and see what PMO’s can do to help. 

  1. Defects – Flaws in deliverables that create work to correct information. PMOs help project teams get things right the first time to avoid making defects. They can also help by providing extra tools and support when defects are found. Since Waste = Impact-of-defect X Time-defect-lies-undetected the timely resolution of defects is in everyone’s best interest. 

PMOs can also help address excessive defects by providing standards and quality control guidance and training.

 

  1. Overproduction – Extra features or extra process that do not add sufficient value. We should always be asking “where is the next best dollar spent?” in other words, what should we do next to best add value.

PMO’s should reinforce this view by reminding people to ask: “Where is the next best dollar spent?” and avoid producing features or processes that are unlikely to be widely used or never completed. Likewise building things that are cool (resume architecture) or “might be needed” are forms of overproduction also.

 

  1. Waiting – Delays for approvals, waiting for projects to start or resources to become available are all forms of waste. They cause people to task-switch which is inefficient and a contributor to defects. 

PMO’s should see if they can reduce waiting by scheduling a better alignment of project authorizations and start-up activities. Also, rather than waiting for team to form, consider bringing new projects to existing high-performing teams. Waiting delays strain learning loops as things get forgotten and it is better to seek out feedback early and apply it as soon as possible. 

  1. Non-Utilized Talent – the waste caused by underutilizing people’s skills, talent and knowledge. Assigning staff to the wrong sort of tasks for their skills and experience results in a lack of engagement. PMOs should work closely with teams to determine not only what experience and skills people have, but also what they would like to try. Then working with projects leads to find a way to give people exposure to these new roles. 

Timeboxed iterations provide a great risk-limited approach for trying new roles and building new skills. If the new roles work out then great do some more, if it does not work out then we learned something and should now try something else. 

  1. Transportation – In knowledge work projects unnecessary handoffs are like transportation waste. They create delays and slow down value delivery. Handoffs also always result in the loss of tacit knowledge. Like the Telephone game, when a message such as “Jon picked an apple from a tree” becomes “Joan licked Adam by the sea” after a few handoffs; details become lost in translation. 

PMOs can reduce transportation waste by eliminating unnecessary handoffs and ensuring information is gathered at source, not relayed through different groups. 

  1. Inventory excess – This is partially done work that represents effort invested with no return yet. Generally, we should try to minimize work in progress (WIP) since managing that status of work and keeping it up to date gets in the way of doing other work. 

PMO’s can help by encouraging and supporting the transition from large batch flow (a single large specification document for a project) and a large analysis and design deliverables to small batch flow, for example just the requirements for the next two-week iteration. 

  1. Motion waste – this unnecessary movement in the knowledge worker world often presents itself as task-switching. It occurs whenever we ask someone to stop what they are doing and work on something else. Team members working on multiple projects must task switch frequently. Each time they have to finish and mentally park what they are working on, move to the other project and reorient and then restart the activities they were doing there. Studies show a significant reduction in productivity and a dramatic increase in defect rates. 

PMO’s can eliminate task switching motion waste by first demonstrating the desired behavior within the PMO. Instead of having a dozen initiatives on the go at once with people splitting their time between them, prioritize and execute them sequentially. Having firsthand experience of increased productivity the group can more credibly help spread the word to project teams and into the portfolio and program planning activities that spawn so many simultaneous projects in the first place. 

  1. Extra-Processing – This waste on knowledge work projects often takes the form of relearning. Poor knowledge capture leads to people having to go through the same pains and rediscovery rather than asking people who know. Other instances stem from poor instructions, and reassigning people too frequently. Finally, extra-processing can also take the form of overengineering a solution or demanding too high of a quality for the use of the product at hand. 

PMO’s can help by looking at the common questions they get asked or the common omissions they see on projects and then providing information and materials to address those shortcomings in future. Using the “Where is the next best dollar spent?” question can also help diagnose where overengineering and too high quality investments are being made. When you consider all the things we need to fix and where we are trying to get to, should we really be spending more time on X or working on some other initiative? These techniques and questions can help PMOs avoid Extra-processing wastes.

  

Take Aways

Lean thinking focusses on serving customers by adding value and eliminating waste, which is well aligned with PMO goals also. PMO’s can learn lots from applying lean thinking principles to not only increase the value of the projects they support, but also increase the value of the group itself.

 


Agile DNA Webinar

Agile DNA 2This post is a follow-up to my Agile DNA webinar I hosted a couple of weeks ago. This was my first webinar for RMC and we had a great attendance with over 2,000 people registering for the event. The recording is available now,  see below for details of how to access it.

The webinar was entitled “Agile DNA, the People and Process Elements of Successful Agile Projects” and the DNA theme came from the twin strands of People and Process guidance that run through all agile approaches and make agile uniquely what it is.

Agile DNA 1

In case you have not noticed it before, Agile approaches weave people elements and process elements together through the agile mindset, values and principles. For simplicity of understanding we pull these elements apart to talk about them individually, but in reality, they are inextricably linked and self-supporting.

Continue reading "Agile DNA Webinar" »


“When Will This Software Project Ever Be Done?”

NoProjects imageDoes this question sound familiar? If you get asked it regularly then you may be part of the mainstream transformation from software projects to products. It’s coming and it's going to turn many roles, certifications and in some cases entire companies on their heads.

 

The last couple of software projects I worked on were large, multi-year endeavors to build in-house systems that add competitive advantage for the sponsoring business group. It did not take multiple years to build the initial product, instead after delivery the business wanted more functionality, more integration, more automation.

The “When will you be done?” issue

The success and reliance on the new system bred further investment. The fact that business sponsors wanted to continue development was a good endorsement for the value being delivered. Yet there was a conflict at the steering committee level and PMO level. “When are you people going to be finished?” was the common question.

Answers like “never” or “when the business unit stops innovating and enters a decay phase” are generally not acceptable. Things are made worse by the teams being staffed, in large part, by expensive contractors. To the CFO or VP who does not use or see the benefits the system delivers these successful in-house products seem like make-work exercises or country-clubs for development teams that have become all too familiar with the business units they are embedded in.

This is not a problem, this is the future

However, we are not witnessing a problem, we are witnessing the future. Software is becoming more critical to business and projects are ending (or will never end) as we take more of a product vs project view of software.

Continue reading "“When Will This Software Project Ever Be Done?” " »


The Business Analyst and the Product Owner


BA and PO rolesIn my last article we talked about the role of the BA on agile projects, reviewing what stays the same and what changes from traditional approaches. In this article, we will review the contentious topic of how the role of the BA varies and overlaps with the Product Owner (PO). We cover the similarities and differences including danger signs such as “BA as PO Go-Between” and positive patterns such as “BA as PO Supporter”.

 

The Product Owner (PO)

First, let’s make sure we understand the role of the Product Owner (PO). It originated in Scrum but is often also used beyond Scrum in other agile approaches and hybrid approaches. The Scrum definition of the role is the person responsible for maximizing the value of the product and the work of the development team. This includes being responsible for managing the Product Backlog. Extreme Programming (XP) has a similar “Customer” role, DSDM has one or more “Business Ambassadors” depending on the scale of the project. They all play a similar role in stewardship of the backlog, including:

 

  • Ensuring that the product backlog is visible, transparent, and clear to all, showing what the team will work on next
  • Ensuring the team understands items in the product backlog to the level needed
  • Clearly expressing the product backlog items
  • Ordering the items in the product backlog to best achieve goals and outcomes
  • Optimizing the value of the work the team performs

 

Benefits Beyond Backlog Management

In addition to this backlog focused work, the Product Owner is often the primary interface to other business stakeholders. They help teams gain access to business subject matter experts for insights on topics where the Product Owner may not have all the answers. They also often act as a gateway to funding, making the business case for additional funding requests, or as a powerful ally when asking for roadblocks to be removed. Playing the “Business is asking for X” card is typically stronger than the “Team is asking for X” card when asking for an exemption from process, or to expedite an issue.

 

Continue reading "The Business Analyst and the Product Owner" »


BA's on Agile Projects?

Team EffectivenessThe role of the business Analyst (BA) on agile projects in some ways parallels the role of the project manager (PM). In that, some people believe these roles are not needed at all! The Scrum Guide, for instance, that outlines the Scrum approach describes only three roles: Scrum Master, Product Owner, and Development Team. Even when you look deeper into the Scrum Guide’s description for The Development Team role, it does not mention analysts or analysis work. However, most organizations agree, good BAs are great assets for any team, be it plan-driven, agile or hybrid.

This article examines what BAs really do, looking at what stays the same on an agile project and what changes. The quick version is that the What and the Why fundamentals stay the same, but all the How, When, Where and With Whom details change dramatically.

Let’s start with What business analysts are supposed to do. (I say supposed to do rather than actually do because yours might watch cat videos most of their time and that is not what they are supposed to do!) Anyway, Business Analysts elicit, analyze, communicate, manage and validate requirements. They also help understand the business and make sure the solutions fit the business. In addition, they help translate technical issues to the business and facilitate stakeholder communications.

Why they do these things should be fairly obvious. To help ensure the project builds the right product, and requirements are not missed or misunderstood. They are also valuable to help facilitate and bridge communications between client, customer and technical groups.

The good news is that all these functions, roles, needs or whatever you want to call them still exist on agile projects. Also, to some extent, because agile timelines are often compressed, these functions become more critical for teams to remain productive and so good BAs are extra valuable.

Now for what changes; let’s start with the How? Agile teams typically do not create large, detailed requirements documents that get reviewed and signed-off before development begins in earnest. Instead, requirements may be captured as user-stories, or on index cards that act as reminders to go and have a conversation with the relevant subject matter expert prior to development. They are typically smaller in terms of how much scope they cover and depth of description. More like micro-requirements for attention deficit readers who only want small, bite-sized components.

 

Continue reading "BA's on Agile Projects?" »


New Role with RMC Learning Solutions

RMCLS LogoI have taken on an exciting new part-time role with RMC Learning Solutions as their Agile Practice Lead. I worked with RMC to create my PMI-ACP Exam Prep book and their ACP training offerings. So, I am really looking forward to working with them further. Previously, as a one-person company with a full-time contract job, I had more ideas for books, web sites and articles than I ever had time to develop. Working with RMC who have dedicated production staff, web developers and editors, I hope to get a lot more content available for a larger audience.

For the last 16 years, I have been pursuing my agile writing in my “free” time. I moved to Canmore a few years ago, and love the location, but the commute to Calgary further ate into that time. Working 50% of the time for RMC from home will free up more time for writing and occasional training and consulting. My challenge will be to stay focused and not use all the extra time for biking, running and skiing.

For RMC, my year kicks off with an introduction to agile webinar called “Agile DNA”, sign-up here. Then an e-learning course and a new book I have been working on will be announced with more to follow. Stay tuned for updates and more articles; heck I might even upgrade my LeadingAnswers.com website to be responsive and searchable – or go fat biking.


Agile DNA Webinar

Agile_dna_webinarI am excited to announce a free webinar with RMC Learning Solutions entitled “Agile DNA: The People and Process Elements of Successful Agile Projects” that will be taking place on January 11th 2017 at 12:00pm Central Time.

This is an introductory level presentation about agile approaches that qualifies participants for 1 PDU. The “Agile DNA” title comes from the twin strands of People and Process that are woven into agile approaches and uniquely define what they are. Please join me for this review of agile through the twin lens of People and Process to get a deeper understanding of the building blocks of agile.

Register now for this event here.


The True Cost of Free Exam Prep. Questions

Free QuestionsMost people taking a project management certification exam use sample tests. Whether it is a PMP exam, ScrumMaster, CAPM, PMI-ACP, PgMP or many others, there are plenty of online options for getting familiar with the format and determining if you are ready to sit the exam proper.

Unfortunately, like all things found online, the quality and relevance varies considerably. If we are just looking for funny cat videos, the occasional shaky video filmed in portrait mode is annoying--but easily skipped and not the end of the world. However, bad exam simulators can give a false sense of security--or a false sense of insecurity--and generally do not prepare you at all for what the actual exam will really be like.

Before getting trained and involved in question writing for PMI and professional training companies, I had no idea about the science behind good multiple choice questions. Now, I cannot help but notice poorly written questions. Even if the test is free, if it tests material not in the exam, it can generate unnecessary anxiety for people studying--and so is bad value. More frequently, people get used to poorly written questions (because these exams are free, they consume a lot of them), and then find the real exam very different--and fail.

So how do you ensure you are taking good, quality sample exams? The simplest and most effective way is to only trust questions from a reputable training company. They have writers that have been trained in how to create questions that meet ISO/IEC 17204 requirements. This is the standard that PMI and many other reputable certification bodies use, such as doctors and teachers.

Ask yourself how much your study time is worth, what are you giving up to get this certification? Given the sacrifices made so far to study, investing in an exam simulation from a reputable source makes good economic sense. However, I understand not everyone can afford or justify paid content, so let’s at least understand how to assess questions to make a judgment call on if the exam simulation is useful or a dud.

Multiple Choice Questions: A Primer
First, a primer on exam question design. This is useful information for everyone taking a test. Understanding how questions are designed helps you answer them more successfully. We will also uncover why you might be good at acing free online tests, but then trip up on the real deal. It all comes down to your online question writers often not knowing this theory.

Multiple choice questions (MCQ) are deceptively simple, so people underestimate them. It seems pretty easy--there is one right answer and three wrong answers. As a test taker, you just pick the right one; as a test creator, you just write the questions and think up a few wrong answers to catch out the guessers.

Let’s start by examining the anatomy of a question and learn the lingo. First of all, questions--along with their correct answer and incorrect options--are called “items”:

 

Continue reading "The True Cost of Free Exam Prep. Questions" »


Agile Risk Management

Risk Action in BacklogThis 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. 

Continue reading "Agile Risk Management" »


When Outsourcing Makes Sense

When to Outsource GridDisclaimer: 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.

Continue reading "When Outsourcing Makes Sense" »


PMI-ACP Exam Prep with Mike Griffiths – Mind Map

Mind Map SmallFor anyone studying for their PMI-ACP exam, I have created a mind-map of the PMI’s Exam Content Outline and my book contents. So here it is, on a single (large) page all the topics within the exam and the second edition of my book.

Mind-maps show relationships between topics and provide hierarchy and structure. It could be used as a study check list – print a copy and cross off topics you are comfortable with leaving the topics to study. Or an everything-on-one-page view of the content in the exam – like a packing list for a trip, you can refer back to it and reassure yourself you “have” everything.

Anyway, if you find it useful you are free to use it for you own personal study. I hope it is helpful in an: “OK, I have got this” kind of way and not scary as in an: “Oh no, look at all the stuff in the exam!” kind of way.

I think it is interesting to understand why laying things out spatially helps with comprehension and recall from memory. It allows us to tap into our spatial awareness and engages the right hemisphere of the brain and that makes us less likely to forget them. (Assigning things we want to remember to a location is a memory aid that many memory-improvement techniques use. Probably using skills developed back in our hunter-gatherer days when our survival relied upon remembering where to find food and water, we have better recall of things assigned a physical location.) This is the reason today’s military still use visual tokens to represented enemy forces, despite having access to the world’s most sophisticated tools. The impacts of forgetting about them can be fatal; fortunately, exams are less critical, but we can still benefit from tapping into our spatial recall circuits.

Use the link below for the high resolution version.

Download PMI-ACP Book Mind Map


The Diagnosis and Treatment of Bimodal IT

Bimodal IT TreatmentIs it just me, or does Bimodal IT sound like a mental health condition? Unfortunate name aside, it has been adopted by companies reluctant to embrace agile but looking for a halfway-house / best-of-both-worlds solution.

In my last post I reviewed some of the issues I see with Bimodal IT; these include promoting a segregation of techniques when companies really need integration and recommending sequential lifecycles for complex projects. While it is easy to poke holes in ideas, it is more useful and rewarding to fix and improve things. So, let’s help organizations using Bimodal IT improve.

First, we should acknowledge the elegance of its simple design and understand why organizations are drawn to it. The simplicity of an If-This-Then “A”, If-Not-Then “B” approach is appealing and it allows companies to try agile-like approaches without making a full commitment. There is a refreshing clarity and simplicity in a simple two-way model. However, true to its namesake personality disorder, organizations using Bimodal IT exhibit large swings in the execution approach that are not natural or optimal.

Diagnosis: Tyranny of the OR vs. the Genius of the AND

In the book “Good to Great” Jim Collins popularized the idea of the “Tyranny of the OR vs. the Genius of the AND” to explain the problems of being forced to choose from alternatives and the potential in choosing a better third alternative – even if it takes more effort.

The “Tyranny of the OR” part describes having to choose from two seemingly contradictory strategies – either Mode 1 which is traditional and sequential OR Mode 2 which is exploratory and nonlinear. The “Genius of the AND” part refers to instead embracing both ends of the continuum and simultaneously making the best decision for the unique circumstance at hand. Most organizations are ruled by the tyranny of the “OR”, whereas Great organizations find a third way to satisfy both and leverage the Genius of the “AND”.

Jim Collins linked the ability to leverage “AND” thinking to high performing companies, but this third alternative or “Middle Way” has been around for a long time. I wrote about it in 2008 here, and my favorite quote relating to it is: “The test of a first-rate intelligence is the ability to hold two opposed ideas in the mind at the same time, and still retain the ability to function.” - F. Scott Fitzgerald.

Treatment: Mix Models, Engage the teams and Innovate

An example of applying the AND mentality to Bimodal IT would be to execute a couple of Mode 1 and Mode 2 projects and then get the teams together for an improvement workshop. We could ask them about their experiences and suggestions for cross-pollination of the best techniques. Maybe Mode 1 projects could benefit from a monthly Show-and-tell review of project outputs and planned work for the next period with the wider project community? Maybe Mode 2 projects would benefit from the development of RACI charts before distributing work between team members and part-time supporting roles?

I am not suggesting these are universal enhancements Mode 1 and Mode 2 projects, they are just examples of things that might be suggested. The real power of the process comes from getting people thinking about how to improve the process and caring about the outputs. Giving people input into how we undertake work and the ability to improve it moves them from un-invested-followers of a process to engaged-workers with some autonomy and say in how things get done. Guess which group enjoys their work more? Guess which group tries harder to overcome problems and deliver results?

I am in favor of using established and proven development approaches, they leverage good practice and help prevent common pitfalls. However, since organizations vary in function, organization and culture it is naïve to assume different companies should use the same one (or two) processes to execute their projects. The impacts of failure in air traffic control are quite different from pop-culture web sites and they should use different development approaches.

As Alistair Cockburn and Jim Highsmith have been saying for decades, we really need a methodology per project. Or as the Declaration Of Interdependance (DOI) say an approach that is "Situationally Specific". If this all sounds too hard or complicated it need not be. There are lots of free frameworks available to engage their team members in continuous improvement of their methodology. Doing so also increases ownership, support and engagement.

The continuous improvement model used could be one already in place at the organization or one that best fits with the mindset or culture. It could be PDCA, Six Sigma or Kaizen, they all share six common principles.

Summary

Gartner did a great job creating a framework that is appealing and accessible to organizations slow to adopt adaptive lifecycles. If they were to now follow it up with some guidelines for tailoring and evolution within organizations adopting it they would have a winning strategy for engaging participants and driving better results.


Agile Coach Camp

Agile Coach Camp CanadaI attended this event last year and enjoyed it...

We would like to invite Agile Practitioners to Agile Coach Camp Canada - West, an Open Space Conference to be held in Vancouver, BC on the weekend of June 17-19, 2016.

Agile Coach Camp – An Unconference

The annual gathering at Agile Coach Camp creates opportunities for our Agile community to share our successes, our learning, our questions and our unresolved dilemmas – all in an energizing and supportive environment.

The Open Space Technology, Unconference format, encourages participants to join the conversation.

Each of us can make a contribution to the art and science of helping people and teams be their best as they deliver valuable software. Share your stories, observations, and inquiries. Discuss challenges you have overcome or those you are still wrestling with today. Describe opportunities you see emerging as we seek to improve the organization of knowledge work. Bring your questions. Test your ideas. Listen and learn from others.

The fee to attend this unconference includes all food & drink for Friday evening, Saturday (breakfast, lunch & snacks) and Sunday morning. Early bird pricing currently in effect $95 CAD until May 10th.  Thereafter the regular event ticket will be $125 CAD.

For more information, or to register, visit the Agile Coach Camp Canada West website.



PMBOK v6 Work

Agile LifecycleAs you probably know the Exposure Draft of the PMBOK v6 Guide is making its way through review at the moment. I have been working with the PMI on some iterative, adaptive and agile content and look forward to when the non-disclosure agreements are lifted and I can tell you all about it. I think I can state, without saying too much, that people can expect to see a natural evolution of mainstreaming techniques that are now considered common practice.

Looking through my web site visitor statistics it is clear that one of the popular resources is my PMBOK v4 Guide to Agile mappings. These were created many years ago to support a training course I used to run for project managers operating in environments governed by PMBOK v4 Guide processes.

A couple of years ago I updated the "Agile Guidance for the PMBOK V5 Guide" but did not share it publicly because it is just as easy to misuse it as use it. It is NOT a how-to-do-agile in a PMBOK based company, a project executed only through the steps discussed in the guide would be a nasty Franken-process that is neither agile or plan based. Instead, it is a thinking tool and discussion guide only for people operating in environments with both plan-driven and agile type. With that prefix and warning, my agile discussion of the PMBOK v5 guide can be viewed and downloaded here: Download Agile and PMI PMBOK v5 Guide Alignment.


DSDM Video

DSDMI get the feeling that DSDM is considered by many people outside of the UK as the uncool, out-of-touch great-uncle of agile. While somewhat related to modern agile, it is kind of forgotten about or dismissed as outdated or not applicable. While some Not Invented Here (NIH) prejudice is natural, there is a cruel irony in DSDM first being criticized for being too large and bureaucratic to be truly agile because it includes architectural elements and program management guidance, then 20 years later SAFe, LeSS and DAD adding these elements for large enterprise suitability.

Anyway, I was impressed by a short video produced by the DSDM Consortium. Despite helping create DSDM 22 years ago I still sometimes struggle explaining its origins and role in the Agile Manifesto to people who are not familiar with it. I think the video is a great introduction and applaud the Consortium for creating it.


In Two Minds About Bimodal IT

Bimodal IT MindsGartner’s Bimodal IT approach has been gaining momentum for the last 18 months. It promotes the adoption of a twin track approach to methodology selection. In Gartner’s words “Bimodal IT is the practice of managing two separate, coherent modes of IT delivery, one focused on stability and the other on agility. Mode 1 is traditional and sequential, emphasizing safety and accuracy. Mode 2 is exploratory and nonlinear, emphasizing agility and speed.”

On the one hand I applaud any approach that helps bring the benefits of iterative methods and increased collaboration to organizations, especially those that have previously resisted them. On the other hand, I have some reservations with a model that polarizes guidance, categorizing projects into either traditional/sequential or exploratory/agility, when projects exist on a spectrum and the best approach is likely a smart mix of techniques.

It’s a Continuum Not an “A” or “B” Decision

Bimodal IT distribution

If your project is simple, visual and being undertaken by a small, co-located team then an agile approach is likely a good fit. However, big, complex, embedded systems undertaken by large and distributed teams also benefit from an iterative approach to the early identification of risks, confirming true requirements and surfacing gaps in understanding.

Also, given the complexity of large systems, the chance of getting something complicated done right through a sequential process is very small. Likewise, we cannot expect a project manager to understand all the technology portions, project dependencies and estimation outliers. Engaging the team more through collaborative practices to better estimate, plan and identify risks produces much more robust plans. Then through the iterative approach of developing real, executable slices of the application, the validity of these estimates can be checked and refinements made to model the likely outcomes.

These benefits coupled with others around an increased sense of ownership and accountability by the team for having been involved more in the planning and ongoing steering of the project, I believe large complex projects need agile techniques more than small simple projects.

I am not saying large projects should be run purely with agile methods, they need additional layers of rigor and communication, but there are some great scaling frameworks like Disciplined Agile Delivery (DAD) that do this without losing the benefits of iterations, adaptation and empowered teams. However, Bimodal IT steers companies away from many of the tools ideally suited for large projects.

“Bargaining” is the Next Step after “Denial” and “Anger”

Bimodal IT Progression Stall

Change acceptance, like grief, goes through stages. The first stage is Denial, we refuse to believe this is real, is happening to us, or applies to us. Traumatic loss or change is often accompanied by a surreal, outside-observer feeling as we struggle to accept what has happened or is happening. At a level of significance down from trauma, denial is expressed as rejection. “Agile does not apply to me!” Next comes Anger “You can’t make me use agile! I have been managing projects with a sequential process for 30 years, and I will not change now.

The next stage after Denial and Anger is Bargaining, where people try to avoid or minimize the impact of a change by making some highly visible or not really substantive bargains. For example, “OK, I will use an iterative approach, how about I make my iterations 6 months long?” Here, the resistor is negotiating or bargaining terminology “I will use an iterative approach when…” for an excuse to continue operating pretty much as they were before.

This is where I feel Bimodal IT resides and in part it explains its gain in popularity. It appeals to organizational leaders who do not really understand or believe in the benefits of an agile approach, but are under pressure to keep up with the times, offer agile projects to their teams, appear responsive to their business community. By publicly adopting Bimodal IT, they can push the small, trivial projects through an agile methodology - appeasing critics while clinging to their more comfortable traditional, sequential model. Since most organizations have significantly more small projects than large ones it may even appear that half or more of the projects being undertaken are Mode 2, agile projects when this represents only a small proportion of the project work being undertaken.

Simplicity Sells

People seem to like simple rules, even if they represent a suboptimal solution. The Atkins diet was very popular because a rule like “No Carbs” is simple and people liked that. Ask a nutritionist though and they will do two things, first they will explain that while it has some truth to it, the real makeup of good nutrition is more complex and varies depending on a large number of factors. The second thing they will do is to start explaining the large number of factors and either confuse you, send you to sleep, or make you wish you never asked them in the first place.

The same is kind of true for the best approach for developing software. Simple rules like Mode 1 traditional and Mode 2 agile-ish are appealing since they are easy to follow. However, like any restrictive diet, they are at best an over simplification and at worst are potentially harmful.

As an example Gartner states their Mode 1 approach that is traditional and sequential emphasizes safety and accuracy, but I would feel much safer and confident in a system where the highest priority features were developed first and have been reviewed and tested in every iteration since, than an approach that had lots of careful planning and then testing performed towards the end of the project. Iterations drive use and uncover missed requirements and defects. You can plan in detail and analyze requirements with reviews and tools – I spent 10 years of my software career working on very formal military projects – but, I believe the best way to discover if software works is by working the software.

Gateway Drugs

For me there is just too much wrong with Bimodal IT to recommend its use. It polarizes project selection when we should be looking more at hybrid models for large projects. It promotes more of a bargaining adoption of iterative methods and empowered teams than a serious acceptance of where these approaches can help all project types. Finally, it propagates dangerous sequential process models for large and complex projects that really need iterations more than small, simple projects.

If it has a redeeming feature it is that it could lead to the introduction of some iterative based projects, that then open the door to more agile projects, in organizations that had up until then resisted agile methods. I think Gartner should not end with the Bimodal framework, but use it as a foot-in-the-door primer for the Next Steps of continued evolution. So, while it currently has some use as a gateway or stepping stone to deeper thinking about project approaches, it should not be considered a destination for IS policy as it stands today.