PMI Organizational Agility Presentation

PMI Organizational Agility Conference

Please join me on Thursday, September 12th for the PMI Organizational Agility Conference. This free, online event for PMI members awards viewers PDUs. I will be presenting on the topic of becoming a Change Resilient Professional.

 

As rates of change increase, building strategies and skills for adapting to change are becoming more important than ever. We will explore beyond agile models and the power of a “Yes, and…” mindset. I will be profiling the increasing pace of change and what the best organizations are doing to keep up with it, drive it forward, and future proof their employees.

 

There is a great lineup of presentations scheduled for the day. Check out the full program and register here.

OrgAgility19_792x200

 


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.


Incubating Innovation

InnovationIf success goes to those who can innovate the fastest, how do we nurture innovation? The basics are simple to understand—but difficult to implement and stick with in the face of adversity. We need to create an environment that encourages experimentation while also tolerating, investigating and learning from the inevitable failures.

It may sound easy, but executives and shareholders demand results, not “learning opportunities.” We need an approach that fosters experimentation and learning in a defendable way, with a bias for results. To innovate faster than our competitors, we need to maximize our learning potential. This means that by design, 50% of our experiments should fail since we are seeking knowledge expansion, not validation of things we already know. The trick is keeping people engaged and motivated when half of their experiment time is spent failing.

It starts with leadership and cascades down to a shared mindset of team members. Leaders need to be transparent about their own mistakes and learning moments. They need to model the desired behavior, share what they have learned and their new plan of action.

These can be strategic learnings (“Our European market testing has been poor, we are reworking the price options”) or personal (“Feedback on my presentation to investors indicated I was too technical; I need to find simpler ways to describe our technology”). Until team members see transparency in common use, they will be reluctant to practice it themselves for fear of reprisal or criticism.

We Are in the Maze-Solving Business

Maze 1
Developing new products or services is a maze-solving exercise. Nowadays, it is also a race. We need to find a workable solution faster than our competitors. There will be obstacles and dead-ends along the way, and that is okay. We must not let them demoralize us; we just need to learn from them, not repeat them, and keep going.

The process of learning starts with understanding the knowable and then adding to this through experiments and new learnings. So, we start with smart people who understand their industry domain, technology and the business goals. We then need to create an environment with a dual track of product development and experimental learning.

Organizations that run more experiments and iterate faster also learn faster. Scientists studying inheritance use mayflies because they reproduce and provide experimentation results so quickly. The more experiments you can run in a year, the more you can learn.

Our Mazes are Really Big

Maze 2

Developing a new product does not happen overnight. Outside of movies, rarely do lone geniuses develop a marketable product themselves. Instead, it takes teams of subject matter experts months to create proof-of-concepts and multiple iterations of tweaks to complete a viable product. These teams need support and coordination services throughout the process.

Sponsors, executives and shareholders need plans, projections and updates. Product managers, project managers and team leaders all play an important role in keeping the maze-solving teams motivated and moving in the right direction. They also need to keep funding and support going while providing inputs about changing market demands and conditions.

It sounds a difficult balancing act, but approaches such as design thinking, lean startup and agile provide stewardship models for development with inbuilt experimentation, observation and learning. What gets less attention is motivating teams to persevere despite the many failures encountered when experimenting for learning, not just validation.

The “Success Leads to Happiness” Fallacy
Most people start their lives with the mistaken view that success leads to happiness. Our internal dialog creates a series of “if/then” scenarios:

  • IF I pass this exam, THEN I will be happy.”
  • “IF I get this job, THEN I will be happy.”
  • “IF we finish this project on schedule, THEN I will be happy.”

However, the brain has a knack of moving the goalposts. We might be happy briefly, but then we quickly focus on the next exam, an even better job or a more ambitious project.

While it is good to progress in life, we should not connect achieving a goal with achieving happiness. Instead, we need to understand that happiness is only 10% extrinsic (external things that happen to us, like success) and 90% intrinsic (how we think and feel about things).

A Happy Brain is a Productive Brain

Dopamine

Happy workers are more productive and creative than stressed or unhappy workers. In our brains, the chemical dopamine is the neurotransmitter responsible for sending reward-motivated happiness signals. Put more simply, dopamine is a happiness chemical—it gets released when we are happy. Interestingly, dopamine also switches on more learning circuits in our brains.

Research [1,2,3] shows that happiness improves work performance. Happy people are 31% more productive, happy doctors are 19% more accurate at diagnosing correctly, and happy salespeople are 37% better at sales.

This intuitively makes sense. When we are unhappy or stressed, the brain prioritizes circuits for survival. If you spot a sabre-toothed tiger, it is probably best to focus on escape rather than contemplating the interplay of sunlight and shadows through the leaf canopy. Yet when searching for an innovative solution, we want all these extra brain circuits engaged. This brings us full circle on the “I’ll be happy when I am successful” logic. It turns out, being happy actually activates more of the brain to help us be successful.

Success Fallacy

Nurturing Happy Teams
So, if the smartest workers are happy workers, how do we make them happy? Well, we don’t “make them happy” at all—that would be trying to force it in externally, using weak extrinsic motivators. Instead, we equip them with the tools to help build intrinsic happiness themselves.

This might be sounding more touchy-feely than you are comfortable with. However, hard economics show that happy workers also persevere with problems longer, take less sick days, quit less and sue for wrongful dismissal much less, too…so let’s suspend the cynicism for a moment.

The good news is that with as little as 30 minutes a day, measurable increases in dopamine levels are achieved in three weeks. So, if we can encourage these behaviors and turn them into habits, we get happier, healthier, smarter and more productive workers.

These 30-minute exercises don’t even require expensive equipment or management consultants. They are simple, backed by research and include:

  1. 3 Gratitudes – a daily recording of three new things you are grateful for [4]
  2. Journaling – recording positive experiences from the past 24 hours [5]
  3. Exercise – increases blood flow to the brain and helps eliminate toxins [6]
  4. Meditation – resets multi-tasking fatigue and helps with concentration [7]
  5. Acts of Kindness - helping others and saying “thanks,” which makes us feel better [8]

Organizations spend vast sums of money hiring smart people and providing them with complex tools and training. In comparison, the cost/benefit potential in investing and encouraging team happiness is extremely compelling. As project managers, team leads and executives, we need to be conscious of the behaviors we model, because people are watching us.

If not already doing so, we can use these techniques ourselves to improve our own happiness and productivity—then share and encourage others to make use of them. A great benefit of intrinsic motivators is that they can be applied anywhere. It does not matter if you work in a toxic environment or report to a jerk. There is likely nothing stopping you making sure the first email of the day you send is to thank someone for their help or contribution. Also, no one will know if you make notes about positive experiences.

People with budgets and hiring authority do know that yoga instructors are much cheaper than labor relations consultants and HR lawyers. Longer lunch breaks and fun team activities may require some explanations, but improved problem solving, fewer sick days and better ideas are definitely worth it.

Don’t wait until project completion to celebrate team achievements. That’s too little, too late—and our brains have moved the goalposts to be thinking of the next project. Instead, celebrate the little things that recognize effort, persistence and displaying a good attitude.

Obviously, it is not as simple as “happy people are the perfect innovators.” There are some concerns that people characterized as “happy” might be less likely to spot certain types of risks. Optimism needs to be tempered with realism. However, given the variable success rates of helping people become happier (“leading horses to water,” etc.), there will still be some pessimists; but on the whole, it creates a positive change that is worth the risk.

Summary
Smart companies know the future belongs to the best innovators. Building and maintaining teams of productive innovators requires investment in tools, techniques and people. We need to have the right tools and be using today’s techniques such as the design thinking, lean startup and agile approaches. Then it comes down to our people. An appreciation of what truly makes us happy—and its effects on success—is a great starting point.

Most organizations are not R&D labs, so we need to balance innovation with everyday production and service. The mindset and changes described here may feel uncomfortable (or even unprofessional) at first. However, a quote from Eric Shinseki explains that “If you dislike change, you're going to dislike irrelevance even more.” It reminds us that the business landscape is changing faster than ever—and that we need to change with it to stay valuable.

