How can any architect predict what the requirements of an IT project will be in eight years? Or what tools or technologies developers will have to work with in five year's time. Unless you are NASA and sending a manned mission to Mars, it is pointless starting any such project. Projects can be huge, but will be doomed to failure unless you can deliver a thin vertical slice of it in six months to a year.
In 1997, the Australian Customs Service began a process to replace its core information infrastructure. The aim of the Cargo Management Re-engineering (CMR) project was to create an integrated system for exchanging complex and varied import and export documents.
The ICS had to provide traders with a broad range of electronic reporting options while, at the same time, satisfy the legislative requirements of Customs. It would also help identify high-risk goods. Surely the requirement is simple enough if you start small?
Seven years later the massive IT program was reported to be at least one hundred million dollars over budget and nearly three years behind schedule. Under politician pressure it was rushed into production. Cargo was stranded at the docks for weeks, subsequently costing the government tens of millions of dollars in compensation.
The project was started prior to September 11 which completely changed the security landscape, so was probably already outdated by the day it was delivered.
How could anyone nine years ago predict what the user's requirements would be today?
Exception: This rule does not mean the entire project has to be completed within a year. It simply means that a demonstrable part of the core functionality (eg. processing a small set of imported cargos) should be shown to the stakeholders in a short space of time. You still need a big picture of where the project is going to go, and some basic “to be” architecture. Serious analysis should have been done - “do we have the data available?”. Tough high level decisions should also have been made - “does everyone agree to these functions are the priority?”. Just don't start building all parts at once. The more suitable the software is for the purpose it was designed, the less likely it is to match the original plan because the world around the project team always changes. The approach and contractual arrangement should be flexible enough to adapt to the changing needs of the customer.
