Steve Jobs didn’t ask for my advice about the merits of delaying the release of Apple’s next operating system (code-name “Leopard,” for those of you who live in the Land of Vista), in order to ensure that its much-vaunted iPhone product will ship on time in (late) June. And I have no spies, anonymous sources, secret microphones in the conference rooms, or access to confidential memos. So my opinion about the delay is probably no more (or less) credible and relevant than any of the other of dozens of bloggers, journalists, industry analysts, Wall Street investors, pundits, geeks, nerds, customers, and would-be customers who have been chattering about Apple’s announcement in recent days. But I think there are some useful lessons for project managers and software developers to learn from the events, regardless of what’s really going on inside the magic kingdom in Cupertino.

As blogger David Weiss observed in an April 12 posting entitled Apple Slips Leopard to Oct 2007, “There are 3 variables in you can change when managing a project: scope - how big it is, resources - how much money and people can allocate and time - how long the project will take. It looks like Apple reduced their allocated resources for Leopard, and without a corresponding reduction in scope, they were forced to increase the time the project would take.”

So, more than anything else, Apple’s announcement was a very public, and I believe very mature, acknowledgment of reality; and the acknowledgment occurred roughly two months before the previously announced “deadline” of June. You might think that such an acknowledgment is obvious, or just “common sense”; but you’d be amazed how many project managers — and their bosses, and their bosses’ bosses, and so on, right up to the CEO — will often deny reality until a week, or even a day, before the deadline. In a company whose culture is “management by edict,” senior management and middle management often like to believe that if they issue an edict that a new software-intensive product will be finished by date X, then by God, it shall be finished by that date.

Of course, without knowing the “inside story,” it’s hard to know whether Steve Jobs pounded his fist on the conference-room table, threw a temper tantrum, and issued multiple edicts — or whether he reviewed the PERT charts and critical-path estimates, and calmly accepted that development (or testing, or whatever) wasn’t proceeding as quickly as needed. And it’s impossible to know the extent to which — if any — the team leaders, and various hierarchies of project managers near the bottom of the organization, pushed back and said, “No! Even if you whip us and beat us, and make us work 24 hours a day, we’re not gonna be finished in time!” But one way or another, it appears that reason prevailed.

Actually, David Weiss’ assessment of Apple’s choices is a little simplistic, and I’d also love to know whether Steve and his lieutenants considered some other alternatives. They might have considered the so-called “Chinese Army” approach of adding an enormous number of additional developers to the project; after all, Apple has enough cash to hire as many developers as it wants, and it could probably bring in an arbitrary number of contractors with 24 hours notice. But I’d like to think that they key Apple project managers are aware of Brooks’ Law: “adding more people to a late software project just makes it later.” Whether or not the original schedule could have been maintained if Apple had hired substantially more developers at the beginning of the iPhone and Leopard projects is hard to tell, without much more information; but attempting to do so two months before the deadline would be a disaster, as Professor Brooks first observed more than 30 years ago (in The Mythical Man-Month, a new 20th-anniversary edition of which was published in 1995).

Similarly, Apple could have considered reducing the amount of functionality to be delivered in either Leopard or iPhone — therefore reducing the “size,” in David Weiss’ terms, or the amount of software that had to be developed. But if such a decision was to be made, it needed to be made during the initial planning sessions, or very early in the development phase, if it became evident that things were not going as quickly as had been planned (such a decision falls under the heading of “triage,” in my Death March book). In any case, it’s too late to consider trimming functionality at such a late stage, when the code has been written and the programmers are in the midst (or even the final) stages of testing.

And Apple could have decided to ship a buggy product, and hope that the innovative features would be so dazzling that customers would overlook the problems and wait for an update — i.e., version 11.5.1 of Leopard, and whatever the next version of iPhone will be called. But this is a very risky strategy indeed, given the fierce competition between Leopard and Microsoft Vista, as well as the competition between the forthcoming iPhone and the dozens, if not hundreds, of other smartphones in the marketplace. iPhone may indeed be dazzling, in terms of features, but if it gets a reputation for being too buggy to use, it could die a premature death.

So, from the perspective of product management and project management, it looks to me like Apple made the best decision it could, under the circumstances. Maybe it should have done a better job of planning a year or two ago — but that’s water under the bridge, and it’s too late to do anything about it now. Yes, it could have shifted resources away from the iPhone team and decided instead to ensure that Leopard would come out on time. But Leopard is — no matter how much I look forward to it, for my own use — an evolution, whereas iPhone is (or at least claims to be) a revolution. Yes, Apple may lose some revenues from college-bound students who would have been more tempted to buy a Mac if there was a shiny new operating system; but if it was iPhone that got delayed until October, instead of Leopard, Apple could well have lost its opportunity to make a strong enough entry into the smartphone marketplace to ensure its survival. There are also rumors that perhaps Apple had some contractual commitments to Cingular for a June release of iPhone, and that there could have been serious penalties if delays occurred; I have no idea whether such rumors are true.

As a consumer, of course, I have an entirely different opinion about all of this. I need to think about the impact of Apple’s decision: I had been thinking of getting a new Treo phone from CIngular, but if iPhone is really going to arrive in June, maybe I should wait. I was going to get a new Mac Pro laptop to take advantage of all the cool new features in Leopard (especially the ability to run Windows and OS X concurrently), but now maybe I’ll wait. On the other hand, I’m down to less than 10 gigabytes of hard disk space on my laptop, and I don’t know if I can keep going until October.

And as a typical consumer, what I really want is Leopard and iPhone — and I want them both now. And I’d like the iPhone to cost $50 instead of $500, and I’d like Leopard to be free. And I’d like every program that runs on my Mac to run on the iPhone — after all, they’ve both got Mac OS X as their foundation, right? And while I’m at it, I’d like a free pizza and beer to go with it. How about it, Steve?