Innovation: Running Experiments and Learning

Experiment DesignIn my last article on Incubating Innovation, we explored the culture and mindset of accountable experimentation. This article focuses on actionable tools and approaches.

Within agile frameworks, the team retrospective is the primary workshop for planning and evaluating experiments. Yet most team retrospectives I see are broken.

Teams spend too much time recording viewpoints and information—but not enough time reviewing or planning experiments. It is common to see the majority of the time spent gathering what went well, what did not go well, and appreciations. Yet where’s the focus on experiments, the learning process and trials for the next iteration?

To make things worse, some teams do not take the retrospective seriously. Maybe after the potential stress of the sprint review, the largely internal retrospective is a relief. A chance to chill out, maybe share some food, and pat each other on the back. However, innovation and learning take conscious effort, forward planning and accountability.

As I work with organizations, I often sit in on retrospectives. Of all the regular workshops/ceremonies, these sessions are typically the least prepared for and worst executed. I often see lazy retrospectives where a basic lessons-learned format is used, but timings are not managed and the recommendations for the next sprint get skimped as they run out of time.

The pie chart below shows a typical planned allocation of time—and the reality of how time is actually spent:

R1

In these lazy retrospectives, people are slow to start, spend longer on recording what went well than what could be improved, and then try to cram the recommendations for experiments (the most important part) into the last few minutes. As a result, experimentation suffers. Few experiments are scheduled for the next sprint, and those that are run are not evaluated properly.

This is not how agile retrospectives are supposed to operate. An excellent guide to running effective retrospectives is Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. In it they describe a five-step process:

  1. Set the stage – Help people focus on the task at hand; check that people are ready and willing to contribute. Outline and gain consensus on the process we will use. Techniques we can use include: check-in, working agreements, focus-on/focus-off (see the book for full descriptions of these techniques).
  2. Gather data – Create a shared view of what happened during the sprint/iteration. When completed, we should have a common understanding of the observations and facts. Team activities we can use include: timeline, mad-sad-glad, team radar.
  3. Generate insights – This focuses on understanding the implications of our findings and discussions. We need to see the impacts of the problems we are faced with before trying to solve them. Techniques we can use include: five whys, fishbone analysis, dot voting.
  4. Decide what to do – Now we move from thinking about the iteration that just ended to what we should try next to improve things. We identify the highest-priority action items, create plans for experiments and set measurable goals to achieve the desired results. Techniques we can use include: SMART goals, circle of questions, short subjects.
  5. Close the retrospective – Here we reflect on the retrospective process and express our appreciations. We may summarize what we have decided to keep or change and what we are thankful for. Team-based activities we can use include: plus/delta, return of time invested (ROTI), appreciations.

This is a more useful format. However, despite people having access to good retrospective advice, poor implementations are still common. Teams continue to attend late, start slowly and run out of time or rush the agreement on what experiments to run.

R2

The recurring theme is poor experimentation design and restricted learning. Gunther Verheyen summarized the problem nicely in his recent post entitled “Inspection Without Adaptation Is Pointless.” Gathering data and deciding what to do is pointless if it is not acted upon. We are doing most of the preparation work but not getting any of the benefits.

Experiment Design to the Rescue
Fortunately, there are some good models we can use. We need to manage time and effort more effectively and use retrospectives to plan and evaluate more experiments. We should spend only 50% of the available time on gathering information and the remainder reviewing the results of past experiments, making wins part of our process, designing new experiments and learning from inevitable failures.

We can help the time management problem by assigning work to be done in advance. People should be thinking about issues and potential solutions independently. There are benefits of group discussion and consensus gathering on agreed experiment design, but observation and idea generation is best done individually.

The New Yorker magazine [3] describes numerous studies that show how brainstorming groups think of fewer, lower-quality ideas than the same number of people who work alone and later pool their ideas. There have been numerous reports on the downsides of brainstorming ideas as a group. Groupthink and the halo effect stifle idea generation. So, ask for people to come with ideas, then use the group setting to vet and vote for them.

Visualizing the ideas and experiments is an effective way to bring collective attention to them. Trent Hone and Andrew Jarding developed the “Ideas and Experiments board” pictured below. It shows the progression of ideas through experiments and their success or abandonment:

Experiment Board

Ideas and Experiments Board (Image Credit: Trent Hone and Andrew Jarding, MindSettlers)

