Today’s Medium compilation in my inbox brings an interesting article on the #NoEstimates movement in software development. It’s a tough bind: the features are fixed and they have to define (and then live or die by) the schedule. I empathize, sort of.
Proposal managers are caught in a different but similar project management bind: the schedule is fixed and they have to define (and then live or die by) the features:
- How many options will they consider for the solution and to what depth?
- How accurate and documented will their costing be?
- How many reviews will the document undergo?
- What production values will they target?
And, just as adding more people to a late software project makes it later, it’s tough to add people to a proposal team late in the game without eating into the productivity of the team members they were supposed to augment.
For software developers and others who have to estimate schedule (think writers), the article makes the case for using schedule estimates/commitments as a way to think and talk about the fixed point: the development challenge. How big, how new, how complex is it?
Proposal managers can learn from that approach by using features commitments as a way to think and talk about their own fixed point: the schedule challenge. How long will it really take to gather cost data from 30 suppliers? How long to write 300 pages? How long to edit them? How long to format them in Word? How long in InDesign? And so on.
And one more thing. Companies can hold proposal managers and their teams responsible for documenting their schedule data – even if it’s nothing more than their opinion or impressions – for the next team.