No Estimates Approach
One of the many great podcasts produced by the .Net Rocks guys featured Woody Zuill and discussed delivering software with no estimates. In the podcast Woody discusses the reasoning behind why you need an estimate and explains that a bad or wrong estimate on a unit of work is of no use and in certain cases can by worse than no estimate at all.
Take for example a software company readying themselves for a major release of software across multiple servers who schedule deployments with the Dev Ops Team, the subsequent training to the supporting business teams and finally a marketing dialogue with their customers readying them for changes to their service. If all of these subsequent tasks have been built on a ill thought out estimate it can have costly ramifications. Compare this with a company who doesn't give estimates, while they're not necessarily able to plan effectively for the future they are able to mitigate the risk of incurring resourcing costs from bad estimates.
With this hypothesis in hand, Woody explains that it's much better for everyone if the developer advises end users on requirements that can be quickly realised. This is a great approach when it can be employed fully however there are instances you find it won't meet your businesses' planning requirements.
Holding a Pre-Mortem
Gary Klien author of 'Seeing What Others Don't' suggests that human behavior makes it very difficult to manage projects and ascertain completion rates of tasks. It's such common practice for workers to start a task and claim they're 10% into the problem, for them then to quickly skip over to 90% in a day but then spend a week or so slowly incrementing their way up to 100%. Similarly people will often commit to completing a task to their project lead and supply updates of varied success only for a deadline to loom and the lead to be told there will be a delay or the task is not possible. Klien relates this to people being all too aware of how tightly bound their success in completing tasks can be to their perceived ability which in turn can have an impact on their earning potential.
With this observation Klien proposes a pre-mortem a meeting before the project starts to catalog the ways in which the project could fail. By harnessing people's pessimism in a productive way you gain foresight usually based on prior learning in other projects, nevertheless this is done in a positive way. Compare this approach to an informal discussion by colleagues discussing the impending doom of an in-flight project, all employees can work together rather than creating an environment of isolation where blame is proportioned even before true failure of missed deadlines have been realised.
When simply applying Klien's approach to software development we will no doubt encounter programmers claiming no deadlines can be given due to an incomparable solutions, how can someone give an estimate if they've not completed the task before. Conversely you can normally get a developer to accurately determine the time required to build a CRUD page but maybe not the integration with a new API.
The problem exists in acquiring an estimate at the beginning of the project when there are far too many variables to be able to accurately give a quote. That said an estimate will be given and work commence. Typically without any advice on prioritisation a developer may pick up the most interesting task first and leave the difficult task to the end, it's human nature, after all there's always a chance the programmer could have the fun task taken from them and reallocated to another programmer especially in an enterprise work environment.
This approach will incur costs as the developer only realises at the end of the project that their estimate was wrong. This means any dependent tasks related to a software release such as deployment activities or the alignment of radio or TV marketing will have to be postponed.
This can expose your business to incurring costs whether it be from a supplier charging you for scheduled resource that can't be reallocated or less tangible costs such as the time spent realigning the business to release the software later. The Dev Ops team will have to change their plans for any overlapping releases as they focus on the delayed project and the time spent clearing up the knock-on effect can often be considerable. Businesses can position themselves to manage these delays by only ever scheduling a percentage of their resource leaving a remaining percentage to deliver unscheduled activities, however, this approach hinder a team from delivering it's capacity while it protects itself from unforeseen spikes in workload.
When a delay is is finally omitted to the project team their ability to deal with the delay is limited due to the options they have open to them. Inevitably resource will asked to work smarter, seeking alternative options and in some instances this may be possible. This could for example be getting resource from the development team to help with its installation. The problem will generally come from third parties who're less likely to be that flexible with their resource when the issue has resulted from a problem on your
By getting the developers to implement these components first you address the area of 'the unknown' first. This obviously means you're unable to deliver an accurate estimate until these are completed. It can often cause frustration to developers giving estimates for items of work that are unquantifiable, by not asking them for these figures it can go someway to building a relationship between the technical and non-technical parties.
As with all approaches when estimating technical aspects of work this approach won't save you from giving inaccurate dates but it would give a framework for your developers to work against. Using the doomsday scenario previously mentioned where a software company has multiple cross departmental activities scheduled dependant on the code being released using the approach of knowledge coverage you'd be able to inform the dependant parties of any slips in the dates.
It does assume the developer is able to understand the requirements and analyse their skill set and deliver an estimate without prejeduce.
This approach should obviously be used in tandem with other good practices such as coherently explaining the scope of the requirement which can often mean explaining to the end user what functionality will not be included in your work and not just focusing on what will be included. As a rule of thumb anything you can do to minimise the area-of-the-unknown between the requester and producer of work should only be seen as a good thing.