As discussed in the last article, by design, 50% of our experiments should fail since we are trying to maximize our learning, not validate things we already know. So I would expect to see an equal number of abandoned experiments as successful ones.

However, this format (or a slightly modified version that represents an experiments Kanban board) is a useful tool to bring the focus for retrospectives to the experiments being run and considered. With some pre-work on idea generation and an increased focus on experiments, we can structure more effective retrospectives.

R3

This retrospective format saves some time by assigning idea generation as pre-work; this also helps avoid the groupthink pitfalls. It furthermore places emphasis on the experiments—the inputs for learning and innovation.

I have experienced pushback from teams about the goal of 50% experiment failure. People understand it optimizes learning—but say it sets people up for too much failure. I understand the sentiment but counter with two perspectives.

First, these are experiments; they should be dispassionate explorations, not evaluations of the people undertaking the work. We need to be professional and try to overcome habits of internalizing results. I know this is easier said than done, so also offer a second reason: We need to kill bad ideas early to save time and money for better ones.

In the article “The Hard Truth About Innovative Cultures,” Gary Pisano describes how killing bad ideas is critical. He profiles Flagship Pioneering, a Massachusetts-based R&D company. It uses a disciplined exploration approach to run small experiments minimizing expenditure. Instead of running experiments to validate ideas, it designs “killer experiments” to maximize the probability of exposing an idea’s flaws. The goal is to learn what went wrong early and move in a more promising direction.

Other useful ideas from the paper include:

  • Tolerance for failure, but no tolerance for incompetence – Hire the best people you can. Explain the goals clearly and let go of those that do not perform.
  • Psychologically safe, but brutally candid – Encourage frank but respectful two-way dialog. It may feel uncomfortable, but it can prevent issues or concerns from going unreported.
  • Collaboration—but with individual accountability – Encourage discussions, but avoid groupthink and hold people accountable for decisions and outcomes.

These are all great concepts and align with the frustrations I experience when I see teams not taking retrospectives seriously—or following through on conducting experiments. I realized I needed a better model for discussing the problem. Fortunately, I found the field of collaborative problem solving (CPS).

CPS is the study of how we work together in groups to solve new problems, innovate and build products. The innovation process and retrospective workshop fall squarely within its scope. CPS skills are quite separate from individual task-focused skills, meaning people can be great at working individually but poor at working together.

A good introduction to CPS frameworks can be found in the article “Advancing the Science of Collaborative Problem Solving.” One model they feature is the “PISA 2015 Collaborative Problem-Solving Assessment.” Unfortunately, like many academic models, the degree of difficulty goes downward, which may make sense as you read down through more advanced stages. However, I think graphically, so I have redrawn the model to show degrees of completeness and difficulty radiating up and out from a 0,0 origin, as shown below:

PISA 1

Along the X-axis, we see three categories of collaborative problem-solving competencies. These are:

  1. Establishing a shared understanding
  2. Taking action to solve the problem
  3. Establishing and maintaining team organization

Up the Y-axis, we have four categories of problem-solving:

  1. Understanding the problem
  2. Representing the problem
  3. Planning and executing
  4. Monitoring and reflecting

Within the body of the model, each square is labeled with the column number and row letter, and describes the tasks that occur in that space.

The model provides a diagnostic tool for identifying broken and lazy retrospectives. The poor engagement and weak follow-through I see in many Scrum teams is characterized by an incomplete execution of column 1 and only half-completion of columns 2 and 3 (as shown by the red outline below):

PISA 2

Teams are not spending time in “(D1) – Monitor and repairing the shared understanding,” nor are they getting to the “(C2) Enacting plans,” (D2), (D3) and (C3) areas to follow through on plans and hold each other accountable for actions and results.

What we want is a complete execution of all the collaborative problem-solving competencies; only then is the framework complete (along with the feedback mechanisms to keep things in check and moving in the right direction):

PISA 3

Summary
Innovation involves combining the right mindset and philosophy with tools and practical steps to ensure its execution. Motivation and attitude are paramount; people have got to want to do this work, enjoy it and create a pull demand for the tools and process that enable it. Trying to foster innovation with demotivated teams is like trying to push a rope.

