How to estimate a project involving unfamiliar skillsets

Question

We are trying to generate an initial estimate to see if a project is viable. The problem is that the project involves configuring and customising an open source product that the development team have no experience with.

In fact the customer requires a large amount of custom integration. At the moment the developers say they cannot imagine how they would go about implementing some of the features (or if they are even going to be possible) and would like time to research, but at this stage there is no budget to allow for this.

What is the best approach to estimating/planning a project of this nature?

Answer 1

In order to do the estimate, and the work, you need the capability to do so. You need the right materials and people--those with the requisite knowledge, skills, and experience--in order to have an acceptable amount of risk and to do right by the client. No customer deserves to spend its dollars for a product it wants to a seller of services who are experimenting and learning, unless that customer is pursuing cutting or bleeding edge stuff and everyone is experimenting and learning.

If you don't have the capability resident, you need to buy it. Then do the estimating as you would normally do. If that is not possible, then the answer is, the project is not viable. Keep your client in the long term and let them hire a more capable firm for this gig.

EDIT to Rob Bird's comment: Rob, I can see a scenario where a customer may want a specific vendor no matter what, simply because of history and trust. Under a scenario like this, a postive and constructive approach I may try, if I were in your shoes, would to be 100% upfront with my client, letting them know you are cutting into an area that is new, and approach the work under a shared risk contract in some way, e.g., a fixed fee with discounted T&M cost rates. This would allow the relationship to continue, open honest communication that there is more risk than one might want, shared investment so that you and your team can build capability, and with some luck a shared win when it is all said and done.

Get them to the table, tell them your troubles framed that you are protecting their interests, and see where it goes. There's a solution to everything...just have to find it.

Answer 2

Actually, if the team doesn't have the budget now, they'll run out of budget later on, that is for sure. You'll need to invest some time (money) into the prototyping in order to get better estimates or ideas on how the integration will go.

If I were you I would give the team strictly three days - timeboxing - to investigate the product you are referring to. During these days they are not allowed to work on something else and interact with the world (no emails, no interruptions). The goal must be to create a spike from XP and have a plan on how to do the integration. (an XP approach)

If you really are not in the position to spend money on investigation, try to find a similar situation from the past of the team and use that data to do the estimation. It may not work, but it is more than nothing. Look for the worst case scenario and use that number. Let's say that your team did several integration projects in the past, and the longest one was 5 months. Use the 5 months. (distribution of lead times approach from Kanban)

You can also try an iterative approach or Scrum: find a small set of features which you can investigate and deliver. It won't tell you much about the end of the project, but you'll know it better after each sprint or iteration. (an Agile approach)

Answer 3

some suggestions for this.

• give the develpers some time, say 2 days, to do some invesigation on the open source tool, or some prototypes for the tool is much more better. This will help the devlopers to understand the open source tool and have a basic sense on what problem may be met in the future.
• Give a rough estimation after the develpers invesgitation. Reserve some buffer for risks
• Split the tasks and set the milestones for your project. If you use the Scrum model, it could be more better, you should pay more effort on the retrospective meeting, which will help you to summarize the experience and identify the problems and block issues in current Sprint.
• Re-schedule after each Sprint according the feedbacks of develpers and testers

Factually , this is the practice I was doing when I faced the similar situation with you. Hope this can help you . :)

Answer 4

Value Transparency

If you have a customer that is asking for an estimate, regardless of your estimating process it should be transparent. In other words, whether you're spiking a solution, using historical data, or taking a wild guess, your estimation methodology should be clear to everyone on the team, as well as the Product Owner and the customer.

Estimates Aren't Commitments

Most agile practitioners will recommend that you treat estimates differently than commitments. If you're being asked for a commitment, that's a red flag. Instead, you should estimate by whatever transparent method you can, and then have the project fail early if it turns out that the project can't get where it needs to go.

Use Iteration to Limit Uncertainty

You stated that:

At the moment the developers say they cannot imagine how they would go about implementing some of the features (or if they are even going to be possible)

In other words, your cone of uncertainty for the project as a whole currently approaches infinity. One approach is to estimate a small feature set where the cone of uncertainty is smaller, and then refactor the project estimates, epics, and user stories after each iteration when more is known about the project and its fundamentals.

This is essentially an exploratory approach, but can be viable if the project doesn't allow time for a spike as input to the estimating process. The spike will still need to happen, but will take place within a sprint rather than in preparation for Sprint Planning.

This kind of iterative development will allow the project to fail early when necessary, or to maximize earned value by building only the features that can be built in a cost-effective and timely fashion during the project life-cycle.

Get a Prioritized List

In order to do most of these things, the customer needs to provide the Product Owner with guidance on what's truly essential so that the Product Owner can prioritize a backlog. Once that happens, you can estimate a few of the top stories, rather than the entire product backlog. This is yet another way to limit the cone of uncertainty around your project.

If feature-by-feature delivery holds no value for the customer (e.g. the final product truly has zero earned value unless the entire project is 100% feature-complete) then the customer needs a measure-twice, cut-once methodology that emphasizes detailed planning and work breakdown structures. It may not make their project any more successful, but such a project isn't a good candidate for an iterative approach anyway.

Of course, that said, very few IT projects actually require 100% feature completion. That's why agile projects attempt to make each iteration potentially-shippable: so that the project can be terminated whenever enough value has been realized that further development is not cost-effective.

Root Cause Analysis

All the foregoing is really a way to manage problems that shouldn't exist at the level that it appears to exist in your individual circumstance. In this case, it appears that the problem is caused by faulty communication with the client about process, capabilities, or cost.

If you are in a position to fix the faulty client communications, then you should certainly do so. If you are not, then your professional responsibility is simply to identify the risk to your management team and let them be responsible for the success or failure of the process--they are anyway; it says so in their job descriptions.

Answer 5

As mentioned before, you will have to invest the time and money to either build or buy the knowledge to be able to give a professional estimate.

Additionally, since it is about an open source tool, you could try and ask the community of this tool, if it exists, for some actuals. But I would be very very cautious and try to be as detailed as possible (split it up in technical tasks, by module, ...) and get as much additional info as possible, like years experience, industry, environment, ...