References

  1. The Happiness Advantage
  2. The Benefits of Frequent Positive Affect: Does Happiness Lead to Success?
  3. Happiness and Productivity
  4. Counting Blessings Versus Burdens
  5. How Do I Love Thee? Let Me Count the Words, The Social Effects of Expressive Writing
  6. Behavior Matters
  7. One Second Ahead
  8. Interventions to Boost Happiness and Buttress Resilience

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


Review of Product Development Books

Product Development CycleNow that a software “Done” Milestone is more like a Tombstone

If you work in an industry that has digital products and services then the Product Development trend will impact you. As software becomes more critical to business operations and product offerings we are seeing that software projects do not end.

Many organizations are transitioning to become software focussed organizations that offer specialized services. Amazon is a software company with retail (and cloud) offerings. Banks are increasingly digital companies with financial services. The same with insurance, travel, music and even commercial goods. The cost of developing the software in new vehicles is now greater than the cost of the engine. It has become the single most expensive component, even in internal combustion engine vehicles with no autonomous driving features.

These websites and software services will only be “done” development when the company stops being competitive, offering new services or keeping up with technology evolution. At one time getting to "Done" on your software project was a relief, a goal, a milestone, now it is more of a tombstone. It means the product is no longer competing or actively being maintained as technology continues to evolve.

Switching from projects (that are temporary in nature) to products that are designed to be ongoing sounds easy enough - just keep funding the team, but for many organizations it is not that simple. Also, organizations that embrace the whole digital product view still need help governing the ongoing process.

This is where product development books can help. They describe the factors at play and provide ideas for guidance around planning, funding, staffing and governance. As I was working with clients experiencing the transition from projects to products I was lucky to engage with several authors of product-first, #NoProjects books and chat about the challenge areas and potential solutions.

I have written about #NoProjects a few times before:

 

Then when I recently read a third book about product development shift I thought it could be useful to review some of the books in the market. A neat aspect of these books is that they all present different views on the project to product mind-shift and journey.  

Continuous Digital

 “Continuous Digital: An agile alternative to projects for digital business

Allan Kelly, Software Strategy Ltd.; October 2018

Allan’s book was the first I read about switching to continuous product development. I had been following his blog for a number of years and was familiar with his work. However, it was not until reading the book that I saw his points laid out in order with full explanations.

It is a great read, it makes a compelling argument for why a project view of software projects is a flawed model. I loved the explanation on the diseconomies-of-scale for software and why it is actually cheaper in small batches – unlike physical goods.

It offers the best explanations I have heard into why a continuous delivery of features by a stable team is preferable to using conventional project models. It nicely describes the team aspects of knowledge work and offers some good suggestions around funding and governance models.  

Any change in mindset has to happen internally first before we can help others adopt it. Continuous Digital cemented my own thoughts about why good software projects never end. It explained the “Why?” questions at the heart of any shift in thinking and behavior. In the same way, we have to understand the agile mindset before generating any kind of commitment towards it. This book helps set the mindset and Why of #NoProjects so we can start our journey.

 

Noprojects book#noprojects: A Culture of Continuous Value

Evan Leybourn, Shane Hastie, lulu.com; July 2018

I read an early draft of Evan and Shane’s #noprojects about 6 months after I started reading Allan Kelly’s LeanPub drafts of Continuous Digital. While Kelly’s Continuous Digital and his spin-off book Project Myopia focus on explaining the Why with some How topics, #noprojects has more of a team focussed view.

It talks about the history of software development. It explains how we came to run software development with project structures and the inherent issues that came with them. It then outlines the case for continuous development with all the arguments for retaining knowledge, reducing handoff and dependences, etc.

I think it is a great follow-on from Continuous Digital. Obviously, it is designed to be a stand-alone text but, for me, Kelly explains the Why of product development better. Then #noprojects fills in some additional background information and focusses more on the team level implementation. It might just be because I read Kelly’s book first but if you are looking to convince others in your organization about the need for transitioning to product development it is the go-to source. Reading both will provide a great foundation to understand and transition from projects to products.

 

Project to ProductProject to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework

Mik Kersten,  IT Revolution Press; November 2018

I first came across Mik’s work via a podcast he did with Shane Hastie. In the podcast, Mik explained that technologies often follow 50-year cycles and then transform through a tipping point into the next evolution in the way of working.

Organizations that try to continue operating with the old model flounder and fail. Moreover, it is now about 50 years since NATO held the first conference on software engineering and the age of software began. Mik explained he believes we are at that tipping point and transitioning to product delivery will be part of the differentiator for the next wave of successful organizations.

I have an interest in technology evolution stories and learning how ideas spread and then transform our lives. So, the 50-year cycle piqued my interest and I ordered the book. The book delivers and not only does it explain the tipping point we are living through right now, but it gives the best explanation of the digital revolution and need for digital transformation I have read to date. Kudos to Mik. If you want to explain why a digital transformation is necessary, and the implications of ignoring it, Project to Product is a brilliant source.

After this great introduction, the remainder of the book explains the Flow Framework Mik helped develop and promotes through his company Tasktop Technologies. The Flow Framework provides metrics and tools for tracking and managing product development. This is useful because while the project management world has a wealth of information about tracking and managing projects, organizations that switch to product management often experience a void or competing recommendations.

The Flow Framework is useful for explaining what we should pay most attention to tracking. Namely features, defects, risks and debts. It recommends a business outcome set of measures that include: value, cost, quality and happiness. The framework employs a lean inspired set of metrics that include flow velocity, flow efficiency, flow time, and flow load.

It is in the rebranding of tradition lean metrics that I struggle to recommend the book wholeheartedly. By prefixing the normal throughput based lean metrics with the word “Flow” Mik is able to define  specific versions of the terms that are often implemented slightly differently from organization to organization. I can see the advantage of that, but it seems an unnecessary name-grab or overloading of lean terms to create trademark-able terms.

That’s a minor quibble though and what Flow Framework does provide is a good mental model for organizing, executing and tracking your product development process. It nicely extends the pattern of books started with Continuous Digital that explains Why product development. Then #noprojects that provides some team-based and stewardship elements. Finally, Project to Product provides solid How To ideas for ongoing governance and improvement.

 

Summary

These three books form a useful progression for anyone wanting to learn about the product development trend. They each provide valuable ideas to help with understanding, practicing and then managing successful product delivery.

Product Development Books Progression

The books allow readers to understand and internalize the need for a product development mindset. Then how to practice on a small scale before encouraging others to try and providing ways to measure and manage it.

Obviously, you do not need to read all three of them, or in this sequence. Any one of them is a good read and source for practical ideas. However, I found that they build nicely upon each other and thought people would be interested to consider them as complementary.


Agile 2019 Presentations

DC ConferenceI learned this week that two of my presentation submissions for the Agile 2019 conference in Washington D.C. August 6-10 have been accepted. I was very lucky to get two accepted as they received nearly 2,000 submissions for around 250 slots. It should be fun and I am really looking forward to it.

My talks will be on moving beyond agile approaches and case studies in transitioning from projects to products.  Here are the outlines:

 

The Future Looks Awesome, and Moving Beyond Agile - The Future of Agile Software Development (IEEE Software) track. The Future is Awesome

“Agile approaches succeeded and changed the way we work. They brought the philosophy and tools previously used by only the high performing teams to the majority of organizations. Now it is time to move beyond them and embrace a new wave of emerging ideas and approaches.

It is short-sighted and self-absorbed to imagine agile approaches represent the best way to execute all work types. As new technology, products, and services emerge, we need new ways to deliver them. Likewise, as organizational structures evolve to use this technology and integrate the aspirations of next-generation workers - who grew up in a digital world, our approaches much evolve again.

Fortunately, patterns are emerging from new organizational structures and the lessons from failed agile transformations. Agile’s “Family” mindset of empowerment and values-driven culture is being overtaken by “Organism” and “Community” mindset organizations embracing Holacracy and Teal Organization ideas. People are also realizing not everyone wants to adopt an agile mindset and we need better ways of integrating with more traditional models that remain that way for their own advantages. The future involves further expansion and integration, not more fervent conceptual conversion.

Come and examine the future beyond agile and hybrid agile. Explore the trends in corporate structures, career aspirations, engagement models, and the technology that is making it all possible. The future is exciting, dynamic, and decidedly less agile – but in a good way.”

It will be a fast-moving presentation recapping the rise, role, and results of agile approaches before moving onto emerging trends. Through case studies of successful organizations, we will explore new patterns in work, the worker, and the workplace.