When motivated and happy people create a strong pull demand for innovation, we need to be ready with the right tools to support the process and keep the momentum going. This includes designing experiments to maximize learning and killing bad ideas quickly—all while demanding competence, accountability and candor.

It is not easy to master the combination of soft skills and techniques required for successful improvement and innovation. However, organizations that succeed can respond to market changes faster and are poised to exploit new technologies and opportunities. Ideas and inventions are spreading quicker than ever. Learning how to build collaborative, innovative teams has become a critical skill.

References

  1. Book: Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen
  2. Article and video: “Inspection Without Adaptation Is Pointless” by Gunther Verheyen
  3. Article: “Groupthink: the Brainstorming Myth” by Jonah Lehrer
  4. Article: “The Hard Truth About Innovative Cultures” by Gary Pisano
  5. Article: “Advancing the Science of Collaborative Problem Solving” by Arthur Graesser, et al.

[Note: I first wrote this article for projectmanagement.com here]


Let’s Rewrite the PMBOK

Future PMBOK
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.

The full details of volunteer opportunities and entry requirements can be viewed at the PMI VRMS site Here.

I will be acting as Co-Lead for the initiative, which is like a co-chair role. However, Chair and Co-Chair sounds too hierarchical so we switched to Lead and Co-Lead role to match the new structures we will be embracing.

If we want to change the future of project management I believe the best way to do that is from the inside outwards by doing the work - not from the outside inwards just criticizing. Longtime readers may recall my 2010 post Raise A Little Hell when the PMBOK v5 Update was being commissioned. Since then we developed the PMI-ACP, PMBOK Agile Appendices, and the Agile Practice Guide.

This is going to be different!

Click here to see full volunteer role details.


New PM, New Choices

