A take on injecting reality into software planning at any stage

  1. Justifies using an overall timeline for software development by providing responsibilities that flow both up and down the organization and makes this information actionable.
  2. Balances the stakes of creating estimates up and down the organization, causing someone pushing to make the timeline shorter to take on greater risk, which is now not normally true.

How to impose responsibility on parties to a project plan without just making everything into an interminable crunch that winds up destroying everything

If it’s ok that pushing for a shorter timeline without changing scope or scaling back the project is completely without risk, then there’s no need for any of this; you just assign every project a symbolic amount of time, roughly in the same order of magnitude to the actual effort and you just keep doing it until it gets done. This is by far the most common way projects are budgeted. Decisions about changes to the project are usually taken in the moment, either near the end of or after the original timeline. I’d argue that in this environment, the project only needs progress reports at the 3/4 point, at the end of the original timeline, and at every 25% overrun thereafter.

This is a healthy way to start a project regardless of the relationship between players

I believe applying a process like this on top of the considerable estimation and tracking work that are basically universal in software projects can help everyone involved and remove some of the tensions that develop between participants. Restarting a project can be healthy in order to discover the best way to estimate.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
art yerkes

art yerkes

An old programmer learning new tricks.