Agile approaches play an integral role and will continue to in the future. However, they are already being augmented and extended by additional models and techniques. Using a “Yes, and…” mindset of combining approaches we examine emerging trends and what they may mean for the future of collaborative work.

 

PotholeSpeed-bumps and Potholes on the Road from Projects to Products - Experience Reports track.

“Transitioning from projects to products made perfect sense for my client. Much of the business was digital and their websites / online-services would not be “completing” or going away soon. Development was deliberately continuous, and executives embraced this as both inevitable and desirable. However, just because it was the logical thing to do, it did not mean it was easy.

Maybe if we did not have over 100 inflight projects executing simultaneously, we could have picked an easier starting time? Maybe if there were not so many dependencies between teams, work would have been easier to untangle? Maybe if they were not in the midst of transitioning to microservices and new hosting technology, the technology challenges would have been easier to resolve?

Most organizations considering the transition from projects to products have similar challenges. By definition, “transitioning” means doing things mid-process; otherwise, it would be “starting fresh with product development” – and where’s the fun in that?

This experience report recounts the story and transformation from slick PowerPoint slides to people problems and development difficulties. We did survive the journey and arrived in the land of continuous digital delivery, but we took some detours and lost some paint along the way. If you are considering the switch from projects to product development, maybe we can help you avoid some potholes and speedbumps along the road. Being forewarned is to be forearmed, but each journey is different, and as they say, your mileage will vary.”

It recounts my experience as a consultant working with the leadership team and development teams. There was general agreement that a shift to organizing around products made sense, but disagreement on the best way to get there. Rather than a big-bang changeover, we adopted a ripple-out, incremental approach. This allowed us to review and monitor for issues before spreading approaches to more teams. Naturally, the executives wanted everything done at once and the teams wanted to be left alone until after the next release.

Not being able to please everyone, we developed a workable plan and rolled out the changes to teams, technology, and supporting groups. We experienced many obstacles such as having to rewrite vendor contracts, get exceptions from accounting for budget processes and from HR for reporting changes.

More details about the Agile 2019 conference in Washington D.C. can be found on the official website.


New PM - The What?, Why?, and How? of Project Charters

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

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

Context is Crucial
First, it is critical to understand that context matters. The definition of what makes an acceptable—or great—project charter will vary from organization to organization. It will also be driven by factors such as project size, criticality, type, approach, etc.

The project charter for kicking off a safety-critical public works project will be very different than a charter for a small internal project to, say, build a tool to recover disk space used by duplicate files.

Large, critical projects will require large comprehensive charters. These can take teams of experts weeks or months to create. Small projects will likely have their three- to eight-page charter written in a day or two by the project manager. When creating (or reviewing) project charters, we need to understand this context. Ask, what is appropriate? What level of rigor and detail does this effort require and deserve?

To start the chartering process, we first need to understand a few things about the project goals and our internal processes.

  • For the project, we need to understand the business case and an outline of the desired scope.
  • For our organization, we must understand any strategic plans we need to align with, our standards and processes, contracts to use, and any relevant external factors like market conditions and industry standards.

Once we know these things, we can start writing our charter.

Make it Clear
I am a simple person and like simple ideas and definitions. I probably miss subtle nuances but have learned that most people appreciate simple, clear documents. The style points we lose for a lack of sophistication are made up for by improved comprehension and clarity. So, my definition of a project charter is a document that authorizes the project and explains the what, why, where, when, who and how aspects of the project.

We can call the whatwhywherewhenwho questions W5 and add a “+” for the final how question. Provided the project charter answers the W5+ questions and provides approval to start the project—all at the appropriate level of rigor—it’s a winner. So, let’s get started by reviewing each question…

What?
In your project charter, you will not call the section “What?” It will likely be called “Scope” or something similar. The “W5+” idea is just a tool to make sure we address the important sections. So, in the scope section, we would describe or list the major deliverables or high-level functionality the project should deliver. People need to understand what we are talking about before they can appreciate further details such as schedule and approach.

When defining what the project will deliver, it is also useful to state what it will not deliver. So, a list of “out of scope” items is also valuable. It is better to have sponsors or user representatives complain now rather than halfway through the project (or worse, at completion when there is nothing we can do about it) that their anticipated element will not be delivered.

Why?
The why of a project is described in a “Problem Statement” or “Business Need” section. Some people put this section before the what. That is fine; follow your organization’s standard, or the preferred sequence of who approves project charters (or failing those, your own preference). Just make sure the what and the why are addressed early on.

People need to understand why this project is important. What new revenue will it bring? What problem or legal requirement does it serve? What new opportunities, new products or new customers do we hope it will attract? Projects are expensive and risky endeavors, so we better have a good reason to undertake one. The business case or problem statement is where we describe it.

It needs to be clear and compelling. It may reference a separate business case or return on investment analysis. If these components are necessary and not in separate documents, include a summary in the charter body and put the details in an appendix. We don’t want people to stop reading our project charter because they came across pages of calculations.

Where?
“Where?” can seem a strange question, maybe inserted just to get the “W” count up to five. However, think broader. Which markets, products, and departments are we impacting? Where is the project going to touch our organization, customer base, and market segment?

Remember: The project charter normally provides approval for a project to start. We need to provide the relevant context so people are thinking appropriately before they approve, reject or request changes be made.

This information may be contained in a section called “Organizational Impact” or form a sub-section of the scope section. It also explains how the project is aligned with the organization’s strategic plan.

When?
This is where we describe the “Project schedule”—not only when we plan to start and (hopefully) complete the project, but also major steps along the way.

Being a project manager writing a charter, it’s easy to get caught up in the apparent importance of your project. You might assume that once approved, the organization will rush full-steam ahead into kickoff and execution. We need to inject some caution and realism. What seems important and obvious to us is often low priority for the sponsors or those already over capacity in executing existing projects and operations. Things might take a while to get going.

So, do not build a schedule based on starting work immediately after approval. That just sets everyone up for failure. The most common source of late project completions is not poor estimating or a lack of risk management, it is late starts. Every late project I have reviewed had a late start. They may also have been terrible at estimating and blind to common threats, but late starts are very common. We need to explain that real end dates are driven by real start dates.

Projects get delayed for a host of common reasons. We were delayed in getting our team, we were delayed in finding a space, we were delayed in accessing funds. So, do yourself (and everybody else) a favor and explain that the project will likely take three weeks, months or years from having the requisite start conditions.

We also need to be realistic about uncertainty. The uncertainty associated with our estimates needs to be reflected (to some degree) in our schedule. It is probably not acceptable to say, “We have no clue when we will be done.” But do not commit to completing within a certain timeframe unless you have a realistic and robust plan for achieving that.

Robust means including contingency to address uncertainty. Be open about it, such as, “We included a 15% buffer for unanticipated work.” You might get asked to remove it and “work smarter” or “find a way, damn it!” and that is fine. You reflected the uncertainty inherent with the work. Depending how supportive the sponsors are, we could consider explaining that removing contingency is accepting the risk of an overrun due to learning in the future things that we do not know today.

Plans and estimates created at the beginning of the project are, by definition, the least reliable because that is when we know the least about the project. It is only when we begin to execute that we learn about its true complexity and the actual abilities of the team, vendors and supporting groups. Sponsors usually don’t want to hear this kind of smartass insolence from the project managers. PMs are hired to deliver projects, not tell them how to set stretch goals or run a business.

There are other ways to shorten a schedule. We can cut the scope of what is delivered. This could allow us to hit a deadline and maybe have a follow-on release for lower-priority work. It is not ideal and is really wriggling out of the defined scope. However, for software products, where must-have and nice-to-have features are more fluid, it could be a viable option.

We can also add more people to the project. This works great if you are undertaking simple work like digging ditches or building pyramids. For anything more complex that involves problem-solving, idea sharing and collaboration, books like The Mythical Man-Month explain that adding people to a project that is late will make it later (while spending more, too).

For these reasons (and others learned the hard way), make sure schedules clearly contain contingency to reflect uncertainties. Also, ensure that schedules work from a project start date that is contingent upon having prerequisite project conditions in place. Yes, they might both get ignored, but it is the responsible thing to do—and you can bring them up at steering committee meetings when asked why the project is behind.