Choices(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.

The goals of planning, scheduling, and tracking are universal. We need to understand what work needs to be completed, determine a good way to do it, then make sure it happens while making adjustments as new information emerges. However, in the last 30 years, we have started tackling more projects with higher degrees of uncertainty and change. These characteristics help us determine if we should use traditional, predictive approaches or rely more on newer, adaptive techniques.

When our projects undertake defined, repeatable work using technologies and approaches our organizations have experience in, then uncertainty and change rates are typically low and manageable. Here, traditional project management approaches work great. It is safe and effective to use Gantt charts, detailed work breakdown structures (WBS), network diagrams and earned value analysis.

Yet when projects use new (to us) technology and tackle problems our organizations have not solved before, then risk, uncertainty, and rates of change will be high. Traditional approaches have plenty of tools for handling risks, uncertainty, and change; but modern, adaptive approaches were purpose-built for these types of projects and have proven to be effective in these circumstances.

Work Characteristics, Not Industries
It is important that we examine work characteristics, not just the industry domain we are operating in. It would be easy (and wrong) to classify all construction projects as candidates for traditional approaches, and all IT projects as needing an agile approach. Instead, there are plenty of experimental construction projects using new designs, materials and assembly approaches. Likewise, there are defined, repeatable IT projects that can (and have been) successfully managed using meticulous planning, detailed estimation, and formal change control procedures.

So we need to dig deeper and see if we are dealing with low-variability tasks or more consensus gathering and problem-solving. These work types often change depending on which phase of a project we are working on. Designing something is typically a consensus-gathering and problem-solving exercise. Here, formal planning and estimation are difficult because we don’t know what we will encounter.

Consider the process of designing a new car or home. We have a combination of creative goals (produce something new and appealing) and engineering goals (meet specifications, constraints). The process is likely to be iterative and adaptive. We are looking to build consensus between stakeholders, who include sponsors (concerned with value, schedule, quality), designers (aesthetics, features) and engineers (performance, practicality).

This design phase requires collaboration between subject matter experts and probably iteration on prototypes to confirm understanding and validate ideas. Approaches like lean, kanban and agile work well in these uncertain, high-change environments. Their tools for experimentation, rapid feedback, reprioritization, and improvement help generate consensus on designs and drive uncertainty out of models.

Then, once the design is agreed upon, the process of production is typically more defined and repeatable. Unless our car or home is using new technology, materials or assembly techniques, the process of actually turning designs into completed examples should be less uncertain and iterative so more predictive approaches to work management can be used.

Physical projects—which manipulate tangible materials like concrete, steel, and plastic—have significant production phases where predictive approaches can be employed effectively. Digital projects—which manipulate intangible data and algorithms—have no production phase since the process of turning code into executable software (the process of compiling code) is automated.

Physical Project Characteristics

So, software projects remain in the design phase—that early, upfront, uncertain period where subject matter experts are collaborating to create something that has likely not been done before.

Digital Project Characteristics
There will be many trade-offs between design goals and implementation practicality to be made. All the divergent stakeholders will have divergent goals. The sponsors want fast, cheap and high quality; the users want their work simplified and streamlined so they can focus on their goal. The development team wants interesting work using new technology and skills to further their craft.

Once we understand what work types suit predictive and adaptive approaches, we can make better sense of our projects. Having said software development is design phase focused, it’s important to understand most IT projects do more than just software development. Tasks like ordering equipment, installing hardware and training users can all benefit from predictive planning and management techniques.

A Case Study
A couple of years ago, I worked on a project to develop and install routing software for truck drivers. This combined custom software development, integration with commercial off-the-shelf (COTS) software, and hardware installation that required wiring into the truck’s engine management system and installing GPS transmitters, tablets, etc.

The custom software development was easy to plan (but not easy to do). It was new, uncertain and benefitted from an agile approach. Integrating with the COTS software was a hybrid process. We worked with the vendor to iteratively tackle the highest risk and highest business value portions first. However, being just one customer of many, the vendor did not have the availability to serve our needs as quickly as we would have liked.

We worked on a monthly delivery cadence maintaining a backlog of issues and features to tackle next. Due to previous disputes about charges, the working relationship with the vendor was quite adversarial—so detailed statements of work and a formal change control process was followed. This consumed quite a bit of time for both parties, time that could have been focussed on feature development—but that reflects the reality of many commercial projects. We have to make the best use of what we have, given the current circumstances.

Installing the equipment in the trucks demanded precision timing, OCD levels of planning and copious communications. Semi-trucks cost hundreds of thousands of dollars and are carefully scheduled to make the most of their time. Bringing them in from a wide distribution area and having them out of commission while installs are performed (and drivers trained) is an expensive exercise.

When there are several hundred trucks spread across the United States and Canada, scheduling install teams and trucks to come to install/training centers becomes a variation on the traveling salesman math problem. Minimizing the total cost of lost trucking time, travel costs and staff time is a classic traditional planning problem.

In summary, like most real-world projects, the environment was complex and required using a variety of approaches. The custom software development was in-house and under our control. We used an agile approach with team-led sprints, demos, retrospectives, adaptation etc. The integration with the third-party package software was more of a hybrid approach. There were monthly deliveries based on a backlog we prioritized, but also statements of work and formal change requests.

Finally, the hardware installs and driver training was handled in a traditional, predictive way. Schedules for installs, equipment, and labor were planned and communicated well in advance. We did adjust these plans based on findings from early installs, but traditional, waterfall-style plans have always been amenable to minor adjustments. Software updates were delivered to the trucks over-the-wire as the trucks communicated back to base, so the agile teams could get new versions distributed once the equipment was installed.  

Making Informed Choices
Assessing uncertainty and consensus-gathering needs are important factors in determining the most appropriate approach to use. Thinking first about uncertainty, well-understood, often repeated work (such as building a new Costco store) represents much less uncertainty than rare endeavors such as building an underwater hotel:

Project Uncertainty

If we add to this uncertainty view the dimension of approach focus, we arrive at a framework for assessing project approaches (shown below):

Approach Focus

The “Approach Focus” Y-axis describes if techniques (approaches) are technical, such as creating a work breakdown structure (WBS); or people-focused tasks, such as team decision making or conflict resolution.

Using this framework of project uncertainty and approach focus, we can see that traditional, predictive approaches cover the bottom left quadrant of the graph well. They are great for work we are able to define and provide good process guidance:

Traditional Approach

Agile approaches tackle the problem space from the opposite corner. They are best suited for projects with high degrees of uncertainty and offer good people-based guidance:

Agile Approach

There is a large overlap, too; it represents areas where we could use a traditional approach or an agile approach. Usually, it is recommended to use the approach the stakeholders will be most familiar with. So, if we are running with an agile team, a risk-adjusted backlog and risk burndown chart will likely be an easier sell than traditional risk management approaches. Likewise, if we are in a traditional, formal contracting environment, then statements of work and bills of materials will be accepted more readily than agile alternatives.

Summary
We can use the project environment to help determine which execution approach to use. Obviously, there will be organizational standards and guidelines to be aware of, too. However, even within traditional or agile guidelines, we can tailor our approaches based on uncertainty and task focus.

New project managers should understand that traditional project management has a wealth of process-oriented guidance for well-defined tasks. Likewise, agile offers much for uncertain, high-risk work that focuses on collaboration and people-based tasks.

We should also be aware that real projects are messy, complicated affairs. We often use a combination of approaches at macro and micro levels to try and be successful. It sounds complicated, but it forms the mastery of being a great project manager and is a journey worth pursuing.

[Note: I first wrote and published this article on ProjectManagement.com here]

 


What’s in your backlog?

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.

Backlog of Backlog Items

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.

A Backlog Primer

For agile teams, backlogs represent their To-Do list of work. All the things they need to complete before the product or project is done. Now, there may be interim releases. In fact, there should be interim releases delivering valuable functionality as soon as possible. However, there typically remains a list of remaining work. For long-lived products this list may never be emptied by the team, instead it is refreshed and reordered based on the latest priorities.

While the team works from the backlog, it is typically prioritized by a product owner / business representative / ambassador user that sequences the work. This product owner manages the backlog, keeping things up to date with the latest product decisions. They also flesh-out items prior to work starting on them. Product Owners also answers questions about the work from the team, etc.

Here’s a typical backlog showing a combination of features, change requests, bug fixes and a couple of risk reduction activities.

Backlog example

Types not Granularity

This post discusses the types of things in a backlog, not the names we give different levels of granularity. Big chunks of work might be grouped into releases and then divided into themes, or features, epics, user stories and tasks as they get smaller and smaller. There is not an agreed to hierarchy at the large end of the spectrum, often teams miss out one or two of the theme / feature / epic options. However, most teams use the user stories and tasks as work gets smaller.

Nevertheless, this post is about types of work, regardless of their size or what we call them.

Scrum Product Backlogs and Sprint Backlogs

Your view of a backlog may be different from mine. Most people I meet these days were introduced to backlogs through Scrum.

The Scrum Guide describes the product backlog as an ordered list of everything that is known to be needed in the product. It is also the single source of requirements for any changes to be made to the product. The guide goes on to describe the sprint backlog as the set of product backlog items selected for the sprint, plus a plan for delivering the product Increment and realizing the sprint goal.

My backlog history goes like this…

“It’s All Just Work We Have to Do”

I was first exposed to backlogs of work in the early 1990s. Working as a developer at Data Sciences Ltd in the UK I wrote a program to manage our work tasks on a government project. My project manager saw it one day and two interesting things happened.

  1. He did not chastise me for working on a side project of developing a visual work tracker rather than working on the client project.
  2. He asked why it did not contain all our bug fixes and change requests? I did not have a good answer, other than those are different buckets of work we should track separately. He dismissed this explanation and told me to add a flag if I wanted to track work types separately, and said “It’s all just work we have to do” and walked off, but his insight stuck with me. The class of work is secondary – all this stuff needs to get done.

My visual work tracker was quite limited and I abandoned it. The database connection from Easel (a language better suited to building graphical UIs for mainframe systems) did not support concurrent users well. Yet, a couple of years later when we started creating DSDM I knew the backlog was “Just work we have to do”. The backlog is the input-hopper for team work. The product owner is the input-hopper custodian, often subject matter expert, and settler of priority and compromise disputes / negotiations.

 

Risks in the Backlog

I have been keen on proactively addressing risks for many years. Just as features deliver value, risks in the form of threats to the project cost money and cause delays - if they occur. As such, these threats are potentials for anti-value. Like bank deposits and bank-fees, the act of adding value and avoiding losses go hand-in-hand to maximize value.

In the late 1990s I used RUP with some clients and was impressed by the Elaboration phase’s goal of tackling risks early in the project lifecycle. I corresponded with Philippe Kruchten, co-author of RUP, about how to illustrate the good work done on risk reduction during Elaboration that often did not have a lot to demo or show for it. I ended up creating Risk Burn Down graphs for my projects. I wrote about these ideas when I started blogging in 2006 as Risk Profile Graphs. By this time I’d been using them for 4-5 years and knew they were well received by sponsors and executives.

Later in 2006, I wrote about risk adjusted backlogs and Agile Risk Management explaining how to insert risk avoidance and risk reduction activities in the backlog. In 2012 I presented some Collaborative Games for Risk Management at the Agile 2012 Conference and PMI Global Conference. 

When members of the project management community read these posts and papers they correctly criticized my ignorance around proper risk management terminology. Risks, of course, can be positive (opportunities) or negative (threats). I was only talking about negative, potentially harmful risks (threats) when I talked about inserting risks based activities in the backlog. A real risk-adjusted backlog has both threat avoidance and reduction steps, as well as opportunity exploitation and opportunity enhancement actions.

This is how we got to risk avoidance and opportunity exploitation activities in the backlog.  One aims to avoid costs, the other aims to generate new value. Risk management techniques like Expected Monetary Value converts probabilistic events into financial values. For instance, if we have a 50% risk of incurring a $400,000 loss then this event’s expected monetary value is 50% x $400,000 = $200,000.

Likewise, we can assess opportunities too. If the average profit for new customers is $20,000 per annum, then we can determine if inviting qualified applicants on a factory tour with product demos and giveaways that costs us $500 per head is worth it at a 5% conversion rate. Here $20,000 x 0.05 = $1,000, so yes, it appears worth offering factory tours and giveaways for qualified leads.

Multiplying guessed benefits or losses by guessed probabilities is an inexact science. However, it is one that the insurance industry has spent centuries trying to master. So they err in their favor and often price based on what the market will bear. Yet it happens throughout all forms of business and is the basis for taking an economic view of production that underpins all the return on investment and prioritization schemes such as Weighted Shortest Job First. We are constantly looking to maximize value.

So, if a team building lunch is important for boosting performance or reducing the likelihood of conflict and delay, why not put it in the backlog? If it would be helpful for someone to walk the VP of sales through the latest product demo, put it in the backlog.

The Product Owner remains the custodian of the backlog, but with some discussions around threats and opportunities, they often see the advantages of adding these other work types to the backlog. Taking an economic view of work allows us to decide “Where is the next best dollar spent’. That may well be on Feature X or a site visit to help build relationships and increase motivation.

 

 


AI Assistants for Project Managers

Robot hand
Predictions like “AI will take our jobs” sound scary. However, long before our jobs as project managers are taken, AI will help us. In fact, it already is, and we don’t think about it much. While writing this article, AI in Microsoft Word and the add-in Grammarly helped protect you from the bulk of my spelling and grammar mistakes. This is how AI will help us first, by doing small things we are error-prone with, before tackling larger tasks.

Like me, do you spend time booking meetings, finding rooms, and distributing information? Do you analyze backlogs and scope outlines for potential risks, or review estimates for commonly missed activities? Artificial Intelligence (AI) can help with these tasks and many more.

Imagine having a non-judgemental expert monitoring everything you do (and do not do) at work and making helpful suggestions to you in private. This expert is constantly learning, is plugged into all the latest research and works for free. This is the not too distant future of AI assisted project management.

June was Technology month at Project Management.com, and there have been a few articles about AI taking away project management jobs. This article focusses on ways AI can help project managers which will happen as AI develops and before it can replace jobs. It deals with automating the process and science parts of project management, leaving people more time to focus on the relationships, leadership, storytelling, empathy and emotional intelligence side of projects that are harder to tackle and are (currently) best done by people.

AI has come a long way since Microsoft rolled out the annoying and not so helpful “Clippy” Office Assistant tool in 2003. It was never tuned for project managers, but it if were it might have looked something like this:

ClippyInstead, AI is becoming more sophisticated and useful. Gmail will remind you to attach a file if you mention “attach” in the text of an email that has no attachment. Most people use personal assistants like Siri and Cortana on their phones, or Alexa in their homes. Voice recognition and comprehension are steadily increasing. Google recently demonstrated their new Google Assistant calling and interacting with a hair salon to book a haircut. Clearly, these tools will soon be ready for prime time and their use will be widespread.

Kevin Kelly, futurist and founding executive editor of Wired magazine, says in his TED talk: “Everything that we have electrified, we are now going to cognify”. In other words, we will add intelligence to devices and products. Kelly went on to say, “I would suggest that the formula for the next 10,000 start-ups be very, very simple: take X - and add AI.

To understand how AI can help project managers, let's examine its basic capabilities.

  • Knowledge Based Expert System (KBES) – these work from decision trees of IF - THEN statements to provide expertise. Gmail’s attachment reminder works with similar IF body_text includes “attach” AND Attachment = False THEN issue a warning.
  • Artificial Neural Network (ANN) – these systems model our real brains and consist of networks of weighted connections. They can be programmed to learn, recall, generalize and apply fuzzy logic. So, if we teach it someone 4ft high is Short and someone 6ft high is Tall it can generalize that someone 4ft 6 is “Not very tall”. Being able to make these types of generalizations are important for realistic interactions with people, such as Google Assistant making a hair appointment.
  • Machine Learning – this builds on Knowledge Based Expert Systems and Artificial Neural Networks to create predictive analytics that can provide validation and advice. In the project management space, this is the technology that can help with checking for missed risks, rebaselining plans, recalculating the Cost of Delay for waiting initiatives, etc.
  • Chatbots - AI powered programs designed to simulate a conversation with humans. Chatbots use artificial neural networks and machine learning to combine domain intelligence with natural language processing. This gives the impression of interacting with a (currently somewhat) knowledgeable person.

If these technologies sound far-fetched in the project management field, consider the quote “The future is already here — it's just not very evenly distributed”. Agile tool vendor Atlassian, already provide project assistants that help with budgets, estimates, and sprint management. They also have chatbots to share project information and remind team members for estimates and status updates.

Moving forward, these tools will be expanded to help check our work for common mistakes, just as Word checks for common spelling errors. Every industry has catalogs of defect origins and removal methods (here is one for software projects) AI assistants can apply this knowledge and suggest steps to help avoid or reduce these risks. It is not an exact science and as a project manager, I may choose to dismiss potential risks flagged. However, having assistants available to highlight these risks or list the top 10 estimation omissions in my field is probably better than not having them.

AI assistants can also alert project managers to slowly developing trends that might otherwise go unnoticed. The old saying that projects become late one day at a time is very true. Optimistic project managers with “Can-do” attitudes often underestimate the impact of small setbacks and or hope that teams will “catch-up” later.  This hardly ever happens, and AI assistants can be programmed to alert early and avoid hope-based-planning.

Over-Reliance?

There is a risk that with expert knowledge systems, organizations may be tempted to use inexperienced project managers. Or project managers become reliant upon these tools and not think as deeply as they may otherwise. Like any technology, a fool with a tool is still a fool. However, tapping into standard risk lists from your industry, that gets augmented with those from previous projects in your organization is a smart move.

Having calculators has likely reduced our ability to perform long division calculations manually. However, I don’t want to go back to self-calculation just because I fear an over-reliance on technology. Instead, I want to use technology where I can and free up my time and mental capacity for other work.

Higher Value Work

The PMI Talent Triangle is a good model for thinking about all the work a project manager does. It includes: 1) Technical Project Management – the project mechanics described in the PMBOK Guide and Agile frameworks, 2) Strategic and Business Management – your industry-specific work, and 3) Leadership – the people dynamics of projects.

