15

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?

  • 4
    Don't estimate it. Classic mistake #32 (Blog post from Steve McConnell of Estimation book fame). – user4469 Aug 20 '12 at 20:57
  • @MichaelT I think this is too general. Estimations aren't evil, the problem is that certain people take them as commitment. Customers would like to know when the product will be ready and you have to tell them something. Either you use existing data or do an estimation. I like the existing data approach, but the estimation process can give you a better overview on what needs to be done. The evidence based scheduling by Joel is a very good approach. – Zsolt Aug 21 '12 at 10:53
9

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.

  • 1
    +1 for "Keep your client in the long term and let them hire a more capable firm for this gig." I've been on the receiving end of vendors trying to get the contract without having the capabilities to deliver or thinking through how it will be done to not upvote this! – Doug B Aug 20 '12 at 13:51
  • Sadly, I've been on the side of the vendor flexing its muscles and thumping its chest saying we can do anything, when I know we have zero capability of pulling it off. Then I get to watch the train slowly come off its tracks. Waste of time and sad for the customer. Thanks for the upvote. D – David Espina Aug 20 '12 at 13:58
  • 1
    "If you don't have the capability resident, you need to buy it." Find a consultant that can configure the open source project for you. – Andrew Clear Aug 20 '12 at 19:30
  • 2
    Thanks for the honest answer! Time to own up to the fact that I am actually the lead developer on the team being asked for a rough estimate for something that I feel uncomfortable estimating. The problem is the product chosen with the customer for it's feature set has no documentation (or any other resources) on how such custom integrations can be achieved and the team has little experience with it. I have already raised my concerns, but was just wondering if there was a way to approach this with a more positive or constructive attitude. – Rob Bird Aug 20 '12 at 19:46
8

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)

5

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 . :)

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.

3

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, ...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.