New PM Articles for the Week of September 1 – 7

Over My HouseNew project management articles published on the web during the week of September 1 – 7. We give you a high-level view so you can read what interests you. Recommended:

PM Best Practices

  • John Goodpasture educates us on the art and science of preparing a request for proposal, or RFP. Must reading!
  • Paul Glen explains why one person can’t be a project manager and a programmer, at the same time.
  • Michel Dion walks us through the process of taking over a project from a departing project manager.
  • Glen Alleman recounts the development of multi-criteria decision analysis.
  • Bruce Benson shares a lesson learned from Little Caeser’s Pizza restaurants: small changes are sometimes enough to get big results.
  • Elizabeth Harrin summarizes a presentation to the Ireland Chapter of PMI, delivered by Mike Hughes, Office Business Group Lead for Microsoft Ireland.
  • Gina Abudi reveals her secrets of evaluating the culture of a client organization.
  • Nick Pisano tells why measuring technical achievement matters and how fits in with other progress metrics.
  • Kenneth Darter lists the attributes of an effective project sponsor.

Agile Methods

  • Mike Cohn defends the notion that story points are about time and level of effort, rather than just complexity.
  • Bart Gerardi looks at Agile anti-patterns, starting with translating story points to effort hours.
  • David Baker explores how the business analyst fits into the Scrum framework.
  • David Anderson explains how risk affects work in progress, using a real life example: the number of shirts he should keep in his closet.
  • Tobias Mayer gives a tongue-in-cheek explanation of how to scale Agile, the same way you would scale a fish. Excellent!

Following the Trends

  • Nick Heath reports that IT outsourcing firms in India are automating many of their technical jobs. Salaries are skyrocketing due to competition for engineers!
  • Mike Frandsen reflects on how the move to continuous development at Workday has benefitted their customers and increased the pace of innovation.
  • Jelani Harper gives us the background on data governance programs.
  • Suzanne Lucas gives us Boomers and Gen-X types a few cultural insights (OK, warnings) on how these recent graduates will change our workplace.

Professional Development

  • Lindsay Scott uses a cautionary anecdote to lead up to the question: What was the last conscious thing you did to benefit your PM career?
  • Andrea Brockmeier shares her thoughts on preparing for the PMI-ACP exam.
  • Michael Lopp describes your elusive but hyper-effective colleague, The Wolf.
  • Susanne Madsen offers three critical questions that you can use to solicit feedback.

Podcasts and Videos

  • Cesar Abeid interviews Patrick Coffin and Dustin Kahia on their upcoming film, “Call of the Void,” and movie project management. Just 57 minutes, safe for work.
  • Cornelius Fichtner interviews author Mark Phillips on his new book, “Reinventing Communication.” Just 30 minutes, safe for work.
  • Margaret Meloni defines strategic reserve time, in the context of teams for whom the project is not their sole responsibility.

Enjoy!

New PM Articles for the Week of August 18 – 24

Balloon BeyondNew project management articles published on the web during the week of August 18 – 24. We give you a high-level view so you can read what interests you. And yes, I took all of these hot air balloon photos right in my own neighborhood. Privacy? Well, they seemed friendly enough. Recommended:

PM Best Practices

  • Glen Alleman imagines a conversation between a project manager, a team of software developers, and an iceberg.
  • Brad Egeland starts a new series with a look at customer satisfaction, and why it’s the most important success metric.
  • Jim Anderson speculates on the root causes of Avon’s recent SAP implementation failure. The users left the company, rather than switch? Wow …
  • Emanuele Passera applies the tenets of “locus of control” theory to project management.
  • Bruce Benson tells of the New Manager who wanted to help.
  • Ian Whittingham continues his look at project management applications for Leavitt and Dubner’s new book “Think Like a Freak.”
  • Christopher Merryman demonstrates ways that we can add visual presentation to our project reporting communications.
  • Dan Patterson makes the case for consensus-based planning.
  • Ron Rosenhead tells of the great new Projects web site at the University of Edinburgh, and asks us how much project information do we share?
  • Nick Pisano is perplexed by the academic community’s apparent lack of interest in Big Data.
  • Jen Skrabak maps Tim Ogilvie’s “design thinking” to project portfolio management.

