|
I have designed a site using WordPress. This was just a test WordPress site. I am now okay with the coding in PHP, JavaScript, CSS, and WordPress. Now my senior wants me, just by looking at a JPEG image and the requirements provided by the client, to estimate the time required to do a project. I don't know how much time I should estimate for the project. Can anyone tell me how to handle this intelligently? |
||||
|
|
|
The first thing to do is check to see if you're being asked for an estimate or a commitment. Especially in software development, these words are often misused. An estimate should be a range with an indication of your confidence in the values. For example, you might estimate a project as 25% confidence of accomplishment in 5 days, 50% in 8 days, 90% in 12 days. If you track your estimates over time, the midpoint of your range should be under your actual time about the same amount it is over. A commitment is an agreement you will have the project complete in N days. In my team, we use estimates (ranges) with each other. But product management gets a commitment number, even if they want to call it an estimate. Once you know whether you're being asked for a real estimate or a number to be used as a commitment, decompose the project as a whole into discrete tasks. You want a list of the work that needs to be done, with each task being no more than 3 days in length. Ideally, half to 1 day's work, although it takes a lot of practice to be able to decompose a project into pieces that size without doing a lot of design up front. Include tasks for research and prototyping if you don't already know how to do something. When you're done breaking the project down, add up your total and there's a number. One of the advantages of breaking down this way is that you'll get early warning if a project starts to go off the rails with tasks running long, and you can then make adjustments accordingly. |
|||||||
|
|
Estimating time is always tricky. I have about 20 years as a freelancer, and while I'm pretty good about time estimates, I come up completely wrong a couple times a year. I've noticed that I never estimate too MANY hours. When things go horribly wrong, it's always because I estimated too few. That's the first thing to keep in mind. In your situation, I would start with the site you've already designed as a test. How long did that take you? How similar are the requirements and layout to the test site? Having gone through the exercise of making the test site, you understand how long it took to code, how long it took to set up the layout. If the new site is more complex, increase the number accordingly. If you have no idea how to do the new site, build in some research time as well to figure out new techniques. Good estimating comes from experience. Without a lot of experience, it's a shot in the dark. Perhaps you can give your superiors a range - between 30-40 hours - instead of a fixed number. If you're able, let your superior know that because this is a new type of development, your guess may not be 100% accurate. Most superiors are understanding about this...especially when they know it's a new environment in which you're working. |
|||
|
|
|
You will give a far better estimate if you do the following: Break out the project into tasks. Don't forget that research,communication and meetings, requirements definition, unit testing, deployment, etc. are also tasks. Determine a min, med, and high figure for each task. Sum them up and you have the low, medium and high estimate for the project. If your organization will translate this into days to complete without adding on overhead - remember that this is a number of hours based on a maximum of 6 hours a day. You have to allow for leave, unavoidable delay, company meetings and other non-project related work or hours. I spent 10 years doing manpower studies and we always figured available time for direct work based on 75% of the available hours in the week for all professionals. So don't forget to add that total to your final number if he only wants a number without details. Your boss may not want to know you added this on, so you may need to adjust your time estimates to account for it. Only add this on if you know your boss is one of those people who will not account for this non-project time himself in passing the figures up the line(how many death marches has he sent you on?). Next keep records of what you estimated and how close you came. Once you do this for awhile you will have a feel for whether you tend to estimate high or low and will be better able to improve your estimates later. We tend to look back at our estimates when estimating similar work (especially for large projects). |
||||
|
|
|
In my case - extremely badly. Estimating time is one of those things that I can never get quite right - it's staggers me on a regularly basis that a task that I've been putting off for days might only actually take 6 minutes to complete. One thing I do to try and make sure that things are accurate - is I fairly regularly pick one task out of my todo list that I know I'm not going to complete and spend just five minutes on it - quite often it turns out that those five minutes work gives me a big insight into a) exactly those things that I need to have around me when I start this task, and b) exactly how big a job I'm letting myself in for... |
|||
|
|
|
Your first estimate will probably be wrong anyway, but that's OK. You learn. The important part is to use the feedback to learn quickly. You could do a detailed list of everything that will probably need to be done during that project. (All the functions that PHP must do for the user. All the supporting functions that PHP must do for the user functions. All dialogs that require CSS tuning. Installing the product. Reading user requirements and talking with user; that's also a lot of time. Fixing PHP bugs. Fixing JavaScript bugs. Setting up the server. Project-related bureaucracy, such as writing this estimate.) Then make a time estimate for each item in the list, and if you are going to write less than 1 hour for an item, think twice; 30 minutes is the absolute minimum. Now, the important part is: during the project write the real values next to your estimates. Add the items you forgot, and how much time they needed. When you are finished, keep this report -- it will be very useful for making estimates in the future: you will know how much time what takes, and what are your typical mistakes in estimating. Sometimes giving the most honest estimate is not the best strategy. (In a perfect world this wouldn't happen, but we don't live in a perfect world.) Most programmers horribly underestimate the time they will need; writing a correct estimate for you may put you in a bad light when compared with their estimates. Or your manager may press you to give shorter time estimates. In such situations, make a honest version for yourself, and then make a redacted official version for your manager. Use the honest version for your personal feedback and learning. |
|||
|
|
