I read Andy Silber’s Adaptive project management: Leading complex and uncertain projects.
I had the chance to meet Andy at the PMI Global Conference in Chicago and to attend his session on adaptive project management. Silber’s coverage of the shortcomings of predictive project management for projects with uncertainty is solid, but even before leaving Chicago, I realized there was a conflict between Silber’s take on the support for risk management with agile methods and that of agile leaders and practitioners whom I met with and heard present at PMI Global. In one of the book's chapters, Silber describes why agile approaches don’t work well with highly complex projects. I don’t understand why Silber doesn’t note the successful uses of agile approaches outside of software or SaaS management. Second, during his session, Dr. Silber noted the limits of agile in risk management. My understanding here is that each risk should be identified, analyzed, and prioritized in the backlog - thus, risk management is better supported in agile approaches than represented in this book.
Silber’s background is relevant to understanding his recommended approach – an astrophysicist, a PMP, and a manager deeply experienced in leading technology hardware projects. These hardware projects have attributes – for example, very high cost for a prototype delivery – that Silber asserts do not map well to either predictive or agile approaches.
Silber’s book is short, but it’s good reading for those interested in project management generally, and in agile approaches specifically. For projects with high uncertainty and complexity, Dr. Silber recommends adaptive project management, which draws on the best tools in both predictive and agile approaches. Silber does provide specifics on the adaptive project management approach (for example, in the chapter “Building a schedule”).
I participated in the October 28-30 PMI Global conference in Chicago, Illinois. This was my first global conference. I began session planning some time ago, but I made further adjustments to the schedule on site, as described below.
The conference kicked off with a keynote by Sir Tim Berners-Lee. Having Berners-Lee begin the conference made sense in one way, since he created one of the most important projects in history: http://info.cern.ch/hypertext/WWW/TheProject.html. Several points that he made blended well with other PMI Congress conference themes:
-Central role of collaboration in terms of building out the World Wide Web (the early WWW were colleagues from CERN and others with networked access to a NeXTdevelopment workstation)
-That the WWW and the predecessor TCP/IP were "permissionless" spaces that enabled extension of the protocols without the bottleneck of clearing work with a central authority
-In terms of leadership: Berners-Lee called out a couple of leaders in his career, for example, his manager at CERN, who provided protection to him in WWW development (think: Protecting the project manager and team)
-No royalties demanded, contrast to Gopher, which had a strong growth period and dived after the University of Minnesota began charging licensing fees (more details in this article)
One year ago, I was furiously studying in preparation for my (successful) Monday, November 7 PMP examination, with my study focused on A Guide to the Project Management Body of Knowledge, Fifth edition and supporting materials for the PMBOK. Thus, it was based on what I'll term predictive project management tools and processes. And while the PMBOK is still a valuable tool, I organized my conference schedule to focus on agile and adaptive methods - with the recently-released Agile Practice Guide as my primary focus.
Mike Griffiths of RMC Learning Solutions was the chair of the group that created the Agile Practice Guide. This guide was collaboratively created by the Project Management Institute and the Agile Alliance. Griffiths presented on the guide and how its creation fits with past project management methodologies. One point that he made was that the term predictive is used in the guide instead of traditional or (particularly) waterfall, and that the latter term is intentionally not used in the Agile Practice Guide beyond a single sidebar instance because it's become a loaded term, with the currently-understood definition not matching what Winston Royce proposed in 1970. (Here's another analysisthat supports Griffiths' interpretation of waterfall.)
Griffiths described agile approaches as the de facto standard for innovation projects most of the time, and that agile approaches fit well for knowledge work. In cases of either requirements uncertainty or technical uncertainty, the use of agile approaches make sense. (I'll be addressing the cases of both requirements and technical uncertainty later when I discuss Andy Silber's work, but Griffiths' take is that one needs to be reduced in order to effectively manage the project.)
In reviewing the history of some twentieth century US technical projects, Griffiths noted the fact that two prominent examples, Manhattan Engineer District and Polaris, mirrored agile approaches in some respects. For MED, he asserted that the project was focused heavily on prioritization and risk reduction. Specific example not cited by the presenter, but one that I'm aware of that fits nicely: A Naval Research Laboratory researcher, Phillip Abelson, worked on a thermal-diffusion process for separating U-235 from U-238 independently of the MED. MED head General Leslie Groves had ordered inspections of Abelson's work in 1943, but decided not to support this uranium isotope extraction method. The story continues:
Even under these difficult conditions, Abelson persisted in his research on thermal diffusion. Now ready to test large equipment, Abelson obtained approval to build a new plant in the Naval Boiler and Turbine Laboratory at the Philadelphia Navy Yard. The plant was under construction in the spring of 1944 when J. Robert Oppenheimer, director of the weapons laboratory at Los Alamos, learned that Abelson's plant would be producing small amounts of slightly-enriched uranium by July....Aware of the obstacles which the Manhattan District had encountered in developing other isotope-separation processes for the huge plants under construction at Oak Ridge, Oppenheimer suggested to Groves that Abelson's plant might be the best way to produce uranium 235 quickly. Groves immediately reestablished contact with the Navy. Time was so critical that he decided to gamble on building a full-scale thermal diffusion plant at Oak Ridge without further experiments... (Hewlett/Duncan, Nuclear Navy 1946-1962, pages 16-21).
The other common characteristics of agile approaches include: Consensus gathering; short build/feedback cycles; results-oriented reporting (for example, Earned Value that focuses on delivered product, not percent of project completion), and respect and empowerment.
To wrap this section: The Agile Practice Guide provides information on agile methodologies used to manage complex projects successfully and my primary takeaway from this meeting is a deeper knowledge of its potential use. The guide describes tools like the Project Approach Suitability Filter, which supports the application of agile to organization projects.
Continuing: One of the methods described in the guide is the Kanban Method. Annette Godsk Vendelbo presented on Kanban. From my perspective as an Orbis Cascade Alliance program manager in an organization that's working to improve project management practices, Kanban is an attractive methodology. Its foundational principles:
1. Start with what you do now
2. Agree to pursue improvement through incremental change
3. Initially, respect current processes, roles, responsibilities, and job titles
4. Encourage acts of leadership at every level of your organization (more info)
Thus, it's a conservative way to move into more agile/lean project management. The goal with Kanban is to manage the project work as a batch, to optimize throughput and flow and, thus, to shorten project lead time (or, the time it takes for a task to move through a Kanban Board). In terms of the project manager, Vendelbo described two roles that have emerged with Kanban:
Service request: Marshaling opinion
Using a Kanban Board to quantify and prioritize options
Service delivery: Managing flow
Using a Kanban Board to track status from committed through development and testing to release and rollout
Note: WIP (work in progress) limits are defined on the board and adhered to by the team
Note: Limiting WIP should limit multi-tasking
This was really a complete and informative presentation by Annette Vendelbo. It will take me some time to work through this, but one takeaway that I have is for the Alliance staff to understand the current uses of project boards in the Alliance and for managers to fully share information about their function(s). In at least one case, for a newly-created group supporting Alliance extensions to the Primo discovery service, the Alliance group is consciously using a Trello project board as an information radiator ("a visible, physical display that provides information to the rest of the organization enabling up-to-the-minute knowledge sharing without having to disturb the team").
This brings me to Nicholas Epley's keynote, one that I had prepped the most for by prereading portions of Mindwise before arriving in Chicago. Epley, in Mindwise: "My collaborators and I asked one group of volunteers to write two different sentences about ten topics, one intended to be serious and one intended to be sarcastic....We then asked each of our volunteers to convey these messages to another person in the experiment. In one condition, they sent the message via email; in the other, they spoke it over the telephone." The results? Anticipated accuracy for both email and phone communication was around 80%. Epley: "Those actually receiving the messages...could understand the speaker's intent only when the communication was clear." (Epley, Mindwise, pages 106-107). The actual accuracy with phone communication was close to anticipated (73.1%), while the actual accuracy level for email was vastly lower - only 56%. Note the receivers' interpretation accuracy figures - even higher than that the senders' expectations.
I need to spend more time with this book, but one takeaway that I have, that the author touched on at the end of his keynote, concerns humility. This means keeping proper perspective on your own role as project manager (which I see as meshing well with the "servant leadership" emphasis in the Agile Practice Guide). Also, understanding our limits as project managers on the ability to read people (via body language) and to understand the limits of electronic communication.
Then, finally: I'm interested in learning more about Andy Silber's work after seeing his presentation on adaptive project management. Silber described this management as applicable for projects that are uncertain in terms of requirements and technology. Silber, an astrophysicist and PMP who leads hardware product development, asserts that there are cases in which neither predictive nor agile approaches work well. These include: Where the cost of a build is very large; and, a project with extremely complex dependencies. (He also asserted agile's lack of strong support for risk management, but I cannot agree with this point). I hope to work through Silber's book soon to more fully understand his project management recommendations.
As you can see, most of my focus at the conference was on technical project management. I did attend some leadership sessions as well and I feel that they were valuable:
-Karen Chovan, The Necessary Culture for Soaring Performance (which also touched on the importance of servant leadership in project management)
-Sara Gallagher, on communicating when you're not co-located/communicating virtually: A session that was repeated on the final day due to attendee voting for encore sessions; as a member of the Alliance staff, this was extremely valuable for me
-Abbigail Frelich and Elizabeth Allen from Nemours Children’s Health System, describing how they've worked to build an enterprise culture of project management, including an organization project management training program - the Alliance staff have started a program like this in the past few months and I'm hoping to take some lessons learned from the Nemours effort
I'll wrap up my summary, having just scratched the surface. One year ago this weekend, I was in deep study on predictive project management in preparation for a Monday morning PMP exam. This weekend, I'm focused on the newly released PMI/Agile Alliance guide and on making project management work for my organization, a nonprofit providing services to higher education institutions (read, a knowledge management organization, where agile approaches fit well). But a concluding and key point: Both predictive and agile methods employed by project managers are standardized. Project managers need to be proficient in a range of approaches that can be applied to help their organizations meet and exceed their goals.