I read this with interest as I have been involved in large scale IT development projects for various corporations for the better part of 15 years. This memo makes it appear as if the problems in the project were execution related: bad management, poor quality control, bad architecture, performance problems, etc.
In my experience, it is actually not that common for an experienced team to fail largely on execution problems. Rather, as I like to say (call it Renn's Law if you'd like): "Most failed corporate software projects failed before the kickoff meeting". Usually the signs of failure were there all along, before the project even officially got started.
Here are some of the key things I've seen lead to problems, most of which are not directly related to the core development (design, build, and test) of the project:
- Lack of an identified executive sponsor
- Failure to identify a limited subset of people who are empowered and responsible for articulating the business requirements of the system
- Lack of clarity as to the actual goals to be achieved or the underlying problem to be solved.
- No shared vision of what a successful outcome would look like among the various stakeholders
- Project positioned as an IT-centric solution to a business-centric problem without a corresponding business strategy, process, and change management plan in place.
- Insufficient resources (time, money, people) allocated to the project
- Lack of qualified staff in key roles (data architect, functional lead, etc)
- Poor governance and scope control
