Honestly, as Nassim Nicholas Taleb writes in his book The Black Swan: ‘we just can’t predict’. Mainly due to the unknown-unknowns. It is generally best to communicate this very fact, the fact that you can’t predict, instead of communicating an estimate.

As Taleb writes: it is better to be broadly right, than precisely wrong. So be sure to communicate the fact that you have hard times estimating, and use things like ‘learning curves in new tech’ as one of the arguments. This means that the range of your estimate will be big: ‘this project wil cost between 100k and 500k.’

By saying such a thing, the one asking you to estimate something realizes that things are not so simple.

The absolute first thing you need is some idea of the scope. The more concrete the better, but any form of requirements can be used to produce initial estimates. Customer requirements, vision and scope, and concept documents can be used early on. As the requirements and operating environment begin to become more clear, then the estimates will improve. A greater understanding of the client (especially the interfaces between the client and the developing organization), the team performing the work, the technologies to be used, the system architecture, and a detailed design will all contribute to a more accurate estimate. This is visible in the Cone of Uncertainty.

If you are using a parametric modeling tool, such as SLIM or COCOMO (Intermediate or Advanced only, as Basic doesn’t account for cost drivers), then there should be adjustment factors for the unfamiliarity of the technology. As an example, COCOMO has a large number of cost drivers, including some that are specifically geared toward familiarity with the target platform as well as the language and tools being used to develop the system. SLIM also accounts for the overall experience of the development team, which should include considerations of the tools and technologies being used.

With this technique, the output of the modeling tools are typically validated because they have successfully been used to estimate previous software projects over many years in many organizations. However, the output is only as good as the input to the tool.

If you aren’t using parametric models for estimation, you’ll have to simply consider these factors when producing your estimates. It becomes more of a judgement call, but you can consider activities such as reading documentation, setting up the new development environment, and developing sample applications on the target platform or with the target languages.

In these instances, you will need to break down your estimates by task and be able to use your professional judgement to back it up. Hopefully, you have historical data and other concrete evidence to base your estimates on. Otherwise, it’s more of an uphill battle.

Separate major training and research time from development time. Break the project into multiple sub projects that have happy endings. Make sure you create a proof of concept after the training.

If you are new to the technology, you will never get close to the actual development time. Raise this as a risk at the beginning of the project and be generous in your estimate. This applies to core technologies you and your team are not familiar with.

Depends, I used FPA (Function Point Analysis) most of the time, but we were into this “enterprizey web development”, I mean, you know, Forbes 500 web companies.

There the task can be always divided into two parts: one, which fits FPA really well: you have input interfaces, output interfaces, internal logical files (aka. database tables / types to be exported), and you have these complex, unknown systems.

In the easy version, the complex task is a component already written, it’s just hard and unknown to interface with it.

The hard version is when it needs to be written, then pilot-based estimations, COCOMO, whatever.

Two things, however, of importance:

1. Every kind of estimation system has to have a calibration time for your organization. You never develop alone, at least there’s a customer waiting for your code (or you wouldn’t be so desperate about this, writing code for your own sake). The question is not “how fast can it be developed?”, but “how fast can it be developed with you all?”

2. Once I had a manager who read that Black Swan novel and was maniac about it. He was telling us that it’s impossible to estimate, and I was doing my usual precise to +-10% estimations relentlessly…

I do projects that fit that description somewhat regularly and I haven’t figured this out yet! Thankfully where I work I’m given the latitude to do what I need to and not have futile time limits. The projects are not always successful and that’s just a part of what the work is with so many unknowns. The company gains knowledge each time though.

Sorry that doesn’t help at all.

Estimate how long it will take to do a similar project using familiar tech.
Multiply by 4.
Add some learning time.

If the estimate is too short you will look naive and arrogant. if the estimate is too large you will look ignorant and incompetent. Choose wisely.