I'm preparing for two "project management in libraries" presentations in May/June at upcoming conferences. In describing project management, there are essential basics, including the "iron triangle" or "triple constraint" of  scope, schedule, and budget. These three areas are each represented by chapters and knowledge areas in the Guide to the Project Management Body of Knowledge. 

​In an excellent ProjectManagement.com presentation, Dr. Blaize Reich of Simon Fraser University provides project managers with some approaches to move beyond the triple constraint approach. As Dr. Reich points out, the triple constraint isn't the current, first measure of success - rather, it's on value delivery. She describes the work that she and three other research colleagues have undertaken in measuring project satisfaction based on triangle/triple constraint targets and on perceived value (by customer) - and emphasizes that these measures are correlated, but only weakly in some cases.  

Dr. Reich then focuses on three innovations to improve value:

• Design thinking
• Benefits mapping
• Hybrid project management (her area of research focus)

Taking benefits mapping as an example, Reich provides a specific example from an automobile association that's building a service center. One value of benefits mapping that she cited (relating a user experience):  Using this innovation shifted the early project conversation from what we are doing? to why we are doing it? Two specific benefits were articulated and target goals were assigned to each and documented. Importantly, changes to the benefits are tracked as well - if the benefits are reduced during the project work, the use of benefits mapping guides the manager to consider - is the project worth doing with the reduced benefits? 

All of these value-enhancing approaches take time (design thinking, for example, requires a period of times from hours to a small number of days to define the problem space). With schedule pressure, these more methodical approaches can be a difficult sell in the organization. 

I viewed a timely projectmanagement.com presentation on the need for project managers to embrace innovation. This is behind the PMI/projectmanagement.com paywall, but I encourage those of you with access to watch this presentation and consider the presenter's (Dennis Stauffer, of Innovator Mindset) arguments. 

Stauffer compares the status quo and innovator approaches and mindsets. Across positions and to a great degree as a project manager, I personally have worked in an implementer role, with a focus on the detect and correct loop. While this isn't bad in and of itself, Stauffer compares the innovativeness scores (using an instrument created by IM) of individuals across some industries with value add - and emphasized that most of the value add comes from those working on the higher end (70-100) of innovativeness. 

Okay, okay - Stauffer takes a more extreme approach in the session when describing the attributers of the status quo and innovator mindsets. Here's a subset of examples:

Status quo:  Argumentative, frustrated, blaming...

• Stauffer:  This is when the detect and correct/status quo approach becomes too dominant

Innovator:  Curious, open, reflective...

• Stauffer:  "Innovators and the best project managers live in this space" (emphasis mine)

To get to the presenter's core argument:  The high-level flows of the status quo and innovative approaches are similar (both with Idea, Action, Reality, Feedback phases in a loop). The PMBOK Guide approach is valuable, but taken too far, it can undermine innovation (specific example that came out during the Q&A session, the overcommitment of resources to knowledge management and documenting lessons learned). 

Stauffer suggests that the project manager should embody innovation. Ask questions instead of making declarative statements; embrace feedback (including negative feedback - which the presenter depicted as a key indicator of effective innovators). 

I hope to take the IM instrument soon  to determine my own innovativeness score  and to learn more about Stauffer's research. Can I ask more questions and make fewer declarative statements? It's an interesting test for me....

One of the challenges that I have in communicating with colleagues on project management is the amount of valuable and intriguing content that's behind a paywall for full access - particularly, PMI PMI ProjectManagement.com materials. 
A happy exception in the risk management area is this Dr. David Hillson 2013 presentation on risk management (YouTube, 45 minutes). 
A couple of specific takeaways:

• If you want to know why there's an Executing process in the Risk Management knowledge area with the PMBOK Guide Sixth Edition, watch Hillson describe what can happen  to risk management risk and response information without making a conscious execution effort
• Toward the end, Hillson provides a nice take on the importance of managing the people side of risk management, including understanding and influencing risk tolerance among stakeholders

I've spent some time recently going over the PMBOK Sixth Guide, Sixth Edition PMP training materials created and published by Velociteach. At the same time, I'm using Mike Bissonette's book Project Risk Management: A Practical Implementation Approach to gain a deeper understanding of risk management. How can the PMBOK processes, including the tools, be leveraged to improve on project risk management?
The current PMBOK Guide, Sixth Edition, has this Risk Management process structure:
Planning

• Plan Risk Management
  Bissonette: "It is considered good practice...to conduct project risk management processes intentionally for projects that are inherently risky." Earlier the this book/guide, the author describes the increasing risks when projects are planned and executed in increasingly competitive industries and spaces. 
• Identify Risks
  Bissonette:  "Identifying project risks is considered by many to be the most difficult aspect of the project risk management process." The author then devotes three chapters of his book to this process. 
• Perform Qualitative Risk Analysis
  Here, the author makes the distinction between "individually identified risks" (relevant to this process) and "overall project costs and schedule risks" (relevant to the quantitative risk analysis process). 
• Perform Quantitative Risk Analysis
  Again, Bissonette, on why this separate process exists: "In most circumstances, the overall project cost and schedule risk assessment cannot be effectively determined by aggregating the individual risks." 
• Plan Risk Responses
  Here, responses are developed for the identified and analyzed risks. Bisonette notes: "Each response typically requires resources (time, people, and budget) to implement. If too few resources are available to cover all response strategies, priorities and trade-off decisions are necessary...."
  
  

Executing

• ​Implement Risk Responses*
  Velociteach's Andy Crowe provides an introduction to this new Sixth Edition process, which is in the Executing process group. This process implements the plans outlined in the five planning processes for this knowledge area.  It's performed after the planning processes, including Plan Risk Responses, are completed. 

Monitoring and Controlling

• Monitor Risks
  Bissonette puts this process in the context of the other PMBOK Monitoring and Controlling processes across the knowledge areas (that is, the similarities between Monitor Risks and other Monitoring and Controlling processes). He then describes drivers between planned and actual risks, including the emergence of unknown unknowns. 

* Process introduced in PMBOK Guide, Sixth Edition; not addressed as a process by Bissonette.