I read a blog some time back, unfortunately I don’t recall where and I can’t seem to find the path. This blog stuck with me, because at first I did not agree with the point of view, but now it haunts me because I see myself behaving in a manner consistent with the punch line. The blog was arguing against the use of estimates of project schedules at the onset of task. From being in a leadership position in a design team, I though this idea was crazy, and to some extent I still do, however there were some good points brought up that deserve attention.
When engineers are given a task to estimate and create a project schedule for a project of unknown complexity, we are really relying on the engineers expertise to provide good information on the ‘what ifs’ and unknowns. Engineers will typically return at least 3 different potential schedule scenarios; a pessimistic, realistic and optimistic timetable.
Pessimistic: This is the worst case scenario that assumes the challenges are beyond the ability of the immediate team or the available set of resources. This is typically a long-term time table in order to account for all the unknowns, what-ifs and direction changes. This scenario also assumes that the teams will not have focus on the project and will have to ‘fit this in’ amongst their everyday workload. From a leadership position, this scenario usually gets dismissed very quickly because of its doomsday tone, however appropriate it may be.
Realistic: This scenario bases time tables off of past performance on tasks of similar complexity and level of the unknown. Engineers will usually caveat this estimate by saying ‘based on project XYZ, it should take this long, as long as we have similar priority on this task.’ This scenario, in my opinion is the most accurate predictor of the project timeline because it accounts for the team’s ability to solve problems, provide solutions and work through the admin portions of product releases. The problem, from a leadership perspective, is that a realistic project estimate is unsavory, it ‘seems’ like it is too padded, when in fact ‘reality’ can be a bitter pill.
Optimistic: This scenario is caveat-ed right away by the engineers as being possible ‘only is all the moons align, we have no problems and we have nothing else to work on.’ This timeline is based on 100% focus on the task, 100% of the tools available and 100% success on every problem solution. The engineers knows this schedule is unattainable, and the leadership also knows down deep this it is unattainable, not only because things go wrong, but also because daily tasks will preclude 100% focus on a single project.
Now the guilty part…
From a leadership perspective, the optimistic scenario is typically used for planning purposes and to get the project approved through the overall system. This scenario may be used for a variety of reason, although top on this list is a justification that the team can fill the project within the desired timeline to meet customer expectations. The ‘optimistic’ timeline is also used with the assumption that ‘we are better at problem solving now than we were in the past’, so the optimistic timeline is accurate, if not a little generous to account for the unknowns.
If you follow this train of thought, you will see that the optimistic dates slowly become the expected dates, the expected dates become the critical dates and critical dates become the deadline dates. We all know that ‘unknowns’ are ‘unknowns’, and 100% focus is rare, if ever the true case.
I still believe that project estimates are critical from a planning perspective, but I struggle with the idea that I am also guilty of transforming optimistic dates into expectation dates. I am in favor of pushing teams to excel, but have to be cognizant of setting teams up for repeated failure.
What are your thoughts?