Hi,

What do you think are the problems software projects have? Does the following have anything to do with it?

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?


Regards,
B

This sounds like a classroom type question and not something you'd hear veteran programmers/IT person ask. Why - All of the things you list (and many more), are the reasons for problems in the life cycle of an IT project :rolleyes:

2. Programming as a relatively "young" industry

I didn't pioneer programming, ie I wasn't the first, but have recently retired after 43 years in the industry, if that is considered young when will it grow up? I guess that as it has gone through many evolutions in that time, never.

I'd just blame the salesmen, managers and accountants for all failures.;)

Brian

The biggest problem is change management.

Generally as you implement more efficient system you will replace some employees and force retraining on others. This is a very stressful situation for some people.

This last year I rolled out a project that completely consolidated the admin operation of small subcontractors. The system eliminated 30% to 50% of the admin work force.

What ended up happening is that the older employees, too committed to there antiquated systems, retired.

It was interesting to observe, they tried in every way to sabotage the implementation, and frustrate my efforts. In the end they failed, because one of the owners of the company took a liking to the new system ( it saved her 1 day week for just the part she used).

So the most difficult part of that project was definitely managing the change.

I didn't pioneer programming, ie I wasn't the first, but have recently retired after 43 years in the industry, if that is considered young when will it grow up? I guess that as it has gone through many evolutions in that time, never.

I'd just blame the salesmen, managers and accountants for all failures.;)

Brian
A lot of people argue that programming is relatively new when compared with other professions. e.g. medicine...etc

This is a common point of discussion (typically everybody talks about it but nobody does anything) among developers and project managers working in enterprise organizations where development projects often stall (if not completely fizzle) and lousy applications and unhappy users follow. That's the joy of Access -- it's typically used for single office solutions where there aren't multiple interests and egos and disparate technologies and skillsets clashing...

A lot of people argue that programming is relatively new when compared with other professions. e.g. medicine...etc

And they are all young compared to prostitution, so what? Industries/skills are changing all of the time the way we programmed in the 60s bares no relation to that now, its not programming thats the problem for IT projects, its nearly always management.

Brian

And they are all young compared to prostitution, so what? Industries/skills are changing all of the time the way we programmed in the 60s bares no relation to that now, its not programming thats the problem for IT projects, its nearly always management.

:D

what is in management that make projects fail?

:D

what is in management that make projects fail?

IMHO - The main problem with management that causes IT/IT projects to suffer is that the business does not maintain and own adequate process flows which are needed to map and maintain the IT requirements.

Think I with Ken on the Management bit. generally they do not fully understand in detail what they wish to achieve. hence you get at best 80% of the true requirements. That's problem 1. Secondly they have no concept of freezing a specification.

I find that they are always chasing the last buck to continue teh promotion of their image. Thought should be given to spend a bit, save a bit more than you spent, then spend a bit more etc. What actually happens is the reverse. here is tye spec...oh yes its frozen....then er how about this must have...extra cost, delay,complaint er how about this must have...etc

Or am I getting cynical

L

Think I with Ken on the Management bit. generally they do not fully understand in detail what they wish to achieve. hence you get at best 80% of the true requirements. That's problem 1. Secondly they have no concept of freezing a specification.

I find that they are always chasing the last buck to continue teh promotion of their image. Thought should be given to spend a bit, save a bit more than you spent, then spend a bit more etc. What actually happens is the reverse. here is tye spec...oh yes its frozen....then er how about this must have...extra cost, delay,complaint er how about this must have...etc

Or am I getting cynical

L
What do you mean by "freezing a specification"?

Len's reply was on the button, and I'm sure that what he means by "freezing the specification" is that at some point in the project's life no more changes should be requested. Changes to the original specification can arise for 3 basic reasons
1 The specification was wrong
2 There is a change to the legal requirements
3 Somebody has a new idea/wants an enhancement

2 must always be acted on, 1 probably needs to be acted on, 3 should be left to the next release of the application, but although people readily accept versioning for infrastructure software such as operating systems , database systems etc, firms are reluctant to accept this for applications, the result is changes are often demanded right upto the last minute, this results in a poor structure and insufficient testing.

Brian

Len's reply was on the button, and I'm sure that what he means by "freezing the specification" is that at some point in the project's life no more changes should be requested. Changes to the original specification can arise for 3 basic reasons
1 The specification was wrong
2 There is a change to the legal requirements
3 Somebody has a new idea/wants an enhancement

2 must always be acted on, 1 probably needs to be acted on, 3 should be left to the next release of the application, but although people readily accept versioning for infrastructure software such as operating systems , database systems etc, firms are reluctant to accept this for applications, the result is changes are often demanded right upto the last minute, this results in a poor structure and insufficient testing.

Brian
That's clarifies it. Thanks.

Len's reply was on the button, and I'm sure that what he means by "freezing the specification" is that at some point in the project's life no more changes should be requested. Changes to the original specification can arise for 3 basic reasons
1 The specification was wrong
2 There is a change to the legal requirements
3 Somebody has a new idea/wants an enhancement

2 must always be acted on, 1 probably needs to be acted on, 3 should be left to the next release of the application, but although people readily accept versioning for infrastructure software such as operating systems , database systems etc, firms are reluctant to accept this for applications, the result is changes are often demanded right upto the last minute, this results in a poor structure and insufficient testing.

Brian
That's clarifies it. Thanks.

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.

The Doc Man,

That's a very interesting post. I believe that the culture of a team/organisation is very important because if you can't communicate to your manager/staff, you can't go ahead.

Do you think having a team of unexperienced programmers who communicate well is better than having a team of very experienced programmers who don't communicate properly?

How important is planning in projects even though plans should be reproduced as things change?