Who?
The who question represents the “Team” and “Stakeholder” sections of a project charter. It is normal to show org charts of core project roles and list known team members and open positions. RACI charts can be used to list who is responsible, accountable, consulted and informed (RACI) for work and deliverables.

We should understand that the term stakeholder encompasses not only the people working on the project and sponsoring it, but also everyone it will impact. This extended family of project influencers include suppliers, customers, and even the general public if the project is likely to draw public opinion. Obviously, we do not list these broader communities by name, but we should identify them and assign a contact within the project for managing that group.

The PMI definition of a stakeholder includes not only those impacted by the project, but even those who perceive they may be impacted by the project. This is important—the scope of people who may influence development is wide. It is better to have a plan for engaging or at least monitoring these groups (be them environmental, minority or special interest) before they can blindside the project. Inventing a fire-response plan is always easier to do before you also have a fire on your hands.

How?
The how question reminds us to explain the “Project Approach.” We should describe how the project will be executed. Will we be following the standard corporate project lifecycle? Are we trying a new approach? Are we outsourcing portions?

People need to understand how the project will be executed before agreeing to fund it or participate in it. If they think the project has merit but we are suggesting to go about it all wrong, they will want the ability to influence the approach used.

When we are following a standard approach, it is sufficient to just name it. When we are proposing something different, we need to describe it in more detail. This could be a reference to another document or pointer to an appendix in our project charter.

Approval
The charter describes the project from a holistic perspective by addressing the W5+ questions; it also provides the approval/authorization to start work. In most organizations, approval of the charter triggers a request for funds or authorization for expenditure (AFE). For this reason, we need some formality around the approval and sign-off of the charter. It is normal to have a signature section for sponsor, division leads and other steering committee members.

The approval circumstances are rarely as simple as either approved or not approved. It is usual to have definitions of the various options that the steering committee may use. Common status options include:

Approve – Looks good, let’s get started
Approve with modifications – Will be okay if you make these changes (provide some space in the signature area to hand-write requested changes and then get signatures)
Request changes – Major changes are required and a new charter will need to be submitted
Defer – Not at this time, keep on hold
Reject – No, do not proceed

What about agile projects that do not have charters?
Today’s agile projects produce fewer documents. However, since charters often authorize work to start and trigger the release of funds, we still sometimes see them used in hybrid traditional/agile environments. If project charters are not used in name, typically a lighter-weight deliverable with a different name is used.

We might see an Agile CharterProject Skinny or Product Canvas. The purpose is similar—describe the endeavor and get agreement to start. When working with agile approaches, we can still use the W5+ idea to make sure we address the common viewpoints. The coverage in each section will likely be brief, but is still helpful.

Summary
Consider the context you are working in. Organizational standards and project characteristics such as size, cost, and impact of failure will dictate the level of detail and rigor that will be necessary. Then keep the sections simple and clear. Use appendices or references to external documents if sections become too long. We want people to be able to read the core body of our charter through in one sitting and then make a decision to approve it.

Make sure the sections address the W5+ views of the project one topic at a time. For instance, do not mix schedule with business justification; keep them separate. Do not paint yourself into a corner by committing to unrealistic delivery dates or optimistic costs. Present what you believe is realistic and let the steering committee assume the risks of reduction (if possible).

Recommending a template is problematic since organizational needs vary, but common sections for a small- to medium-sized project might contain:

  • Introduction – Explain the purpose of the charter
  • Problem Statement – Outline the what
  • Scope Outline – More detail on what would be delivered
  • Definition of Success – Define what “done” would look like
  • Risk Summary – Review the high-level threats and opportunities identified
  • Constraints and Assumptions – Outline the accepted operating parameters used
  • Business Case – Explain why the organization should do this
  • Schedule – Explain when the project will be completed
  • Deliverables Schedule – Outline when the key deliverables will be completed
  • Budget – Explain how much this is likely to cost
  • Team Structure – Outline who will be working on the project     
  • Organizational Structure – Explain who will be responsible for oversight and direction
  • Project Approach – Explain how the project will be run
  • Steering Committee Decision – Record the approval (or otherwise) of the charter
  • Appendices
    1. Project Background – Supporting material about why this is a good thing to do
    2. Deliverables List – A list of what should be delivered and what Done looks like for each
    3. Deliverables Schedule – A schedule for the deliverables’ leave some wiggle room
    4. Risk Assessment Detail – Details of the threats and opportunities analyzed to date
    5. Communication Plan – Details of how people will be kept informed about progress and issues

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


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]

 


Volunteering: Giving Back That Feels Like Taking

Volunteer 2Volunteering with PMI has many benefits. Not only does it feel good to be giving back to the profession that supports us, but whenever I do it, I learn something new and build useful connections with fellow project practitioners. Add to this the fact you also earn PDUs makes the whole process a win, win, win.

Project management can feel a solitary activity sometimes. Even if you work with large teams and in organizations with many project managers, the unique nature of projects means PMs often have less in common with their peers than other roles.

In a work setting, not all PMs are willing to share their best approaches or secret sauce. Perhaps they feel competition as if their jobs could be replaced if they openly shared what worked for them. There is no such nonsense when interacting with other volunteers. You are automatically in a self-selecting group who have put a higher cause ahead of their sense of self-worth or importance.

I have come to discover that people who seem guarded with advice typically have little to protect, while those who are generous with their experience know the most and prosper more as they educate others. Knowledge and experience are not finite resources to be hoarded; instead, they become more valuable as you share them.

Over the years of volunteering with PMI, I have met many great industry leaders like “Risk Doctor” David Hillson and PMO guru Jack Duggal. They have been generous mentors, and I often learn more in a 10-minute coffee break than days of training or reading. Generally, the quality of people you meet when volunteering is exceptionally high, because they are doing it for intrinsic reasons, not for pay or recognition. It’s the perfect environment or qualifier to find generous, knowledgeable people to network with. By definition of them being there, they are willing and happy to help others.

I have been in the industry long enough now to have people ask me how I got started. I have been asked how I became involved in agile approaches, or a SeminarsWorld instructor, or worked on PMI standards. The answer to each and every one is that I volunteered for something. That led to me meeting some people and then volunteering on something else. Every industry achievement I have I can trace directly to volunteer activities and volunteer contacts.

I half considered keeping this career secret to myself—the fact that the best method for professional development is free and available to everyone. Yet, that would be so anti-volunteerism that I could not.  The fact is, of course, that only people truly in love with project management want to volunteer long term.

Let’s be clear: It is not all rainbows and unicorns. There may be lots of stacking chairs, waiting around and unproductive administrivia—it is not always about discussing the “next big thing.” Also, the payoffs are random in frequency and nature. The odds of meeting your next hiring manager on a conference call or in-person meeting are very slim. Yet, like many things, there is power in showing up—and luck only favors participants.

The good news is that effort and goodwill seem cumulative; who knows when and where something useful will show up. In the meantime, you are doing something useful and even getting PDUs for your time.

There are many ways to volunteer. I used to help at local dinner meetings, but after moving far out of town I find virtual and full-day events easier to participate in. Your local chapter and the PMI.org website have many volunteer opportunities.

One thing I wish I had realized earlier is that you do not have to be an expert—or even experienced on a topic—to take part or be valued. Unlike a work setting (where you are payed a salary and so expected to largely know what to do), volunteering is great for the inexperienced. People are just glad you are there; and in fact, you get most out of working in new areas since most topics come with a free education and you have a bunch of generous individuals around to explain things.

For years, PMI have used the slogan “Good things happen when you get involved”—and it is so true. If you are looking for professional development opportunities for 2019, I strongly suggest you consider volunteering. I acknowledge the gushy nature of this write-up might suggest some insider prompting from PMI to drum up more volunteers; however, this is personal and heartfelt.

As I reflect on 2018, looking at what went well and what not so well, I see an undeniable correlation. This year, like the last 10, my most rewarding work and business connections came out of volunteering. Heck…maybe I am just terrible at capitalizing on regular work (I do have a history of buying high and selling low at most things), but the things that go well seem volunteer related. Confirmation bias? Maybe. But if you have not volunteered before, give it a try…it’s free, and did I mention you get PDUs?

I don’t think this is just me. If anyone else has experienced similar serendipitous benefits from volunteering (at PMI or anywhere else), please share in the comments below.

