The arts of Project Management and Product Development are both deeply rooted disciplines in their own right.

It has been a long standing tradition for IT departments to place Project Managers at the helm of software projects.  This practice originated years ago with government projects, principally from the DoD, where modern templates of large-scale software development and integration were etched, patterns that were later imitated by private sector corporations.  By the 1980’s government policy makers and academics were united in encouraging the view that project success and failure was predominately a function of managing the Iron Triangle (scope, quality, and cost).  It was thought that Quality could be inserted by rigor and brute force, a.k.a. Six-Sigma, CMM, ISO-9000. Attentions were turned to the Project, not the Product, as being the most important thing to manage.  The art and science of Project Management as a distinct discipline evolved rapidly and Project Management as a leadership function was incorporated into almost all government funded projects; and surprisingly, into many corporate IT (formally known as Data Processing) shops.

Despite the widespread trend, part of the commercial sector resisted putting Project Management at the top of the food chain.  Many successful technology industries, outside of IT, did not put Project Managers at the helm of projects.  Instead, they pick product champions as leaders.  These people own the “whole product” and its development end-to-end, inside and out, soup to nuts, budget to bolts.  They manage with the philosophy that the Product is the center of importance, not the Project.  The titles given to these leaders range from Product Development Manger to Chief Engineer, Head Designer, Product Lead, or Product VP.  In a “product-centric” environment, the Product is important, not the Project.  When the difference in role is more than just in name only, the Product is managed, not the Gantt; ROI is achieved, not estimated.  This approach has driven engineering productivity and product innovation in industries ranging from cameras and TVs to automobiles and everything in-between.

In places where product-centric management competes head-to-head with project-centric management, the competition is a smack down.  Whether it is Toyota’s ability to design a new car model in slightly over 1-year (whereas GM takes almost 4-years), or Burt Rutan’s building of an operational manned spaceplane for $25 Million when it takes NASA over $1B to build a barely flyable scale mockup, the results are almost always unambiguous: Project-centric management simply fails to deliver on either cost efficiency or innovation.  At the end of the day, what else is there?

The results are even more skewed when looking at software and IT products.  It is common to find cost differentials of two orders of magnitude for the same or similar functionality between projects where product-centric leadership goes head-to-head against project-centric leadership.   (Example: Page 27 of this link: Florida vs. Minnesota’s SACWIS).

IT projects are about creating products, usually one-of-a-kind products.  Success or failure is determined by a collage of factors.  Some of those factors are project management in nature such as meeting external commitments, planning resources, and adhering to budget.  However, most of the factors driving success and failure have to do with the product itself.  With an IT project, factors like meeting schedule are most affected by the content of the product and the techniques used to synthesize that content.  The content of a product and how you go about putting it there influences schedule, cost, and quality even more so than the raw productivity and the PERT.   

With due respect to the art of Project Management it is completely inappropriate for leading the typical IT development effort.  Project Management is indented to be administration, not leadership. Its purpose is to formulate plans, track progress against a plan, collect and analyze measurements, contain costs, control productivity, and apply formal risk mitigation strategies to cope with variances between assumptions and reality.  To any development effort these are all necessary administrative skills and a great PM can make a significant contribution to almost any project.  However, you don’t put a traditional heavy-weight PM at the helm of product development.  E.g. Burt Rutan doesn’t work for his PM, the PM works for him.

That’s not to say that some people with the title Project Manager aren’t secretly skilled as Product Development Managers, because many (in my own personal experience) are.  Sadly though, the practice of relying on the title “Project Manager” as the leadership role actually discourages the use of Product Development Management at the helm of a project.  In reality most project-centric environments produce mediocre products and yield projects that appear perfectly well managed until they slip near the end of the Gantt, mostly due to issues with inadequate flexibility and customer acceptance (or lack thereof).

PM’s should be at the helm of certain types of projects.  PM’s should run projects where execution is largely driven by planning and when efficient Gantt execution is the key discriminator between success and failure.  Donald Trump (on the TV show The Apprentice) uses high-dollar Project Managers as leaders quite effectively in his companies; setting up events, overseeing construction projects, managing B2B relationships, and etc. There are many types of projects in the world that can be effectively run by PMs, just not in IT.

In the real world of one-of-a-kind custom technical systems the day-to-day tradeoffs are far more complicated than scope, quality, cost, and schedule.  The tradeoffs require a deep thorough understanding of the science, skills, steps, methods, and risks inherent in that type of product.  Making wise compromises depends on adhering to a robust and cohesive vision.  A compromise to one aspect of a product must be offset by something excellent in another aspect.   

What about the Gantt?  

Gantt is not and has never been the silver bullet to project administration.  Nuff said!

Project Management is a serious discipline requiring years of training and experience, it is a career and a specialty in itself - focused on project administration and business operations.  Product Development Management is also a serious discipline requiring years of training and experience – focused on evolving ideas into technology, turning at-risk dollars into successful products acquired.

I always get asked why so many IT projects appear to be circling the drain. 

Inevitably, if a project is having trouble it is because it does not have a Product Development Manager or equivalent at the helm.  That single factor makes more of a difference than any combination of things you might otherwise do to fix or save a project.