Requirements and scope not documented - Early Warning Signs of IT Project failure

It is important to to define in writing in the initial stages the expected functionality arising from an IT Project. While this definition might not be fully detailed at this point, until the analysis/design process has been completed, the requirements should be sufficiently descriptive that any non-IT manager can understand what is proposed. The initial documentation should describe the scope of the project. It should also describe any important business features not included at this point. 

In today's environment of 24/7 on-line, web based and social media applications the requirements should specify the performance and reliability expected of the system.  I've seen several projects where the leaders can produce massive dense documentation on the functionality of the system, yet no real detail on the expected performance of the system. It is crucial to understand the costs of appropriate performance levels and reliability right from the start of a project. It can be very difficult to retrofit performance/reliability into a system if this has not been considered from the outset.

One of the many budgets used to control a project might well include a performance budget where the resources and infrastructure required to meet the projected processing and response times of each major component are monitored.

It is important the business signs off those functionality/ scope/ performance/ reliability requirements at the early stages of the project. It is important that this is "informed consent". One of the responsibilities of the Project Manager/Director is to ensure business executives understand what they are signing off and have the time to question what is proposed. Real signatures should be on a document recording that agreement.