[This post first appeared on ProjectManagement.com here]

 


Focusing on Results, Not Agile Approaches

Focus on Business Value


Quarter Century

25 Years Agile2019 marks the 25 year anniversary of Scrum and DSDM. I was involved in the creation of DSDM in 1994 and was an early adopter of Scrum and FDD shortly afterward. Now, having been at this for a quarter of a century I am reflecting on where my journey has taken me compared to others.

I am agnostic about agile. I value the mindset and goals more than approaches that preach a single path. This has had mixed blessings for me. I remain agnostic and impartial, but I have not jumped on any of the approach bandwagons.

I received more training in Scrum by Ken Schwaber in 2002 and offered a training role (before they were called CSTs)  but I have never offered Certified Scrum Master training. I would feel wrong evangelizing the singular view of Scrum as the way, or role of the Scrum Master to spread Scrum. That feels too religious to me.

Don’t get me wrong, I think Scrum is an OK starting place, but I would not recommend only using a Scrum approach - since approaches like Lean, Kanban and FDD have great things to contribute too. Some Scrum practitioners correctly explain that Scrum does not say you cannot add other approaches. In fact, it can be viewed as a deliberately incomplete framework, so organizations have to add their own process to make it successful. Yet this message is undersold as I visit organization after organization that only use Scrum practices with maybe some XP engineering practices. They are missing out on so much more and struggling because of it.

The Scrum community often has a myopic focus blaming implementation struggles on a failure to understand or apply Scrum properly - when maybe something outside of Scrum would better suit the situation.

Likewise, I think SAFe does a great job of packaging and presenting some good ideas for organizations to consider - but its adoption draws too much effort away from developing valuable product. By all means, raid SAFe for valuable content and ideas, but create your own approach with the bare minimum of process. Then continue to ditch that process as soon as it is no longer worth the effort.

 

Take Off

Agile TakeoffIn the 25 years I have been using agile approaches, I have seen companies like LeadingAgile and LitheSpeed form, grow and prosper. They offer Scrum and SAFe training even though they are also agnostic and understand the benefits of various approaches.

I have thought about just sucking it up, drinking the cool aid and offering these courses. I could also explain there is nothing to stop us blending other approaches too. However, then its not really Scrum or SAFe, or whatever I am peddling so it is not a genuine message, which is important for me.

I offer my own training courses in agnostic agile, focussing on the philosophy and tools available for a variety of circumstances. However, like trying to market a healthy, balanced diet, I am first to acknowledge the message lacks the clarity, simplicity or sex-appeal of a single, silver-bullet solution.

People want a “Paleo”, or “South Beach”, or “Atkins”, “Mediterranean”, “Keto”, “Raw”, or “<Whatever>” solution to follow. I can yell, “Stop being lazy sheep and think for yourself”, but the majority of people want recipes and ready-meals, not to learn nutrition and cooking skills.

 

 

Benefits, not Popular Fads / Staying On Track

Staying On TrackThat is OK, I would rather be genuine than popular. I truly believe we are most successful when agnostically taking the most suitable approaches for our circumstances. Then, ruthlessly reviewing, morphing and pruning these approaches as our teams evolve.

We need to focus on the output, the business value, not the process. If wearing purple hats produced better results than agile then I would be all for purple hats and ditching agile. This is one reason I named my company as LeadingAnswers and not a name with the word “Agile” in it. I am focussed on solutions and outcomes, not a single approach. I still believe Agile is our best starting point, but I am always hopeful we will create something better.

As 2019 starts, I am doubling down on my “Yes, and…” commitment. I realize the message lacks the clarity of a single, sexy, (sub-optimal) solution and so it will never be widely adopted. However, my last 25 years has taught me that there are enough people who see the benefit of a balanced, evolving approach.

So, I hope you stick with me as I explore being successful by focussing on delivering business value regardless of approach. I think there is merit in traditional processes in the right circumstances. There are also many underemployed benefits from leadership, emotional intelligence, and industry specific practices that get used in pockets that we could all learn from.

Here’s to another 25 years of delivering the most business value we can through situationally specific approaches.


DIPMF 2018

Dubai SkylineI have just returned from the 2018 Dubai International Project Management Forum (DIPMF). It was my second year presenting there and this year I hosted a session called “Agile: Not New, but Now Necessary”. It traced several techniques back through history and explained how lean, agile, and design thinking approaches share common guidance for building high performing teams.

During the conference, I mainly attended the agile and artificial intelligence (AI) sessions. Having written about AI augmented project management previously I was interested to learn more about Microsoft’s PMOtto assistant that uses Azure Machine Learning Studio. PMOtto has a chat-bot interface that uses their LUIS (Language Understanding) machine learning based natural language system to understand questions. It integrates with Office 365 tools, a cognitive services model for learning about projects, and business intelligence tools for analysis. Like having a project assistant who is always getting smarter, PMOtto will track, trend, and answer questions for project managers and PMOs.

TED speaker and child prodigy Tanmay Bakshi gave an inspiring keynote on AI. His main theme was it is more like Augmented Intelligence rather than true Artificial Intelligence. He profiled some of his work including helping those with Rett Syndrome "speak" through the detection and interpretation of EEG signals analyzed by cognitive systems.

PMI’s Murat Bicak, senior VP strategy, also gave an interesting talk on AI as Augmented Intelligence. He profiled some AI generated artwork that used machine learning to identify pleasing images. Interestingly, when control groups were asked to try and identify images as either human generated or computer generated, people rated the computer-generated images as human 75% of the time compared to human-generated art only 48% of the time.

There were also great keynotes by Yancey Strickler, co-founder of Kickstarter on building socially responsible companies and Lisa Bodell, founder of Futurethink on why simplicity wins.

The whole event was really well hosted and it was great to see a massive display wall featuring a Project Management History Timeline. It showed PM developments and local Dubai mega-projects since 1917 from the Gantt chart all the way up to the present. The early years showed the creation of the Critical Path Method, the building of the Dubai airport, formation of the PMI, and creation of the PMP certification.

Timeline 00

The middle years celebrate events like building of the world’s tallest tower, the Burj Khalifa, and breaking ground on the world’s largest solar energy facility. The chart seemingly culminates in the grand finale, the Agile Practice Guide. Having worked on the guide with many other people, it was great to see it profiled. It was a fantastic conference and I hope to be invited again next year.

Timeline 2


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.

 

 


Certification Proliferation and Confusion

Cert ProliferationLike TV channels, the choice of project management credentials has exploded recently. 20 years ago things were much simpler, in North America, the PMP was the dominant credential, in the UK and ex British Empire countries it was PRINCE2. Life was straightforward, career paths defined, and credentials well understood.

In 1983 in the US, over 100M people watched the finale of the TV series M.A.S.H. Outside of the Apollo moon landing and sports events, it remains the most watched US TV broadcast of all time. Chances were most people in the office watched it and everyone had something in common to talk about. That was Peak TV, viewer counts have increased since but program choice has exploded much faster. These days there are so many cable choices, on-demand services, YouTube channels, and Periscope sub-streams it seems as if everyone watches something different.

Likewise, project management credentials have proliferated too. Today I discovered 7 different credentials for PMO staff from the same provider. Each (presumably) providing some niche specialization or incremental progression from a former step. Don’t even get me started on Agile certifications which have splintered and multiplied faster than the brooms in Fantasia’s Sorcerer’s Apprentice.

This creates problems for project management professionals and hiring managers alike. How can they compare or rank one over another? Within the PMI community, people know the CAPM® is a foundational credential and the PfMP® is more advanced. However, outside the PMI the situation is complex and rapidly evolving.

Becoming a Certified Scrum Master might sound impressive, but for many people, it merely required attending a two-day class. Yet, at the other end of the spectrum, the Association for Cost Engineers (ACostE) requires degrees or over 30,000 hours of experience (3 times Gladwell’s 10,000 hours guide). This is more like a career quest, rather than a 2018 learning aspiration. 

This diversity in experience requirements and study effort along with frequent new offerings muddies the waters of comparison. It would be negligent to simply ignore new offerings since many have been created to fill real needs.

