Take that project you are currently running, and imagine, just for a second, that it came with only 3% budget overrun. Most of people in software industry would call it wild success.
In motion picture industry, however, trampling measly 2% or 3% over initial budget would be considered a failure.
While movie industry and software industry are seemingly light years apart, there are many things these two have in common, and there are obviously many things we can learn from them.
James R. Persse in his Hollywood Secrets of Project Management Success does exactly that: analyzes the project management best practices as practiced in Hollywood, and draws parallels with software and IT industry.
Isn’t it intriguing to think of a movie production project and an IT project, and then take it as granted that an IT project can easily burn 25% more funds than initially allocated, while movies consistently come almost exactly at budget? What does Hollywood know about project management that we in IT don’t?
First, James Persse explains why Hollywood is relevant. He could have easily picked building or road construction, or shipbuilding, all of which fairly often deliver the scope within given time and budget constraints, but he picked the movies. He found 8 important similarities between movies and IT:
-
Both deal in intangible product development.
-
Both are shaped to directly address a deadline-oriented business need.
-
Both require significant investments.
-
Both are built against a specification open to change.
-
Both rely on specialized production protocols and technologies.
-
Both require the integration and collaboration of specialized teams.
-
Both require careful analysis, design, execution, and integration.
-
Both must be thoughtfully delivered to their target audiences.
After establishing the relevance of Hollywood best practices for IT, Persse moves to analyze how Hollywood manages to consistently deliver the scope within given time and budget, and explains the Hollywood production system, which is sort of project methodology and set of best practices for producing movies. Not surprisingly, it distills down to a simple framework of five phases: development, preproduction, production, post-production and distribution.
When mapped to PMBOK, development roughly corresponds to project initiation, with pre-production mostly having to do with project planning. Other three phases could be mapped to project execution and monitoring. (Persse says that Distribution maps to closing, but IMHO it doesn’t, or it only partially does.)
This system, according to Persse, is the way the whole Hollywood does movies. If you do it that way, you succeed; if you don’t, you are playing the odds.
The book is structured around this system that has worked for Hollywood for a long time, and analyzes how the project cycle goes through these five phases.
In first three phases, most revolves around the script, the Hollywood’s equivalent of requirements document, and although Persse found out that the script also changes, it tends to be more of a holly scripture than requirements are in IT. For Hollywood, it is much easier to set Big Requirements Up Front (the notorious BRUF in agile methodologies) than it is in IT. Hollywood can do BRUF, so they do it. The IT mostly can’t.
Inside this system lurks the biggest difference between the IT and Hollywood: movie industry exists for more than a hundred years already, they had enough time to develop and establish best practices and to prove them in practice to such an extent as to tell everyone: this is how you need to do movies; and everyone can trust it works, because it has worked for the whole industry for decades already. IT industry is very young, and exists for a few decades. We are still learning.
In my opinion, a big issue with IT is that we are like being smart, preferably smarter than the next guy. We like to improve things even before we know if improvement is really needed. We invent methods before we know why existing methods succeed or fail. That’s why we have so many systems and methods, which all work, and none does. The things are slowly sorting out, there is more appreciation and adoption of proven formal methodologies today in IT than there was ten years ago. But we still have to go a long way to get where Hollywood is already.
It doesn’t have nothing to do with complexity, diversity or rapid development of IT technology. Movie industry has been through all this, they also need to cope with new technologies, new equipment, new achievements; and they do, but they don’t touch the system.
For me, this is the most important lesson learned from Hollywood: take a proven method, and follow it, don’t question it. Then learn. Then improve.
All in all, this is an interesting book. It is more of a mind teaser than of a methodology handbook. If you approach it that way, you’ll enjoy it more. But don’t expect it’ll teach you some arcane techniques you can employ immediately to deliver your next project at 1% cost variance and 700% ROI within 6 months. It won’t; it will teach you though, how important it is to follow the system that works.
Pingback: Navigate Into Success
Hi Babic,
This article is quite interesting and thought provoking. Very true, your thoughts on this.
Not always we can develop and deliver a 100% perfect software within the estimated time. But by following a proven method, like you have mentioned, we can ensure less failure and more success.
Thanks
Vaidy
@Vaidy: the book is even more interesting and thought provoking, I really recommend you to read it.
@Funkygraz: I don’t know what happened to the trackback, it’s kinda automatically handled, and I don’t have any influence over when and how it updates. Yes, it really makes you think: if an industry has a proven model which yields huge profits and only tiny variances over budgeted costs, year over year, would we people in software industry benefit more if half as much time we spend inventing new and improving existing methods we spent actually practicing those methods. Personally, I don’t think that web-based applications have any effect on manageability of development, it should all be the same. What web does bring, however, is leaner approach, more “standard features” adoption, and less customizations.
Personally I missed the trackback to your post on Sure step, go push your product more in these times of global recession.
A very interesting post though , especially since it makes the recent publications of the American movie industry’s annual reports a bit more understandable (Record profits).
I wonder if a shift towards more web based applications will make software development more manageable.
The web applications i see usually have a higher degree of user customization possibilities then legacy software traditionally had. That might have something to do with that.
ABout the other point, I definately agree. I see it in IT education, students are faced with a lot of different methodologies for short amounts of times in projects / classes / etc. Logically they are faced with failures / shortcomings in said methodologies because they are partially implemented or the fact that they lack experience.
Taking these experiences in mind I doubt a lot of upcoming students are satisfied with the methods they have faced and are already in a mindset to do it “better”. Personally I think I might learn a lot from reviewing myself on this, so thanks for more work ^^.