Bee, good question. The factors you listed were:
1. Technology
2. Programming as a relatively "young" industry
3. The people working in the IT industry
4. Other people's perspectives of IT
5. The nature of software development itself?
There was a book published at least 20-25 years ago by an author named Brian (or perhaps Barry) Boehm. He did a doctoral thesis on the subject of programming projects of all sizes and why they did or didn't go smoothly.
1. Technology by itself is rarely the issue. UNDERSTANDING the technology is a much bigger issue. Using a brand new system = trouble in implementation. Using an older system = easier to implement - but you have to then worry about the applicability of the older methods to the newer problems. Fortunately, very few of the newer problems absolutely require all-new technology.
2. Programming as a young industry: No... medicine, construction, transportation, electronics, and other industries have new technologies, too. New discoveries in methodology keep those people going back to school. The fact of a changing base doesn't matter that much. It depends far more on how comfortable your staff is when working with programming projects. If you have a programming staff who grew up with programming as a way of working, you are in good shape. If not, ... bye-bye!
3. People in the IT industry: This subdivides into two parts. Your programmers and other techie staff must understand the details of what they are doing. Your business guys, marketing guys, and management team must at least take the time to familiarize themselves with the new paradigms of programming - but they aren't really new. Go find a book called
The Mythical Man-Month if you haven't read this already. Copyright date will be in the 1960's. This book should be mandatory reading for EVERYONE in the computing industry. Including - ESPECIALLY INCLUDING - managers who themselves don't program for a living.
4. Other people's perspectives of IT: This subdivides as well. Most of the "other people" don't count. But some groups that DO count are
a.) your prospective customer base
b.) your suppliers of techincal equipment
c.) your advertisers
5. The nature of software development? Yes, this was a biggie in Mr. Boehm's work. S/W development tends to fall on a continuum for which one end is "data entry to existing program" and the other end is "design & develop new programs that have never been done before." Obviously, if you have a job in data entry, it is a lot easier to manage as well as to predict data flow times. I.e. make completion estimates that have some meaning. If you are out on the leading, bleeding edge of development, though, you are acting as a primary researcher in - at best - applied mathematics. Projects get easier or harder in direct proportion to the amount of development required.
In a subsequent entry, the question of the role of management came up. In this case, good management is CRUCIAL. If your manager came from an assembly line environment and you are doing R&D, you are in for a massive headache. Your manager will not recognize that the nature of programming often includes original research components - some of which are in and of themselves worthy of consideration as a subject for a doctoral dissertation.
The worst thing that could possibly happen to KILL a project - or a whole department - is to put in a manager who has no programming experience or understanding, and who is by nature a micro-manager. If you have access to the
Dilbert comic strip (appears in many USA newspapers), start reading. Or get a "Dilbert" book. Watch the pointy-haired manager. I swear I have worked for the guy who was his behaviorial model.
Finally,
Harvard Business Review posts articles on this subject now and then. Bigges - for ANY business, ANY industry - have to do with a few simple abilities at the corporate - and departmental - levels.
a.) Communication - if you and your managers cannot communicate, that is bad. But it also kills you if you cannot communicate with your sales & marketing staff, your production schduler staff, etc. A breakdown in your communications with guys who SHOULD be on your side will destroy your project, your department, and your future credibility.
b.) Delegation - once a department gets big enough, you have NO ROOM AT THE TOP for a micro-manager. Middle managers - lower middle, to be more precise - can survive as a micro-manager. Mid-to-high level management MUST NOT be micro managers. Otherwise, you choke schedules down to where the critical path flows through the MANAGERS as though they were a production resource.
c.) Autonomy - the natural consequence of true delegation.
d.) Isolation - to prevent interference with the programming department by other departments that are not directly involved with programming actions. In particular, keep the Marketing & Sales staff at bay - with armed guards if needed. As mentioned before, you MUST prevent voluntary changes to your project design once you get past some pre-determined point, such as that point at which your inter-program interfaces are about to become reality.
Do NOT allow (d.1) Mktg/Sales to dictate production schedules (d.2) Mktg/Sales to sell anything that doesn't exist yet (d.3) Finance team to cut your development budget without involving the Sales team. Yes - play both ends against the middle in this case. HOLD A HARD LINE on needing every hour/dollar of the development budget in order to finish a project. OR ask the Finance guys and Sales guys to at least come to a consensus on what the Sales team didn't really want to sell. (That'll give you at least another month while the bloodletting occurs between those two groups...)
There are several other principles, but these are the ones I have learned in my (too-many) years in commercial as well as government programming.
