[drieddust]

As someone who works in same space, I can say this is happening because unrealistic expectations of customers are not challenged by bidding Vendors because they fear losing the project. This in turns happens because customer tries to outsmart vendors by pressing them for reducing the timelines to absolute impossible. If any vendor tries to play by the rules, they are thrown out. Smart vendors respond by crafting the contract smarty. Skipping training is one such example. It was crucial but ....

In the end project is either canceled or goes over budged or barely manage to deliver anything.

[Bertio]

Customers love to be lied to; in a recent set of presentations I was favoring the vendor who was presenting reality but the winner chosen by the business evaluators was the vendor who brought in the glossiest presentation and glossed over the complexities and the frightening part expressed a comfort with ever changing requirements. They were put off by the vendors who boasted about zero change requests and making their timelines but liked the vendor who proposed a fantasy timeline with no promises.

[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...).

[foliovision]

A responsible vendor then declines to take the project (smart decision) or executes anyway. We've been in the situation a few times where what started as an attractive project with a reasonable budget turned out to be an underestimate and we barely earned back our salary expenditures on the project.

Those companies did continue to do business with us though and we've normally earned back our losses and more on future projects.

That's what honest vendors do. That's not what IBM did.