If we squash the triangle out and lay the pieces in order of how much impact the project manager’s contribution has towards project success we get: Technical, then Strategic, and then Leadership. By this sequence, I mean that if the basics of Technical Management are met then Strategic and Business Management work is more significant. Furthermore, good Leadership has an even greater impact on overall project performance than Strategic and Business Management Work, and Technical Project Management.

This sequence is shown below:

AI Focus

The good news for us as project managers is that (currently) AI is best suited for the lower value end of this work spectrum. It is already capable of assisting and saving us time with Technical Project Management work. Next, it should soon be commonplace to get AI assistance with Strategic and Business Management tasks. This will involve accessing machine learning focussed on our industry domains, like ROI models, common risks, and estimation omissions.

The last area AI will move into is the Leadership domain. Machine learning requires deep data sets in a consistent form to draw reliable conclusions. The people dynamics of motivation, conflict management, and negotiation are harder to classify and rank.  Currently, most people would rather work with a real person to solve issues or discover their calling. Who knows, maybe in future people will prefer to interact with chatbots who’s decision parameters can be shown to be neutral and fair. This might be preferable to dealing with people with all their inherent bias and gaps in knowledge.

All I know for now is that I currently welcome any AI assistance I can use. It is likely to safeguard me from making basic technical project management errors or omissions. It should also be helpful soon in providing industry knowledge and best practice – like having a seasoned professional in the industry available to look over your work. However, AI tools will check in real-time before you commit that decision or share a plan.

