The Impossible Deadline

Limes or Lemons?Another day, another question on a LinkedIn project management group discussion: “How to refuse your sponsor for the impossible deadline committed to by him?” Or, to put it another way, how do you tell him his lime is actually a lemon?

First of all, you aren’t refusing – you are simply calling his attention to reality. Good project managers are a force for truth. You can’t fit ten pounds of flour in a five-pound sack, as Dolly Parton once said, and no one benefits from spilling a lot of flour all over the floor, trying to make it so.

Exploring Alternatives

Explain why the scope to be delivered cannot be done in the time frame the sponsor outlined; ask if it makes sense to cut some things out of scope; then ask if there is budget to add resources. If the sponsor wants to make it about you, reply that you are simply doing the math – the project will not succeed, as currently envisioned. Ask what was the basis for the timeline that he provided. The answer will probably be about lack of support for the project at senior levels, whether it’s said that way or not, or about the sponsor’s personal ambitions. If you’re not making any progress with the cost or scope legs of the triangle, ask if it makes more sense to cancel the project. At that point, he’ll either deflate or explode.

Consequences and Culture

If you simply try to overcome reality (you can’t) in order to please this sponsor (you won’t), you’ll end up as the scapegoat when it becomes obvious the project is going to be late. Better to take the abuse up front, and get whatever credit there is to be had for putting the organization first.

Of course, I say this recognizing that, in some cultures it isn’t easy to stand up to authority. Deference and obedience to the manager are valued over loyalty to the best interests of the organization. I’m describing what I would do, with my American upbringing and cultural values. But even in our culture, it takes a lot of personal integrity to do all of this, especially when the sponsor is an ambitious tyrant. Before signing on to be a project manager, do a gut check: how would you handle this situation? Because you will face it, if you manage projects as a career.

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.


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.