Timing is Everything
I went to the Heartland Developers in Omaha a few weeks ago. It was a great user event for developers. When I got back I put some Lentils in a pan to soak to make some hearty soup. I got busy and forgot about the lentils. A few days later I opened the pan with the soaking legumes and they had started sprouting roots. The Lentils went from soup starter to plants, from possible nutrition to living growing things.
This reminded me of the value of timing. Timing is everything. Soaked for a night and you have soup. Soaked for a week and you have living plants.
Software development projects depend on timing too. Spend too much time on the wrong thing or at the right time and instead of software you have a lot of everything else. A philosophy of software development that I follow is very simple: plan at the macro level as briefly as possible, figure out which elements you can buy or reuse, and then build the core system outward. The last part is one of the most important parts of software development. Identify the core parts of the system, the most valuable parts, and put all of your energies into those elements first.
If the core features can be identified and built first then you arguably have a usable system very early. A usable system is going to demonstrate value to the customer, later trade-offs can be made for schedule purposes, and project is less likely to end up as a death march.
Many projects I have seen get bogged on too many non-essential details of project scheduling, building data access layers, arguing about coding standards, GUI s or GUI standards, or excessive design and modeling. Often core systems, especially those that leverage existing code or components from external sources, can be assembled in kind of a skunk works mode. Then, elements of a macro schedule can be converted to detailed micro schedules for sub-systems, again building from the high value, high risk, priority items out. Things that are often not high priority or GUIs unless you are building a new kind of GUI, data access layers, documentation, tutorials, schedules, and standardization rules.
A reason what I refer to as lower priority items are built first is that often teams are assembled and re-assembled early on and not everyone is sure of what they should be doing. The way you combat this problem is to build the core sub-systems early with as few people as possible to seed inertia and demonstrate feasibility. Then, after you have buy-in, a core working solution you can bring on secondary players, like testers, documentation people and trainers, and GUI fit and finishers.
On many projects, even pretty large projects one or two people that work well together can get the core system roughed out before a lot of people are needed. This is true of enterprise systems too. For example, too many players too early and the project quickly derails into planning and scheduling, how do we get all these people moving at once. The hard truth is you can't unless it is a team that is highly cohesive, that has worked together, and everyone already knows there roles. Few such teams seem to exist, except maybe at places like Google and Microsoft where many of the same people are working on an existing vNext project.
In 21+ years of completing projects highly formalized planning, modeling and design, and inception with large teams seem to cause most of the problems.Build software with a few people first, identifying the riskiest, most critical elements of the solution, and add the overhead of task scheduling, planning, and formality slowly.