New PM Articles for the Week of July 7 – 13

Picking CherriesNew project management articles published on the web during the week of July 7 – 13. We gather all of this stuff so you don’t have to search for it! Recommended:

Risk Management

  • Craig Brown observes the effect that the company’s financial performance has on how we manage change.
  • Adam Stone reports on efforts to secure the energy grid from malicious mischief. Or even acts of war.
  • Gina Abudi suggests we consider the challenges of cultural diversity on geographically distributed teams in terms of risks we need to manage.

PM Best Practices

  • Glen Alleman notes that the Minimum Viable Product mindset, popular in certain product development circles, doesn’t consider enterprise business needs.
  • Nick Heath reports on some of the imbedded system prototypes and single-function servers built using the $35 Raspberry Pi Linux computer.
  • Andy Jordan describes his vision of an enterprise PMO, with a number of support structures to provide guidance throughout the organization.
  • Nick Pisano replies to my recent post on defining project success, centered on disruptive change and the potential impact of change management.
  • Lynda Bourne explains stakeholder theory, as conceived by Ed Freeman. The ethics component matters deeply!
  • Suzanne Lucas recently saw an article on bad parenting behaviors by a British nanny; Suzanne interprets the same behaviors as bad management.
  • Bart Gerardi enumerates the costs of scope and requirements changes on the project, and on the team.
  • Cheri Baker has been experimenting again. This time: co-working! Also known as, “Working in an open space with other people around.” Well, maybe not …
  • Kerry Wills objects to long Emails, for many reasons. For one thing, they’re … long.

Agile Methods

  • Mike Cohn suggests we select backlog items that will serve an additional purpose – like risk management, or the chance for the team to learn.
  • Henny Portman shares the white paper (in English) synopsis of his recent book (in Dutch) on managing Agile projects, using Atern.
  • Donna Reed considers a range of metrics for measuring the success of an Agile project manager.
  • Vandana Roy considers the merits of Scrum and Kanban, and which one would prevail in a fight. No, not really …

Professional Development

  • Elizabeth Harrin extracts some key points from “Business Networking,” by Will Kintish, to explain why you must network.
  • Penelope Trunk explains why keeping you options open leads to failure; only full commitment succeeds!
  • Lyndsey Gilpin trots out some statistics on the state of women in technology. If you’re a people manager, you have a chance to help shape a better future.

Podcasts and Videos

  • Cesar Abeid interviews Jonathan Creaghan on why we just make stuff up, more or less. Just 40 minutes, safe for work. I’m not making this up …
  • Samad Aidane share a four part video version of his “ERP Projects: The Complete Survival Manual.” Each part is about 11 minutes, and all are safe for work.
  • Craig Smith interviews Alan Bustamante on conflict resolution and starting Xcelerate Partners, as well as all things Agile.  Just 36 minutes, safe for work.

Enjoy!

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.

New PM Articles for the Week of June 30 – July 6

Gathering ClamsNew project management articles published on the web during the week of June 30 – July 6. We gather all of this stuff so you don’t have to search for it! Recommended:

Risk Management

  • Andy Jordan consider the decision whether to manage risks at the program level or push them down to the project level.
  • Nittin Mittal identifies the top eight risks in Agile projects.
  • Matthew Squair prepared a hazard checklist for a course he was teaching, and decided to share it with us. It’s an interesting list of risk sources!
  • Ron Rosenhead asked the class in one of his project management courses what goes wrong in their projects. Yup, more sources of risk!

PM Best Practices

  • Pawel Brodzinski challenges the default option of “grow” with an alternative: preserve the culture.
  • Elizabeth Harrin reviews “The Presentation Book,” by Emma Ledden.
  • Robert Wysocki and Joseph Matthews continue their series on the Occasional PM, with a look at three types of projects they are likely to encounter.
  • Glen Alleman reminds us that the ability to release software faster than the business operating rhythm will allow the changes to be absorbed is not very valuable.
  • Johanna Rothman recounts a story of her encounter with a manager who discouraged his people from bringing him problems.
  • Martin Webster continues his series on leadership models with a detour into motivation theories, and John Adair’s Action Centered Leadership model.
  • Brett Beaubouef suggests that we should earn the right to challenge the requirements we elicit from our customers.
  • Chuck Morton continues his series on deconstructing project management with a look at the nature of program management.

Agile Methods

  • Bob Tarne notes the biggest challenge for organizations embracing Agile methods for the first time: the time commitment required for business people.
  • Mike Cohn provides interesting examples of “decorating” user roles in user stories, by adding simple (but meaningful) adjectives.
  • Jesse Fewell finds a better tool for representing Scrum roles and responsibilities than the RACI chart: an “Owns-Helps” chart.
  • Craig Brown shares an interesting diagram that helps explain what practices play to the strengths of different cultures.
  • John Goodpasture explains why Agile is, by nature if not in practice, a recursive methodology.
  • Venkatesh Krishnamurthy tells a simple story of two waste bins that speaks volumes about changing behavior.

Working Smarter

  • Mike Donoghue has a few tips for the traveling IT consultant. Or as I classify myself, the migrant computer worker.
  • Sonia Liang wants to help you quit an anti-productive habit: multi-tasking.
  • Alina Vrabie explains why Inbox Zero is so hard to reach, and nearly impossible to maintain.
  • Suzanne Lucas points to some recent research that debunks a few meeting collaboration “tricks.”

Podcasts and Videos

  • Cesar Abeid interviews Roy Gatling, on his experiences at a fast-growing firm (Dell) trying to perfect the practice of project management. Just 51 minutes, safe for work.
  • Soma Bhattacharya shares a TED talk by Kelly McGonigal on tiny interventions to develop willpower that she found particularly useful. Just 54 minutes, safe for work.

Enjoy!