IT Employment

of things.
1) Correctly planned schedule for development.
2) A Coding Standard that works.
3) Programmers that have been smart enough to write portable code, or have a good knowledge of the code available to them for re-use.
4) A good team.

on point 1, sales team, and develpment team have to work together to come up with a delivery schedule that the customer can live with, the development team has to be involved in the requirements discussions in some fashion, to be able to give reasonable estimate of development time.

on point 2, the simplest way to set a coding standard: use the international standard for the language ie: ansi c / C++. clearly define what is meant by well documented / commented code. the coding Requirement for the company should be detailed in the documentation / commenting area, in clear, plain english [ or whichever language is used in workplace ] no legalese.

on point 3, every function that they write can be coded where it will only ever work in the software they wrote it for, or it can be coded to be re-used in projects that it will help later on in their career. If a programmer is not familiar with the libraries of code that are available to them in the workplace, then they will often be slower developing new software, as they are constantly writing new code that already exists.

on point 4, the entire company has to be a team, from every department, if there is anyone who doesn't feel that the company is a team then they are not as productive as they can be. This includes Management. the Sales rep that got the contract for the product is a part of the development team, they are the interface between the developers and the customer, their job has not ended until the customer has received exactly what they ordered.

ATITUDE If you have a happy work place SO'S
THE BANK. When you give employees the power
and resourses to accomplish their goals,
the sky's the limit. You only get out what
you put into project, plus that added amount
you have garnered along the way. REPUTATION
can go a long way and RUMORS will get you
nowhere.

As with any effort in life, some people unsderstand the difference between management of a process and being a figurehead.

Successful teams tend to have leader/coaches/mentors who are part of the effort who understand the process and are able to deliver.

Its a combination of factors.

Sometimes you have to slow down to speed up.....

What I mean by that is that the more thorough and painstaking a process you have for developing thorough requirements, and creating a realistic project plan, the more likely you are to deliver on time without the kind of stress you describe.

What often derails development projects are additional requirements which pop up once development has started, or bad assumptions on technical issues which lead to a dead end. The more time you spend up front, the less likely these are to happen.

James

The big one for me is the finite size of a piece of A4 paper.

What is this guy on about ?

Very simple, your project is going to be a disaster are if.
More stuff gets added but the resource stays the same.
The initial estimate of the required resource was considered too expensive, so some idiot agreed that it had been overestimated.
The estimates were not done by the people who had to do the work
Someone says half way through the project, you never said this wasn't in scope or
oh by the way, make it do this as well.

Developer's do not have psychic gifts, nor did they qualify for magic school, so relying on them guessing what you really wanted or pulling a tenner from behind your ear might not be a wise move.

I see it time after time. Nice plan composed by a set of business management types, fits beautifully on a piece of A4 and will always do so no matter what!

No plan will survive contact with reality to paraphrase someone who knew how to organise his sh1t.