This leaves me more time to focus on the people. The people sponsoring the project, those working on it, and those who will be impacted by it. They will have their own AI assistants too. Booking meetings, getting rooms, and sharing ideas should become frictionless leaving us to work on the more significant issues.

My recommendation is to stay abreast of AI developments and remain open to trying the tools as they emerge. Standing still in an environment that is moving forward has the effect of moving backwards -which is not good. Where I should probably be more worried is in writing articles like this. It seems like a blend of domain-specific Strategic work with some Leadership based storytelling. Likely a candidate for an AI takeover long before the project manager. (My plan is to get in on the research and get a Chatbot writing this stuff for as long as I can get away with it!)

References:

  1. How AI could Revolutionize Project Management, CIO Magazine, Mary Branscome, January 12 2018
  2. 3 ways AI will change project management for the better, Atlassian Blog, April 7, 2017
  3. Artificial Intelligence in Project Management - Is Your Company Ready for it?, Teodesk Blog, Minja Belic, January 22 2018
  4. AI will Transform Project Management. Are You Ready?, PWC White paper, Marc Lahmann, et Al, 2018
  5. Artificial Intelligence in Project Management, Khaled Hamdy, March 2017

[Note: I wrote this article for ProjectManagement.com, it first appeared here – free membership required.]

 