Instead hiring managers likely use unknown credentials as a demonstration of lifelong learning and career change motivation. They may not know exactly what they entail, but for promising candidates, a few minutes on Google should shed light on the credential requirements and process. Unfortunately with the rise of automated and AI-assisted recruitment workflows these candidates might not make the initial selection due to keyword filtering.

If someone was a little sneaky I guess they could state on their resume that their New_Credential_ABC was similar to a PRINCE2 Practitioner, PMP®, or another credential so they pass the keyword scan. Yet, if you were so inclined, you might as well have a section called Future Credentials Planned and list them all along with your Nobel Prize.

It is unlikely TV channels or credentials will ever converge back into a simple collection of universally understood offerings. People want choice and specialization.

If the future of recruiting really will be AI driven maybe a service that ranks, validates and checks credentials will be created to remove the need for hiring managers to do so? It could be constantly updated and evaluated by independent experts to ensure parity. In the meantime, if you have a niche credential or are considering pursuing one, be aware its lack of recognition could be a factor.

Ideally, credentials are just an entry point, beyond which experience and character fit are evaluated. Hiring managers should look for a baseline proficiency but then focus the bulk of their decisions on soft skills evaluated through interviews, etc. We could say it is like making sure candidates have a driver’s license if a job requires driving, it is a prerequisite. Yet we know hiring managers attribute more credence than this.

It is because of this proliferation of credentials and the encouragement to renew and expand that some people are opposed to them. They believe they are money-making schemes for the owners and not reflections of ability or experience. I sympathize to some degree, as stated, at best they are entry points, like drivers licenses, that demonstrate a base level of competence. Yet they are used by hiring managers to qualify candidates. It seems if you are looking to change jobs they are, to some degree, a necessary expense.

For other people, credentials are pursued for personal reasons. Maybe to encourage ongoing development or for differentiation among peers without changing jobs. The list of motivations for pursuing credentials is likely as diverse as the credentials themselves.

More choice is great - until it isn’t. When options and complexity overwhelm our decision-making process we need new tools. Luckily we can learn from other arenas that have complexity. The internet has not unified and standardized the choice of news, entertainment, or services. It has done the opposite and created more choice, enclaves, silos, and choices than ever before.

Fortunately, the internet also comes with tools to search, sort and rank to help us navigate all the diversity.  We need the same with certifications. As television and films proliferated sites like IMDB, RottenTomatoes, Fandango, and Metacritic were created to add smarts and help us choose. Built around expert and personal ratings these sites allow people to sort, filter and view aggregate scores.

Hopefully, we will see the same with certifications. Hiring managers and people looking for the next credential to consider will have tools to help them choose. Whereas films and TV shows are filtered by genre (action, adventure, drama), actors and viewer age recommendations, certifications will have different criteria. Categories such as topics covered, experience requirements, and assessment method are some basic measures. Beyond that user-provided data on market awareness, average study effort, typical salary bands, etc. could be added.

Just as we will not be reverting to only 3 or 4 TV channels again, we cannot expect the diversity in credentials to disappear. Unpopular ones will fail, but more choice seems to be the future. Fortunately, the solutions for managing complexity and too many choices have been modeled in other domains.

Currently searching for “Best PM credentials/certificates/qualifications” yields lots of articles, but no community-sourced tools. That’s likely the future and maybe a project for one of our readers?

 

References:

  1. UK Project Management Market Snapshot, October 2018 – Arras
  2. Wikipedia: List of most-watched television broadcasts, Retrieved October 2018
  3. Project Management Certification Benchmarking Research: 2015 Update - Dr. Paul D. Giammalvo

 

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


GOAT18

Shaw-center_0I am excited to be a keynote speaker at the Gatineau-Ottawa Agile Tour (GOAT) conference on November 30th. Along with Mary Poppendieck, we will be leading a day dedicated to learning about agile culture and collaboration.

The Gatineau Ottawa Agile Tour is an annual conference in the heart of the nation’s capital, focused on sharing and learning. GOAT has run for 7 years and is part of the Agile Tour that takes place in 90 cities worldwide.

Click to see the Keynotes Overview and the Sessions Previews.

I hope to see you there.


Hybrid Knowledge: Expansion and Contraction

Knowledge Expansion and ConsolidationExpansion and Contraction

Project management requires the combination of technical skills, people skills and industry-specific knowledge. It is a true hybrid environment. This knowledge and its application also forms a beautiful paradox. Our quest to gain skills is never complete and always expanding, but the most effective tools are usually the simplest. Smart people do very simple things to achieve desired outcomes. Yet, they probably considered fifty alternatives before choosing the most effective, simple approach. You must know a lot to be confident your choice is apt.

Knowledge and experience in project management follows the same pattern. Learning about project management, how to work effectively with people, and our industry domain is never complete. We then use this knowledge to choose the best action, which for ease of understanding and implementation, is usually a simple course of action. I call it Expansion and Contraction, but there is probably a simpler name I will learn about one day.

Learning as a Project Manager

One of the things I love about project management is the opportunity to expand our knowledge. There is so much to learn that is useful and applicable to projects. We also live in an age where there are more avenues for learning than ever before. Like a hungry kid in a candy store, the options seem endless and enticing.

But what should we learn next to make the biggest impact? We could learn techniques to make us more effective or alert us to risks earlier. While earned-value is widely used, earned-scheduling is just getting started but promises useful tools. Alternatively, we will never be done learning how to better work with people. Communication, collaboration and motivation skills are more important than ever now talent is so mobile.  Likewise, expanding our industry and business skills are critical to build credibility with sponsors and useful collaborations with teams.

The PMI Talent Triangle nicely describes these connected but infinitely extending fields of study.

Talent triangle tm

For learning purposes, the Strategic and Business Management segment includes all aspects of your industry. For example, if you work in IT, learning anything your team does or uses would be valuable.

Hybrid Learning Model

We should study topics from each of the Talent Triangle segments. However, it needs be fun to be sustainable. We learn best when we are interested and engaged, not when trying really hard to stay on topic or complete a task. Learning also needs to be balanced with other aspects of our lives. We need to look after ourselves and our relationships. We won’t perform or learn well if sick, depressed or lonely. (See the Project You post for more on this idea.)

When we get stuck, tired or burnt-out on one topic, switch to another after recording what is challenging. Our brains process things in the background. Often the simple act of recording that we are stuck on a topic yields an A-ha breakthrough days later in the shower or out on a walk. 

In addition to a stuck list, recognize all the things already studied. The following Kanban board has columns for To Learn, Studying Now, Stuck On, and Studied Already.

Learning Board

Personally, I try to limit my studying to one topic per Talent Triangle segment at a time. That’s my mental capacity, but I might mix in some short articles alongside a book on a similar topic.

Line Chefs not Eggheads

Knowledge is only useful if we can apply it when necessary. We want people who are humble and smart with a bias for action. When presented with a problem, recalling potential fixes is only half the solution. We then have to select one and try it otherwise we have analysis paralysis. The selection might be done individually or through discussions with the team, but we need to go from many options to a preferred one.

Many people find having too many options with no clear preference overwhelming. Kicking around alternatives is good to select the best solution, but be aware of the anxiety this can cause. So keep it short. Power comes from agreeing and focussing effort on the selected approach. A 40 watt light bulb is barely enough to light a room. Yet a 40-watt laser beam will cut through cardboard and aluminum. It’s the same amount of light energy, just focussed in one direction.

For me, there is an analogy or parallel between learning multiple skills and navigating. Once we know our way around we can create new pathways and connections. I live near the Canmore Nordic Centre. It has> 100km of cross-country ski trails tightly winding through a heavily treed, mountainous park. It also has > 100 km of summer mountain biking trails in the same space.

People describe the trail network and map as confusing as a plate of spaghetti (summer trails) dumped on top of another plate of spaghetti (winter trails). It took me a couple of years of frequently getting lost to become comfortable navigating there. Now knowing both sets of trails allows me to create new loops by tagging trail segments together. It also allows me to get from point A to point B quickly or get back to the Day Lodge swiftly if needed. In short, learning where all the connections are allows us to link elements together for better flow and shortcuts.

Learning as much as we can about project management, emotional intelligence and leadership builds similar skills. It allows us to see connections between ideas, link concepts together like creating a common vision for a project through storytelling.  Or, resolve conflict with empathy and appreciative inquiry.