How important is planning in projects even though plans should be reproduced as things change?

Without a plan you cannot manage or predict the impact of change, infact it is the probability of change that makes detailed planning important.

Brian

I have heard it say that

If you have no plan then you plan to fail.

Not all plans are successful but at least you have thought about it and the experience should lead you to improve your planning

L

Do software projects really need experienced managers in IT or any managers will do?

Would a very good Nuclear Physicist be able to discuss the progress and problems of the Building of a Bridge with Civil Engineers.

No I think the Project Manager needs to be knowledgeable in the field otherwise he could be fed an absolute load of garbage from all directions

L

Edit

But there again if he has the right people on his team..... but who is to be sure of that ?.

Len is absolutely correct. Back in the 60s as a junior I had an arrogant rude non IT project leader, a week before we were due to roll out he asked for a change to a form layout which he had refused to discuss with me earlier , I said it would take 10 days, so the whole of the organisation saw and complained about his lousy design. It actually took less than a day as any IT guy would have known.

IT Projects need lots of skills at management level, IT skills being one of them.

Brian

Bee,

Do you think having a team of unexperienced programmers who communicate well is better than having a team of very experienced programmers who don't communicate properly?

The way I see it, inexperience is not a barrier to success - but failure to properly communicate is almost always fatal. You can NEVER allow your situation to devolve into an adversarial situation, which is exactly what you get when you stop talking.

Do software projects really need experienced managers in IT or any managers will do?

Mr. Boehm's book was quite thorough. One of the more important factors was that every project should have an experienced lead designer and/or programmer. This person's experience would, by communication and osmosis, become available to the junior staff.

This is why many "how to" books on management use the concept of frequent reviews of progress at a detailed level. (Yes, this sounds like being a micro-manager, but I'm talking about low-level, single-project management. See my earlier comments about low-level micro-managers.)

If your junior staff gets gently nudged in the right direction by your senior team leader, you can expect good things to happen. For this reason, your team leader must have reasonable interpersonal skills. An arrogant, know-it-all team lead is a project killer.

In many cases, Mr. Boehm suggested that the effect of more or less experience was relatively minor. With an experienced leader, having a less experienced staff was usually just a 15% difference in flow times. Having a team with NO experience, top OR bottom, was a lot more expensive, at least 30% if not more. In fact, there are several places where experience counts and they are all different in effect.


Know the hardware (if you are directly interacting with it).
Know the operating system (so you can make good system calls)
Know the language you are using
Know the subject matter (i.e. if it is an engineering project, don't hire accountants.)
Know corporate or departmental methodology


Just remember that "knowledge gravity" applies here. I.e. knowledge flows down from the top. So if your top guy is a know-nothing, you are already in deepest doo-doo. Because crap ALSO flows down from the top. You NEVER EVER give an unknown quantity the lead on any major, corporate-crucial project. Make your unknowns 2nd in command for their first project and let the experienced leaders evaluate the newbie.

In the final analysis, a company that hires a non-IT person to manage an IT shop can effectively kiss off that department UNLESS: The new person has experience in a DIFFERENT type of engineering applied-esearch situation.

My original comparison was "assembly-line" mentaliity vs. "research-project" mentality. Whether the person is specifically IT-cognizant is less important than that they recognize the extreme volatility of an IT development schedule. I once worked for an electronics engineer who also ran an IT development shop as his second hat. He wasn't bad because he knew it was development work, not a cut-and-dry (cut-and-paste?) operation, that was slowing our progress on our big project. So though he wasn't up on the terminology, he understood the nature of the beast.

If your managers are like one of my Marketing Engineers from about thirty years ago, they all think that programming is just "a test and a branch." If you ever hear a Marketeer say that, do the world a favor and KILL that S.O.B. before he further pollutes the gene pool. Or give him some haughtily delivered rejoinder - like "Yes, but you pay me because I know WHICH test and WHICH branch to use."

The Doc Man,

I am not familiar with the types of managements you mentioned on your posts e.g. micro-managers...etc

I guess this sort of describes what Doc is saying :

http://ezinearticles.com/?Micro-Management-Has-a-Negative-Growth-Effect-on-Business&id=70027

I guess this sort of describes what Doc is saying :

http://ezinearticles.com/?Micro-Management-Has-a-Negative-Growth-Effect-on-Business&id=70027
Good link. Thank you.

rak: good link.

Yes, a micro-manager is the ultimate pain in the employee's arse. What it comes back down to is that the micro-manager doesn't trust any employee to make any decision any time any where on any subject of any size. So in other words, the micro manager cannot DELEGATE effectively. S/he must be intimately a part of every decision any time a decision must be made. And this leads to failure because in a major implementation project that has any chance to succeed, the major decisions should have ALREADY been made before anyone started writing the first line of code. So a micro manager should not be making massive decisions during a project anyway.

The only ways to defeat a micro-manager are to assassinate him/her, overwhelm said manager with so many details that even S/HE has to back off, or to simply allow the manager to fail miserably through the tried-and-true method called "malicious obedience.' When the micro manager says "do XZY" (even though everyone else in the world KNOWS it should be XYZ), get it in writing and do it. When the micro manager's manager sees no progress on the charts after enough time, an inquisition will come about. And that is where your records of orders in writing will get the micro manager in more hot water than a missionary in a cannibal's stew pot.

In any case, there is one time - and only one time - that a micro manager is worth anything. And that is as a manager of a true assembly-line operation where individual employees don't have choices to make in the first place. Even then, only as a low-level manager, not as a top-line manager.

This sounds like a classroom type question and not something you'd hear veteran programmers/IT person ask. Why - All of the things you list (and many more), are the reasons for problems in the life cycle of an IT project :rolleyes:
lol..hahaha