Agile 2018 Conference – Unraveling Team Dependencies

Agile_SD2018_600x100_Speaking_FM
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.


Mining Bitcoins with Your InstantPot: Has Agile Popularity Gone Too Far?

InstantPot_Bitcoin_MachineI am excited to be presenting at next week’s PMI-SAC Professional Development Conference on May 2 in Calgary. I am looking forward to seeing old friends and meeting new people at this new format conference.

My session “Mining Bitcoins with Your InstantPot: Has Agile Popularity Gone Too Far?” examines the hype, realities and use of agile approaches.  Here is the presentation summary from the conference site:

“The project world seems to have gone agile mad. The PMI has stuffed agile into everything in an attempt to stay current, but is it right or even helpful? Fear of missing out has vendors claiming to be agile and executives asking managers to be more agile. However, like InstantPots and cryptocurrencies, does the reality live up to the hype?  This session investigates the agile trend and looks at a new breed of agile suitability filters that help organizations apply agile approaches only when and where they make sense.

The presentation profiles organizations that effectively use agile approaches and how to build PMOs that support agile, hybrid, and traditional project teams. We look at the limitations and applicability concerns of using agile approaches. It would be naïve and arrogant to believe that agile (or any other approach) is universally the best way to execute projects. So, what types of projects do suit the approach (spoiler alert: novel, knowledge-worker projects) and what types of projects should best avoid it?

