Sunday, June 30, 2019

Your Projects Should Start Slow in Order to Run Fast Later

Your projects should start slow in order to run fast later
I am a big believer of short and fat projects and I am very vocal about it. Because of this I often get asked if I propose to fast track projects and reduce upfront work.

No, I am not. On the contrary, I think more time should be spent on upfront work.

Yes, to keep costs down and maximize benefits you should keep implementation phases short and delays small. This should not be seen as an excuse for fast-tracking projects; that is, rushing them through decision making for an early start.

For smaller projects, this might be something you can get away with, but for large technology projects all you do if you hit the ground running is fail hard. Front-end planning and validation need to be thorough before deciding to give the green light to a project, or to stop it.

You need to go slow at first (during project initiation) in order to run fast later (during project delivery).

Unfortunately, many times the situation is exactly the opposite. Front-end planning and validation is rushed, bad projects are not stopped, important projects do not get the money/ people/management attention they need, implementation phases and delays are long, costs explode, and value diminishes.

In a nutshell: Stop the madness. Start slow, and run fast later.
Posted on Sunday, June 30, 2019 by Henrico Dolfing