If we can layer these skills with learning more about our industry, then in the eyes of our sponsors, we go from effective employees to trusted advisors.

When We Get it Wrong

This is all great in theory, but we will inevitably screw-up sometimes. We will assess the options and gallantly blaze our way forward into bigger problems and unintended consequences. This is when being humble and flexible pay dividends.

Just as a lack of direction in the face of uncertainty looks like fear or paralysis, then dogged adherence to a doomed plan looks like blind stupidity. By carefully framing decisions with qualifiers such as “Right now, our best course of action looks like X” or “We have decided to try Y for an iteration and evaluate the results” this way we reserve the right to be smarter tomorrow than we were yesterday.

People are more likely to forgive a mistake and try another approach when it was originally positioned as today’s favoured strategy rather than our only hope. This is not to say we should get into the habit of failing and flip-flopping, just be smart enough not to get preachy about decisions in case the occasional one turns out to be a dud.

So, strive for clarity with options to change direction if needed. We can explain: Here is what we are going to do... but, if along the way we learn of a better approach we reserve the right to revaluate and change direction. In fact, we have a duty to our sponsors to change direction if there ever looks like a better option.

Summary

If we cast the net wide and learn all that we can about project management, leadership and our industries we will never be bored or lacking topics to explore. The beauty comes when topics connect and we make links between subjects. Like always wondering where that unfamiliar road goes only to emerge from it one day and suddenly realize where you are and make the new mental connection.

As we grow in our careers we see how management is really about leadership and leadership really starts with ourselves. Then a simple shift over here makes things go better over there. Project success is a hybrid of technical, leadership and strategic domains. As we grow we see more connections and then achieve more through doing less. It is great when it works but still uncomfortable when it fails so, follow the advice of Patrick Lencioni, and stay humble, hungry and smart.

 

[Note: I wrote this article for ProjectManagament.com first and it can be found here - membership required ]

 


The New Need to be Lifelong Learners

Never Stop LearningWe are a generation who stand with one foot in the outgoing industrial era and one in the knowledge-based future. Training and education that prepared us well for careers in the past will not work in a faster-moving future. Now, we need to be not just lifelong learners, but engaged, active lifelong learners.

The move from industrial work to knowledge-based or learning work can be difficult to see because change does not happen uniformly. Instead, some organizations push ahead, while others lag behind. However, all industries are changing and terms like “Retail Apocalypse” are invented to describe the trend in just one sector.

Some product companies have learned to generate revenue from digital services while many traditional models are disappearing. While I drafted this article gadget store Brookstone declared bankruptcy and Apple became the world’s first publicly traded trillion-dollar company, with Amazon close on its heels. Each are landmarks along the road to a different future and world of work.

People have been through similar transitions before. The Agricultural Revolution moved nomadic hunter-gathers to farmers. They no longer had to wander around in search of food and allowed for permanent, full-time settlements which changed humanity. I am sure there were many people who rejected the new way of working and elected to live out the remainder of their lives as nomadic hunter-gathers. However, the general population reached a tipping point and changed.

Then came the industrial revolution. Many of the dispersed farmers moved to cities to work in factories. Again, a huge change that did not happen overnight, or around the world at the same time. There were some people left farming, but most transitioned. The next stage was known as the Information Revolution. This revolution focused on information and collaboration, rather than manufacturing. It placed value on the ownership of knowledge and the ability to use that knowledge to create or improve goods and services.

We now live in an era dubbed the Learning Age by Jacob Morgan, author of “The Future of Work”. New technologies are evolving so rapidly that company training departments cannot provide all the skills their employees needed to perform their job in an effective manner. Instead, with the rise of internet-based information and learning, workers have the skills to learn as they go. Capacity to learn and a willingness to self-study are the hallmarks of learning workers.

 


MindsetA New Mindset

Becoming an active lifelong learner requires more than just a willingness to self-study. It is linked to a totally new mindset and values structure. Susan Cain, author of Quiet (and presenter of my favorite TED talk with no slides,) explains how each work era brought a new value mindset.

The Agricultural work period valued character and hard work. Role models included Abraham Lincoln and self-help books had titles like “Character, the greatest thing in the world”. Then, the Industrial Revolution moved people from small communities into cities, so they now had to be heard and prove themselves in a crowd of strangers. Qualities like magnetism and charisma became important and self-help books had titles like “How to Win Friends and Influence People”. In the Industrial era role models were great salespeople.

Today knowledge, learning, and experimentation are rewarded. The goal is to quickly test new ideas or products and then profit (if it works), or pivot to something else if it does not. Books like “The Lean Startup” and “Blue Ocean Strategy” have become the new how-to guides for people wanting to innovate. In demand skills are less sales or personality focused and more experimentation oriented. Today’s role models are engineers - who would have thought!

 

FutureThe Future of Work and Learning

Futurist Magnus Lindkvist explains there are only two types of development: horizontal and vertical. Horizontal development involves spreading existing ideas to everyone else. 30 years ago, only a few people had cell phones, now most people in developed countries have them. 20 years ago, online shopping was a small segment of sales, now it is huge. 10 years ago, ride-share and gig-economy jobs were rare, now they are commonplace, etc.

There is a lot of opportunity and work for people spreading ideas horizontally to markets or segments that currently do not have them. According to McKinsey research, more than half the world’s population is still offline. About 75 percent of the offline population is concentrated in 20 countries and is disproportionately rural, low income, elderly, illiterate, and female. This is an example of horizontal growth potential to these 4 billion people currently offline. However, once a market is served the challenge then becomes one of differentiation on price, features, and service. Things get competitive very quickly.

The other sort of development is vertical, creating new markets and products that do not currently exist. This is error-prone and uncertain. Most initiatives fail, but the rewards for the successful can be enormous. Since the cost of communications continues to fall, digital markets are global and expanding as more people get online.

Samsung recently announced it is investing $22 billion into emerging technologies such as artificial intelligence, 5G, automotive electronics and biopharmaceuticals as it searches for new products to power growth. Much of this work will be exploratory with high rates of failure, but that is normal in vertical markets.

Workers in these markets are unlikely to have the prerequisite skills since the technologies themselves are still being developed. Instead, the most valuable employees are rapid learners and linkers & thinkers who can take partial solutions from other domains to solve novel problems. 

One such example of linking ideas provided a solution to a rare liver disease in children called Tyrosinemia. The condition prevents the body from processing the common building block of protein tyrosine. Swedish doctors Elisabeth Holme and Sven Lindtedt stumbled upon the results from a failed herbicide experiment in Australia.

Chemicals in the bottle brush plant suppressed competing vegetation, making it a candidate for a natural herbicide. Unfortunately, experiments with mice led to eye issues and the product was abandoned, but the failed experiment was documented along with the plant’s tyrosine processing change. The doctors gained permission to run a small study and the results were dramatic, with liver function returning to normal. The failed herbicide became the miracle drug Orfadin that has saved the lives of countless children worldwide.  

We need to experiment and document not only our successes but also our failures. Who knows they might be useful to others. Ideally, this information should be openly available which will likely be a challenging concept for many traditional organizations. Even encouraging the sharing of positive experiments can be difficult for old mindset companies that rank staff performance against peers and create competition for resources between departments. In such environments, there is little reward for sharing valuable breakthroughs.

Nucor Steel solved this issue with its bonus pay system. Incentives are rewarded one level above people’s span of control. So, as a plant manager, bonus pay is not based on how well your plant is doing, but how well all the plants are doing. This encourages learnings and breakthroughs to be shared with other plants. It encourages global rather than local optimization. The model repeats at all levels, department heads are not rewarded on their department’s performance but a composite of all departments. The same for team leads and individual workers. Rewarding learning and collaboration has made Nucor steel one of the few successful US-based steel companies.                                                         

 


ExperimentsBetter Experimentation Design

If we are engaged in vertical development, we need to overcome our aversion to failure. As professionals with many years of experience, there is a stigma with failure. We are paid to know our field and deliver positive results, not failures. However, this is legacy industrial thinking. As knowledge workers, we need to be designing and executing low-cost experiments to learn more quickly than our competitors.

Paradoxically, if most of our trials and experiments usually work that does not mean we are great developers. It means we are wasteful innovators. By design 50% of our experiments should fail, this is the quickest path to learning and innovation. Failed experiments tell us just as much (and often more) than successful ones. We should not be duplicating confirmed ideas but exploring new ones.

