[jordanbeiber]

Projects are necessary for things that are built to last and not change much during their lifetime:

- a bridge

- airplanes

- most houses

- etc

Hardware comes to mind - it’s all hardware on the list, basically.

Software (outside certain realms ofc) like this? I’ve been, like many others here, doing this software thing for 20+ years now.

Big and small, I’ve basically never seen anything spawned from a project-driven organization actually deliver great results.

Most software is supposed to change, indefinitely - that’s the point!

Everyone in this day and age should know that requirements change over even short periods of time, so why even bother trying to pin them down in detail up front - you’re going to do everyone involved a disservice.

There is something to this agile thing and a “project” is it’s anti-pattern.

Not mention how much a quick feedback loop will learn you about the operation side of things.

Operations and change, it’s all you can build for and that is best done one step at a time.

(This joke of a platform is spread across multiple (5?) vendors/partners no less. A couple of them probably started just for this, backed with vc funding. It’s most likely a glorious mess!)

End rant.

[scooble]

I suspect that one cause of this is the fact that these contracts need to be rendered for, which means stipulating the requirements at the beginning so bids can be produced. So a change of approach would necessitate a change in how how contracts are awarded.

[jordanbeiber]

What you describe is the real change now when “digitalization” has popped up again. Back to the future!

It’s not going to be a technological shift - it’s a different approach to software and forming teams around it.

I’m writing this and it kind of echoes Brooks words in “the mythical man month” - it was written in the 70s.

[globular-toast]

The trick is to make your projects tiny, not big. Instead of "build an all-encompassing system that does everything" you do "solve this very specific business problem". You could call these little projects sprints or something.

[throw0101a]

> The trick is to make your projects tiny, not big.

Gall's law:

> A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.[9]

* https://en.wikipedia.org/wiki/John_Gall_(author)

[bborud]

Oh, be careful.

At my previous employer there was the concept of the "90 day sprint". Top management use the term without irony. All they have done is substitute "sprint" anywhere you would say "quarter". So now they are agile. I wish I was making this up.

[jordanbeiber]

Yeah, it’s not about what words you use, it’s about how you act and work.

[jordanbeiber]

Think big, act small comes to mind.

No tricks really, just common sense, right? :)