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.


Egad, Not Another “Weird Al” Video?

I can’t believe I’m linking to Yet Another “Weird Al” Yankovic video, but here it is. It seems that Al culled mission statements from a wide variety of organizations and put them to music, based on Stephen Stills’ love song to Judy Collins, “Suite: Judy Blue Eyes.” Warning: I wasn’t sure whether to laugh or seek medical attention, but it will definitely impact the way I talk about project goals.

Thanks to Craig Brown for calling my attention to this one.



High Failure Rate, Compared to What?

Failed DigFor many years now, we’ve read studies such as the CHAOS report, expounding on the relatively high failure rate of IT projects. High, relative to what – highway construction projects? The typical highway construction project is proposed, studied, risk managed, and planned for years before the first shovel of earth is turned. A massive body of laws, regulations, standards, and technical requirements drive every design. Materials, products, and processes are mature and standardized, and a coterie of safety experts, inspectors, and regulators watch over every step. With all of that, one would reasonably expect highway construction projects to have a low failure rate. Yet, these projects still fail. The Big Dig in Boston stands out as a monument to cost and schedule over-runs.

Rat's Nest CablingIT projects, on the other hand, tend to be subject to snap decisions by sponsors, with little executive oversight. There is typically limited time allowed for planning, due to short schedules driven by “competitive pressure” and ever-shorter product life cycles. Scope is frequently vague. Stakeholders are usually too busy with “business as usual” to participate in planning, defining requirements, or testing. Project team members are rarely dedicated to the project, and their work priorities are constantly shifting. Software tools are buggy, poorly documented, and poorly supported by the vendors (or “supported” by a user community). No wonder so many software development teams are using Agile methods to shorten their development cycle, limit their scope, and keep “the bar” within reach.

Defining Success

All of those constraints and challenges aside, we should assess success in terms of results delivered. Project management isn’t about budgets and schedules; those are just the means to an end. A successful project would:

  • Deliver usable results, quickly enough to be of benefit, to customers that understand how to use them
  • Delivery didn’t “break” something else
  • All non-functional requirements were met
  • Knowledge transfer was compete and effective
  • Maintenance throughout the product life cycle will be cost-effective, and major business process surgery won’t be required in order to replace it at end-of-life
  • Quality is commensurate with the criticality of the delivered product to the business
  • Organizational change management efforts were sufficient to meet adoption goals
  • The risk profile did not exceed the organizations appetite for risk, and the risk management budget was spent wisely
  • All contracts were completed satisfactorily and relations with the vendors remain positive
  • The core project team was retained, and their experience will benefit the organization in the future
  • After some reasonable period of time in operation, it looks like the ROI that will be achieved at least matches what was expected in the original business case
  • Any lessons learned have benefited other activities within the organization

You can make your own list, based on the nature of your project, but the key point in making it should be that success isn’t about the project; it’s about the results.