Most people in IT are familiar with the “iron triangle” of project management, whereby attempts to fix each dimension of scope, schedule, and cost results in a project that is extremely brittle to change. Since for most projects, change is inevitable, an experienced project manager will proactively manage the variability of one of the dimensions to hold the other dimensions in check. I’ve long held the view that holding schedule fixed and scope as variable provides the best control over projects. Cost follows schedule (as the majority of cost in software development is services).

 Holding schedule constant has a number of benefits:

• The project team is focused on producing the simplest solution that will work opposed to engineering for “just in case” scenarios.
• Project momentum is maintained, which is an important psychological factor in project success.
• Dependencies outside the immediate project team are not impacted, such as business plans, time committed from the business, and external testing.
• The project has more options in response to a change.

It is tempting to delay a project milestone when a choice is unclear or input has not been received from every stakeholder. Even small delays have a significant cost. To put this into perspective, let’s assume a small project of 5 full-time people over 120 days (around 6 months) with a daily per person cost of $800 and these are the only costs that are accounted for. A delay of only 3 weeks represents 12.5% the cost of the project, and if the supplier of the resources is a vendor who expects a 10% profit, then the project has become loss making. The customer may seek a fixed price to mitigate this risk, so the vendor add 20% contingency to the price. This gives the vendor less than 5 weeks of leeway but now there is less incentive for the customer to keep within the deadlines. Change management can protect the vendor but creates overhead costs for both parties.

 The question should be whether the delay in this case is justified based on material impact to more than 10% of the scope of the system, and that the issues cannot be resolved in a subsequent release (a benefit of an iterative release plan).

 My point is not that all delays are avoidable, rather that schedule requires intentional management and successful projects are more likely to have sponsors who manage the schedule ruthlessly. Invariably, the death of a software project is from a thousand cuts, not a decisive blow.

 The reason it is harder to develop simpler software is because it requires management of people not of technology. Other creative industries such as advertising are more likely to see the truth of this - where the value of less is worth more.