In reviewing the software projects I have been involved with over my programming lifetime: I have noticed that the smaller and more highly targeted a software project is, the more likely it will be completed under budget and ahead of schedule.  This is not a hard and fast rule, and there are a number of mitigating circumstances along with some very visible failures.  The easier it is to get your arms around a project, the more likely it is that everyone associated with the project can understand the expected outcomes.

Does this mean we should divide large projects into smaller tasks, each more simply understood by the development team?  This is certainly the point of many software development methodologies, like Agile.  Are these methods "better" at producing results?  I think the jury is still out on that answer.  Large software projects do not seem to be completed more cheaply or on time with Agile, at least in my experience.  I have seen one spectacular failure of a large project using Agile.  My observation was that the Agile process was followed religiously.

So what is the best way to manage a project and complete it on time?  These are my observations:

1. Keep the target concept small and the expected outcomes simple and understandable.  It is in the best interest of IT staffing to have large, long term development projects.  This is why you need to fight this tendency.  What is good for the IT staff isn't necessarily good for the company or customer or the software project.
2. Keep the team small.  Large teams begat fiefdoms, turf wars and "us against them" attitudes.  You have to reject the tendency to build more levels of management into a project team.
3. Do not divide up a project such that the failure of one group or task is used as an excuse for all other groups to be late.  If an excuse to be late can be placed at someone else's feet, it will be.
4. Do not allow feature creep to destroy your projects.  One of the problems I see over and over again: long term projects grow new features exponentially.  As new knowledge of a process is discovered, or management changes, etc., the targets of the software under development change with time.  Keep your time horizon very short.
5. Don't bank your business on a single software project.
6. In general, fight the urge to turn a project into a bureaucracy.  This goes against the human tendency to create empires.  I believe this urge to create empires is the root cause of so many large software projects.  I also think it is why small, highly target projects are more likly to succeed.  Small projects do not offer the ability to build empires.  Managers tend to leave the work to the developers and maybe a technical lead.  Stuff gets argued about and then stuff gets done.