Agile Methods

  • Mike Cohn explains his approach to massaging the backlog for a three-month vision of where the product is going.
  • John Carroll explains the Taoist basis for Agile methods. Or at least, anti-rigidity.
  • Craig Brown and Tony Ponton interview a few attendees / thought leaders at Agile Australia in Melbourne. Just 25 minutes, safe for work.

Professional Development

  • Elizabeth Harrin Interviews Terry Okoro, Chair of the APM’s Women in Project Management SIP on their 21st anniversary conference in London.
  • Dave Prior advocates for experiential learning, also known as “getting a bunch of adults to play a game together.”
  • Robert Wysocki and Joseph Matthews continue their series on methods for the Occasional PM. This episode: team structure.

Enjoy!

Risk Management is Part of the Operating Rhythm

Risky Baby Business

Risky Baby Business

I just watched Dave Prior’s interview of Ken Rubin at the Agile 2014 conference. It’s a good interview, and Ken makes some excellent points. But at one point, he makes the observation, “In more traditional risk management, the assumption is early on that you’re going to generate this risk assessment. You’re doing this now on the first day, when you have the worst possible knowledge you’re ever going to have about the project.” Dave then interjects, “And then nobody updates it.” While I agree that this is not uncommon, it is poor practice.

Risk management should not be something you do once, at the beginning of a project. It should be part of the regular operating rhythm of any project. Whether you take a very structured approach to assessment, with quantitative analysis and a separately managed risk budget, or a qualitative approach with risk management costs baked in to the project budget, risk management is only beneficial if it is part of execution, as well as planning. Our risk assessment, like our requirements gathering, should be an ongoing process that improves the resilience (anti-fragility, if you prefer) of the endeavor over the course of the project.

Risk: “An unknown that matters”

I would argue that a large part of any risk management project, like the requirements gathering process, is reducing or eliminating the unknowns. This can’t be accomplished just by making plans – you have to take action and increase your understanding. Let’s consider the most common risk responses:

  • Transfer: If you transfer the responsibility to deliver some portion of the project, especially to an external organization, you still have to ensure that they’ll be deliver on time and to the required quality in order to make your risk response successful. This requires continuous monitoring and corrections, as well as coordination with the other performers on your team. If things start to go sideways, you’ll have to deal with the residual unknowns and the possible impacts.
  • Mitigate: Any mitigation action should have a trigger, which requires monitoring. Once triggered, you need to determine if the mitigation is having the desired effect. If your mitigation is intended to reduce the impact of the risk event, you need to update your estimate of the impact in order to know whether to make incremental changes. If the intent was to reduce the probability of the risk event, you need to be able to monitor the residual probability.
  • Avoid: If you avoid a risk by removing something from scope or changing the design, you’ll need to communicate that decision to the stakeholders. This shouldn’t be something done only at the time of the decision; it needs to be part of your communication plan.
  • Accept: If you decide to accept a risk, you still need to monitor for it. It is not uncommon for a project to decide that a risk, previously determined to be acceptable, grows to require some mitigation or even avoidance.

The Team Should Know the Risks

The risks to the project may impact the project team, so they need to understand them. They also need to understand the planned responses for each significant risk, at least as it impacts their work. The team is part of the “sensor network” that will detect the transition from risk to issue, requiring action. They need to understand their role, and how to escalate an observed risk response trigger.

Ultimately, risk management is an integral part of the execution of the project. Whatever methods you use to manage and respond to project risks, be sure to keep discussion of the risks under management on the agenda for your team’s regular meetings. Few risks are entirely static; we have to manage them dynamically!