Project Management Lessons from Paleoanthropology

In early 1987, a study of 145 mitochondrial DNA samples from women representing a variety of populations, conducted by biochemists and geneticists, was published in Nature. Using a complex analytical model based on mutation rates, the authors determined that all living people have a common ancestor, later dubbed Mitochondrial Eve, who lived in east Africa between 140,000 and 200,000 years ago. This was a blow to the multiregional hypothesis promoted by several prominent paleoanthropologists, which asserted that the fossil record showed continuous evolution over the last two million years in widely distributed locations. But recently, a team of geneticists, paleoanthropologists, and other scientists collaborated to develop a new model. And their approach has important lessons for those of us who manage teams of knowledge workers with diverse specialties.

Acknowledge Biases and Assumptions

Every well-developed knowledge specialty has its own culture, models, methodologies, favored data sources, and assumptions. Consequently, practitioners have biases that reflect their specialty. The scientists in this interdisciplinary team, led by archeologist Eleanor Scerri, wanted to avoid letting their professional biases lead to “cherry picking across different sources of data to match a narrative emanating from one [field].” So, the team met for three days to review each other’s work—challenging assumptions, noting accomplishments and problems, and learning to communicate effectively with their colleagues in other specialties. This process led to a coherent view, goodwill, and mutual respect. Lesson learned: many of our biases arise from deep knowledge in our specialty and confronting them early can facilitate cooperation and team building.

Develop a Common Vocabulary

Paleoanthropologists, geographers, geneticists, and environmental scientists have very different ways of talking about their work. Each field has its own jargon, buzzwords, and acronyms. Scerri noted, “[Our] understanding of findings tends to be influenced by the models and paradigms we have in our heads, which tend to … [affect] how we process new information.” The team had to pool their knowledge in a way that let them share data, methods, and models in a way that didn’t leave anyone out. This required them to adapt their communications to use terminology that was meaningful to the entire group and avoid a dependence on jargon. Lesson learned: time invested in establishing a common vocabulary facilitates understanding and leads to real progress.

Become Accustomed to Conflict

The researchers were able to reconcile their different theories into a cohesive story that accounts for the complexity of the different data points and leaves room for the abundant ambiguity still present. Scerri noted, “Insights from different models can help to shed light on the answers we look for … it’s all about incremental steps and changing perspectives.” Lesson learned: conflict can often be resolved, but even when it can’t, the root of the conflict is often based in some ambiguity. Acknowledging that ambiguity is a step toward a tentative agreement, pending eventual resolution of the ambiguity.

Scerri and her colleagues recognize that, like humanity itself, their model is still evolving. New data and new ideas will inevitably lead to future refinements, and they are fine with that. And that might be the most important lesson of all: you don’t need to be absolutely certain in order to deliver something of immediate and future value.

And if you’re curious, here’s a link to their paper.

New PM Articles for the Week of February 19 – 25

New project management articles published on the web during the week of February 19 – 25. And this week’s video: Doug H. shows us how to create a dynamic dropdown list in Excel using the Indirect function. Validate a cell based on the value contained in another cell! 6 minutes, safe for work.

Must read!

  • Maria Korolov reports that the global cyberwar is heating up and businesses should be worried about it. Why launch a nuke when you can devastate an entire economy? 10 minutes to read.
  • Dmitriy Nizhebetskiy explains the overlap in skills and responsibilities between a project manager, Scrum Master, and product owner. 8 minutes to read.
  • Hal Gregersen suggests a new approach: brainstorm for questions, rather than answers. New questions beget new insights. 15 minutes to read, but well worth your time.

Established Methods

  • Leigh Espy tutors us on how to create and maintain a project assumptions log. 8 minutes to read, with examples and a downloadable template.
  • Kiron Bondale introduces us to Randomized Branch Sampling, an estimation technique borrowed from orchard managers and adopted by software teams. 2 minutes to read.
  • Jonathan Browne separates rigorous problem definition from similarly rigorous solution definition. 5 minutes to read.
  • Vanita Bhoola considers scope creep in projects and how we can apply critical thinking to deal with volatility, uncertainty, complexity, and uncertainty. 10 minutes to read.
  • Melissa Eaden advocates for an aggressive approach to clearing defects. 6 minutes to read.

Agile Methods

  • Stefan Wolpers curates his weekly list of all things Agile, from corporate Agile failure to Agile metrics to three indicators of a waterfall team. 7 outbound links, 2 minutes to scan.
  • Juliet Lara offers some ways to tell if user your stories suck, and how to improve them. 7 minutes to read.
  • Johanna Rothman begins a new series on challenges encountered in Agile transformations. 3 minutes to read. Part 2 will take 4 minutes.
  • Mike Cohn insists that all team members should be in all team meetings. Filtering people out because of their role fragments the team. 4 minutes to read.
  • John Goodpasture notes that Agile teams can be virtual and backs it up with details on what adjustments are necessary. 2 minutes to read.
  • Brian Crofts differentiates between the product manager and the product leader. 4 minutes to read.
  • Renee Troughton imagines several Game of Thrones characters as product owners. 6 minutes to read.

Applied Leadership

  • Glen Alleman summarizes the leadership lessons from Ernest Shackleton’s failed exploration of Antarctica in 1915. 10 minutes to read.
  • Dave Prior and Mika Trottier talk about the mental shift required to stop thinking of people as resources. Video, 33 minutes, safe for work.
  • Mary Jo Asmus tells of a client who was frustrated because his employees had adopted his lack of curiosity. Engagement starts at the top! 2 minutes to read.

Technology, Techniques, and Human Behavior

  • Nick Heath reports on new research that allows simulated robots to independently learn skills like walking—you know: like babies do. 2 minutes to read, plus a 6-minute video interview.
  • Hanne Tidnam, Adam Bry, and Chris Dixon discuss the evolution and state of the art of autonomous drones—in this case, the self-flying camera. Podcast, 23 minutes, safe for work.
  • Katrina Clokie walks us through the process of deciding how to automate testing, based on factors that have nothing to do with code. 7 minutes to read.

Working and the Workplace

  • Suzanne Lucas points out five really hard things that successful people do. 3 minutes to read.
  • John Yorke reflects on the active nature of feedback and the requirement for a sense of empowerment in order for feedback to work. 3 minutes to read.
  • Kerry Wills observes several persistent types of interaction in meetings, which he characterizes as roles. Worth a smile and you can read it in a minute or so.
  • Francisco Sáez examines intensity of focus as a contributor to productivity. 2 minutes to read.

Enjoy!

New Post at AITS: There’s More to a System Design Than Requirements

My latest article for AITS was published today: There’s More to a System Design Than Requirements.

Acme Tornado KitIn addition to meeting the current needs of the users, a good design (and a good implementation of a good design) has to be capable of being supportable once it makes the transition to production. We have to be cognizant of both the history of the legacy system we’re replacing and the potential for evolution of user requirements over time. Both technical debt and Lehman’s Law come into play here and good project managers help the designers keep past, current, and future needs in mind.

As always, thanks for taking the time to read my stuff.