When asked to give a timeline for project delivery, my first questions, of course, are about the details of the project. Then, I take a guess about the timeline and double it, and fight like hell to eliminate blockers and distractions for the team, work with them on implementation theories, ask leading questions that help balance the “optimum” solution against the timeline, and put up whatever obstacles I can to any changes to the plan.
Because in the meantime, we’ve committed to other projects and other timelines, and those project timelines depend on completion of this project.
Internally, we mostly use a scrum approach to projects, but externally we’re forced to follow a waterfall approach. With too many projects and too few engineers, we have to time slice quickly and move on from projects just as people are getting excited about them.
I play a role I don’t like, and oppose changes I think would add value and increase satisfaction in projects because the team is held responsible for delivering on timelines that only exist to give the next person in line an idea about when his or her project can start.
Neo’s Josh Seiden and Jeff Gethelf attempted to address this back in 2011, but Josh’s followup earlier this year pointed the finger at the RFPs and contracts that firms such as theirs face. Josh named some of the most damning contract terms:
- Fixed-scope deliverable: Assuming that the features of the system are known in advance.
- Fixed time deliverable: Assuming that we know how long it will take to build the scope in question, and specifying a delivery date for these features.
- Acceptance: Assuming that at the end of the project, we’ll be able to tell that we’re done based on a set of “acceptance” criteria that were identified (and fully understood) at the beginning of the project.
- Corrections: assuming that the we will provide free labor to “fix” software that doesn’t meet the acceptance criteria (which in turn assumes known acceptance criteria.)
The list is different, but not unfamiliar to what I face.