Recently I was at a seminar were one of the participants asked a question regarding estimating properly when working on an R&D project from the expert panel.
The question was “How do we give proper deadlines when we are working on R&D projects, because when we start going into research we come up with so many stumbling blocks that we need to figure out so many things and our estimations goes out of the window”.
Well this is a small follow up to that question on how I normally go about giving estimations when starting an R&D project where most things are unknown. I will use a project that I had to work on several years back regarding creating a mail plugin for communicating between our JEE based systems and an MS Exchange mail server as an example.
Well, when giving estimates there are many techniques that we can use like COCOMO, PERT etc... which are pretty good for giving estimates for large scale projects, however when giving estimates I have some golden rules which I use and the first being “I am giving an estimate and estimates are wrong”. This is very basic yet a very powerful rule to remember. Because an estimate is an estimate, If we knew exactly how long it is going to take it does not become an estimate, so estimates can vary, the catch is to give an estimate that is close to the actual deadline as much as possible.
So let's take the example I mentioned, Well here I was given a very simple requirement. One of our client who was using our J2EE – e commerce platforms had a requirement to connect and use their mail server which is using Microsoft Exchange 2006 and as I was in the R&D team I was asked to look into this and create an API or some sort of plugin which can be used to in all our J2EE apps so even in the future if anyone asks for such a connectivity we can provide the service.
The first thing the PM wanted from me was a time frame when we would be able to give our client an estimate of completion date, because depending on that the customer would decide the launch of the product, and as usual I did not have the luxury of months and months to give the estimates or to actually give the working plugin. So the first thing I did was I fired a series of question which would narrow my field down to what I need to focus on and following are some of those questions.
Q1 - Why does the customer specifically want MS Exchange connectivity?
A1 - He wants to use that to send mails and attachments through our system using his mail server.
Ok, so my client did not want to use the fully fledged features on MS Exchange, just the mail sending part, which led to my next question
Q2 – Can he use s simple protocol like SMTP if needed as that is straight forward implementation?
A2 - He can, but he would prefer MS Exchange as that is what their other systems use.
Ok. so now I knew that if this was going to take time, still we can get the customer off and running in about 2 days work by creating a SMTP connector and that was my back up.
Q3 – If he has other systems using MS Excange, are they Java based systems, Do I have someone who I can contact at customer side who knows how those are configured or are working?
A3 – No. Those are MS dot Net platform apps, however there is an expert on the MS Exchange service connectivity at the client side you can contact to get information on the configs and connectivity to the server etc....
Ok, So now I knew that if there is problem regarding the actual connectivity then I had an expert on the connectivity side so I can cut down on my trouble shooting time
Q4 – Are we, or is the client going to pay for a any 3rd party API that we are going to use if we have to use a commercial API?
A4 – If it is within budget “Yes”, but would prefer an open source free software connectivity
Ok, this was vital, because there can be so many open source API's but the support normally for a commercial product would be much more then an open source one, hence I could cut down the delivery time drastically if needed
Q5- Is there any specific config, architecture, platform, OS, etc... that he wants us to use
A5 – nope, the connectivity would happen from our side, in an RHEL, JBoss environment.
This was needed, because often we do research without knowing any specifics on where we are going to implement and after the research is done we end up not being able to implement due to environmental issues and that effects the actual delivery times drastically.
So now I had some things to work on, So I gave my PM a time frame of 3 hours to look around so that I can come back to him with an estimate for set of estimates for final deliveries
The first thing I did was broke my research in to multiple options using the info I had.
- Commercial , Java products which can connect as an API and is being used currently in the market with enough support. I got about 3 or 4 good products, but did not go deep into them, just read the home page, features and clients who are using the product. From that removed 2 who were very expensive and narrowed to two API's
- Non Commercial, Java API's which can connect to MS Exchange and is being currently used by clients. Got about 10, from those about 2 had good support, some were no longer having API support and some were used as mail clients rather then API's or plugins. Again I did not try to go deep into the products, just the home pages, features, support and usage
- In the net, has their been anyone who has connected any Java plugins to MS Exchange and have it working in production environments. I found there were two ways of connecting either via a WEBDAV connectivity, which people have done but the responses were less, and using a MS Exchange web service called EWS which had a straight forward connectivity and lot of people have used that, had issues and have got them resolved as well, so this was very promising as most of the group discussions had solutions and have been used in production environments as well.
So with this, I now had three ways of connecting where I knew if I used the commercial product, I would have the fastest development and delivery time, the Open source API's might take longer and if I use EWS that would be the longest time taken. From what I got from the net, most people have connected using EWS in about 2 - 3 weeks and have had the whole thing working. So my longest delivery date would be within 3 -4 weeks maximum.
So I went to our PM and explained there were three options, option one would cost $XXX, and the rest would not, but the maximum time taken would be about 20 man days and I can do some research and come back to him in 3 days with the exact timing.
With that I started researching more on the EWS connectivity and created the WS clients using Axis and used our clients MS Exchange experts help to get the connectivity and WSDL's etc... sorted out. So in about 2 days I had the WS clients created and after that it was pretty much straight forward WS client implementation with some twists and turns.
So my estimates I gave initially were pretty much achievable and the client was also agreeable for a 20 day implementation.
So with the clients involvement, MS Exchange experts involvement I got the R&D done in about 7 man days and then it was pushed to client testing in about 15 man days as an API which later I re factored so that it can be used as a plugin for any system. Later I even got the WEBDAV connectivity done as well, but I did not continue on that.
The reason I wrote this article is to show several key points
- The power of questioning. We as software professionals love to just jump in to the code and develop, but by spending a bit more time upfront thinking and asking some basic questions we can save tremendous amount of time and headaches which we get most of the time.
- We should never jump in to one solution, but have several options evaluated up front to know which are the solutions that we should even look more closely into as well as what are the solutions that would give us the longest delivery time to the shortest. This would allow us to gauge our estimates better
- Always be aware if you are going on the right solution and if you feel quickly change to a solution before you spend unnecessary time and later find that you are too late to communicate to client.
- Always keep the client or client side representative involved at each stage so that they also know the difficulties you are facing, do not try to hide from client and later come to a situation where when it comes to delivery only we inform the client about any delays or any other predicaments.
- Always try to have back up /Alternate solutions, if what you are doing is going to take more time then estimated you can give the alternate solution till you get the actual solution implemented
I hope the above points help when you are planning estimates for R&D based projects, when looking at evaluating tools or even simply giving estimates to software projects.