We will explore hybrid approaches where certain portions or periods of the project can exploit agile approaches. In these hybrid scenarios, we examine how to coordinate and integrate the agile work with the more traditional, plan-driven work. Also, we will examine the cultural fit of agile approaches and investigate how corporate mindsets and values effect structures and decision making. Trying to force fit a new mindset that is at odds with the corporate culture will inevitably be met with resistance. So, we need to be smart about what we try to introduce and how we plan to do it.

Our end goal should be successful projects and happy stakeholders. The approach we take should be appropriate for the tasks at hand, there are no points for style or conformance, since every project is different. So, learn how to analyze the project variables that include organizational, standards, technical and team components then act intelligently within that framework also guided by the inputs of the contributors.”

That description was for a 2-hour slot proposal and I was assigned a 1-hour slot so I will have to cut some material, but I will cover the highlights. The presentation title and outline are deliberately a little controversial to hopefully spur some reaction and interest in the session.

Having been involved in the development of the recent PMI standards, I personally do not believe “PMI has stuffed agile into everything in an attempt to stay current”, however, I can see how this may appear so to external parties.

As agile rides the hype cycle it is important to retain a grasp on where it can add value and where it’s use should be limited. This session aims to strip away some of the hyperbole and ground people with some practical application tools. Please come say hello if you see me at the conference!

PMI-SAC PDC Banner