Low cost and fast experimentation lead to more profit-or-pivot decisions. Organizations that can do this quicker than their peers emerge as the new Apple’s and Amazons. Organizations that do not, follow the path of Brookstone and Blockbuster.

 

LearningPersonal Learning

Going forward we need to recognize how people learn best which is through storytelling and visual learning. YouTube’s How-to videos are popular because they combine both elements in a time efficient delivery mechanism.

Checking our ego and embracing humility is also necessary for learning. We might be experts in horizontal development of the known, but no one is an expert in vertical development of the new. Instead, we must learn how to be collaborative problem solvers.

Harvard Innovation Lab expert Tony Wagner puts it this way. “Today because knowledge is available on every internet connected device, what you know matters far less than what you can do with what you know. The capacity to innovate – the ability to solve problems creatively or bring new possibilities to life – and skills like critical thinking, communication and collaboration are far more important than academic knowledge.”

We cannot predict the future and that’s what makes it exciting. We may not know exactly what technical skills to pursue next, but a couple of quotes that seem to apply include: “Once we rid ourselves of traditional thinking we can get on with creating the future” - James Bertrand and “The essential part of creativity is not being afraid to fail” – Edwin Land. So, go forward and experiment boldly.

  

References:

  1. Minifesto: Why Small Ideas Matter in the World of Grand Narratives, Magnus Lindkvist
  2. The Fifth Discipline: The Art & Practice of The Learning Organization, Peter M. Senge
  3. The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, Eric Ries
  4. Blue Ocean Strategy: How to Create Uncontested Market Space and Make the Competition Irrelevant, W. Chan Kim

 

 [Note: I first wrote this article for ProjectManagement.com here – free sign-up required]


Agile Animations

Animation Film
Following my Agile 2018 conference workshop, I had a couple of people ask how I created the smooth PowerPoint animations. I have always liked using animations to explain ideas since they help me understand processes.

My logic has been, if they help me understand it, then they should help others understand it too. Visual learning, and especially animations, are valuable on knowledge work projects.

Animations help us overcome the three challenges of knowledge work:

  1. Invisible – designs and ideas are often abstract and hard to visualize.
  2. Intangible – bits not atoms. Since we cannot see or feel ideas there is a real danger other people might interpret them differently, leading to difficulties with collaboration and problem-solving.
  3. Transient – Our work is often novel and unique, the challenges teams face are often unique too. The solution to our last problem is unlikely to help us today.

Tom Wujec, the author of The Future of Making, has an interesting short Ted talk on how animation helps create meaning. He explains seeing an image triggers 30 portions of the brain to start working together to process information, solve problems and make decisions.

Visualizations address the knowledge worker challenges:

  1. Clarity through visualization – engage all those brain circuits, helping us comprehend faster and clarify ideas.
  2. Making concepts interactive – when we all see the same interaction of components, we build a common understanding as a group.
  3. Make permanent – Animations can be stored, shared, and replayed - capturing mental models of A-ha moments.

So, if a picture is worth a thousand words, is an animation worth a thousand pictures (a million words)? – No, but it is hard to beat visual storytelling.

Continue reading "Agile Animations" »


Creed Over Greed: Motivation and Purpose

SunriseThere have been a couple of stories in the news recently that reveal some important facts about motivation and purpose.

  • Ex-Tesla Workers Are Still Believers

Some people’s reactions over being fired from Tesla surprised many analysts. Rather than the normal angry barbs (and I am sure there were plenty of those) what made the news were the messages of thanks from, now ex-employees, explaining how they enjoyed their time there and were glad to be a part of it. Some of the Tweets included:

  • “Thanks for the opportunity, Elon! Eye on the mission. Will always be proud to say I worked for Tesla”
  • “I just wanted to let you know that I really enjoyed working for Tesla”
  • “I was laid off from Tesla yesterday and although it hurts (a lot!), it is the right thing for the company. I don’t regret giving all I had and in a way bidding adieu is my last contribution. I’ll be cheering Tesla on knowing I did my part. Thanks for the years of memories!”

A Bloomberg article Fired Tesla Workers Still Love Elon Musk recaps some of the comments.

  • Enlightened Pessimism

From a reverse perspective, a recent Science Direct article found that Employees who practice mindfulness meditation are less motivated, having realized the futility of their jobs. It seems that when people learn how to detach from sources of stress they are less likely to want to work towards goals they are not aligned with.

So, beware those corporate mindfulness workshops unless your organization has a compelling purpose!

The Importance of a Compelling Purpose

First, people want jobs that satisfy their physical and safety needs of having enough money to provide the necessary food and shelter. These are levels one and two in Maslow’s hierarchy of needs. None of the later stages of motivation ever come into play until these most critical needs are met. However, once they are met, people want to work towards something worthwhile and motivating.

Tesla has never been about making fancy electric cars, that’s just a side effect of their real purpose. The Tesla vision and mission statement used to be: “To accelerate the world's transition to sustainable transport.” However, in mid-2016, the company changed it to “To accelerate the world's transition to sustainable energy.” So, they are not building cars, they are helping save the planet for us and future generations.

That is a worthy goal. It is a purpose people can get behind, and a reason people were glad to work at Tesla, even if their role has now ended. They were never just car makers, they were game changers and that’s what people are grateful for.

Contrast it to the mission of BMW: “Strategy Number ONE aligns the BMW Group with two targets: to be profitable and to enhance long-term value – from a technological, structural and cultural perspective. The mission statement up to the year 2020 is to become the world's leading provider of premium products and premium services for individual mobility.”

While it mentions culture, there is a focus on profit, value and being the world’s leading… In other words, it is based on money and dominance, rather than a compelling purpose.

Creed Over Greed

Most organizations share mission and vision statements like BMW’s. They talk about generating shareholder value and becoming the biggest this or the leading that. This is understandable in a purely economic model, but as we saw earlier, once people have enough money they want something more - something compelling, something worthwhile.

When we can appeal to people’s desire for meaning, and when we can support them to make valuable contributions to a worthwhile purpose, they will experience motivation beyond the economics that dwindles over time. “Creed” means a belief system, it is more powerful than greed. Growing larger for the sake of profit and market share is unfulfilling, like a cancerous growth.

Having a worthwhile purpose people can unite behind is tremendously powerful. Organizations like TOMS Shoes and Warby Parker attract top talent not only because they are rewarding places to work, but also because they share a larger goal of helping others less fortunate. Studies show that contributing to good causes makes us happy so it should be no surprise that working for an organization that helps others should be the most rewarding and motivating.

Talent is More Mobile Than Ever

The internet has lowered the cost of communication. It is easier than ever to advertise jobs and share the corporate purpose. People tend to switch jobs more frequently now and the same tools that make advertising jobs easier, also make relocation easier. Smart, talented people are more mobile than ever. They want to apply their skills in worthwhile, interesting settings.

Given the choice of making more money for executives and shareholders or saving the planet, most people (thankfully) would choose to try and help save the planet. When Tesla was hiring last year, they received nearly 500,000 applicants for about 2,500 job openings. So, people only had about a 1 in 200 chance of being accepted – a  testimony to how much people want to work there.

With these odds only the very best people get accepted. This has a two-fold effect, 1) the top talent moves to the better companies, 2) lacklustre organizations get a higher concentration of sub-par people as the best move on.

Find the Purpose/Make a Purpose

If you are a CEO, aligning your organization with a higher propose will help attract top talent. If you are a leader in a traditional organization, then creating opportunities for employees to contribute to society is a powerful motivator.

We cannot all work for Tesla or Patagonia, but we can try to inject some worthwhile components into people’s work lives.  Hackathons for a good cause, Habitat for Humanity volunteering, they all help create more satisfied and motivated team members.

At various stages of people’s careers, they care about different things. Many people starting out just want the highest paying job they can obtain to get established in their adult lives. This is understandable and natural. Then, later they want to be part of something bigger, something more useful. Understanding and recognizing this desire allows organizations offering a motivating purpose the capability to appeal to the top tier talent.

 

[Note: I wrote this article for ProjectManagement.com first and it was published here]


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

 


Webinar – Solving Wicked Problems: What is Old is New Again

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

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

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

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

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

Watch Now.