[dv_dt]

Yup, this kind of contracts game is what really needs modern innovation. I think the space is kind of living in an extensions of 70's assumptions with many decades of beauracratic rules added on to try to fix up fundamental problem. For another factor, it would be lower risk to allocate into many smaller projects and sign contracts in phases and sub-systems - but then the funding of the total project becomes more at risk politically, and then there is a higher technical load on the contracting dept to architect the boundaries.

[drieddust]

They are barely able to state the outcome of project so expecting them to do the necessary legwork to break projects into logical subprojects is too much to ask.

No disrespect but we have come to a point where IT have started appearing magical to pointy hairy bosses who think juse because it's software everything is infinitely malleable with no impact on quality, cost, or time.

[dv_dt]

If you don't have an organization that can break it down to a smaller projects then there is a question if doing it as one large project has a higher or lower chance of failure.

[drieddust]

Shouldn't that depend upon complexity of change but who cares. CIO have a short tenure so collecting the bonuses and leaving before house of card collapses works.

It's all about managing the personal bonus and career, who cares for the success 9f project?

[dv_dt]

It depends on complexity, but I think it's more of a situation akin to refactoring or rewriting a complex code base. A total rewrite is always an attractive thought, but a real focus on continuous refactoring in smaller portion at a time is often lower risk, lower cost, and faster in the end - and I suspect it's the same with large bureaucratic processes too. It's also a way to sharpen the skills of the organization in small steps with lower risks for failure (and improving future project steps...).