Work with, rather than against, your project manager. Have you ever been asked to estimate something? Or the dreaded, what percent complete are we? Let me share some of the quantitative techniques I’ve used to lead successful projects.

Problem:
Developers are asked to complete ‘project management’ tasks on a daily basis. Many do not have the background to accurately complete the tasks, leading to problems down the road. Are you familiar with ROM estimates? Earned Value Analysis? If not, your walking down a slippery slop.

Solution:
Follow these basic techniques to add confidence to your estimates. Use quantitative measurements used by the best project managers to answer the dreaded percent complete question. Understand what your project managers are attempting to track in order to accurately transfer knowledge on key project elements.

Estimating

Let’s start with estimates. I’m making the assumption that you, or someone else has, already done the business analysis for the project. You’ve got a rough idea of what the client wants. Maybe a quick phone call or piece of paper on your desk. Now, in the middle of your already busy day, you need to come up with a number. A number that may come back to bite you in the ass. So what do you do? Well, you’ve got three distinct types of estimating: ROM estimates, intermediate estimates and definitive estimates.

ROM Estimates:
For when you need to qualify a client. They are + or – 50% of the actual number. Mostly just to filter out the clients that are trying to waste your time. On small projects make these quick. For large projects, you really should make the client pay. Come up with a quick list of items required for the project. For example, a video upload / player:

Controls
Authentication
Backend processing
Video playback
Pretty Stuff
QA
Project management

Next, identify each as small, medium and large. Controls would be small, authentication medium, backend processing and video playback large and pretty stuff medium. Assign a number to small, medium and large. Let’s say 4 hours, 8 hours and 12 hours. These numbers are gut feelings and should consider the type of client. Are they an agency that want’s everything perfect? Or a small company that wants something to work? After that you assign the hours to the tasks and send it back to your project manager. Don’t over complicate a ROM estimate. It’s just a ballpark. Make sure the client knows this! You would be surprised at how accurate these quick estimates are compared to those that people spend days on.

How do I know my ROM estimate is within the ballpark of + or – 50%? I’ve got a trick for that. Ask your co-worker to re-estimate, right? Wrong! Developer time is expensive. You can’t re-estimate everything. If you feel confident with another developers estimates just show them your stuff. If they like it than your good to go. Don’t know if this developer is even paying attention? Change your estimate by greater than + or – 50% and see if they catch it. Quick and easy way to qualify a fellow developer without them knowing. If they catch it than they are good for future use, if not than go to someone else. Confront them about it at your own risk…

Intermediate Estimates:
The client chose you, for some reason or another. Probably because the sales person sweet talked them into it and dropped your estimate 😉 Now what? Take that ROM and turn it into some tasks? NO! Worst idea ever. You just took something someone spent so little time on that it’s worth + or – 50%. Turning that into an estimate is like walking up to a hungry bear. You just don’t do it.

OK, so what’s next? Re-estimating! Seriously. You need to talk with the client for an hour, I know it sucks. Make sure you understand what’s going on. Hopefully you have something that resembles a design at this point. If not, I feel for you. Create a new list of defined tasks for the first 20 – 40% of the work that are all less than 20 hours. Ballpark the rest, intermediate estimates are + or – 30%. Why not estimate it all in detail? Because projects change and the last 60 – 80% will be different than you think. Based on your metrics from the first 20 – 40% you can accurately estimate the rest. Metrics??? WTF are those? You’ll have to wait till the next section. Now you have a list that looks like this:

Seek bar – 2 hrs
Play / pause buttons – 2 hrs
Volume control – 2 hrs
Database creation – 1 hr
GUI for login – 2 hrs
API for authentication – 2 hrs
PHP configuration – 2 hrs
Video processing – 8 hrs
Video playback -12 hrs
Fade on playback – 2 hrs
Easing for controls – 2 hrs
QA – 15% of total
Project management – 10 to 20% of total based on your metrics

Now you have tasks. We are going to ignore the definitive estimates because they generally aren’t worth the time to create. Of course, your project manager says no, it won’t take 20% of the budget for PM time. You than, very nicely, pull out previous project metrics that show otherwise. Show them data in their own language that shows PM time DOES take up that percentage based on statistical data. Don’t be mean about it. Just bring it up. Then, if the project goes over due to the drop in PM time cause they didn’t believe you, than you have something to back it up with. I can’t tell you the number of times I’ve been on a project that had developers working UNDER estimates but PM time (meetings and status reports) took up way too much time causing the project to go OVER budget.

Whew. Done with the basics on estimating. For more details you’ll have to wait for my book

Project Tracking

If you don’t know what Earned Value Analysis (EVA) is, your leading unsuccessful projects. How do we know where the project is going wrong? And how do we get it back on track? Let me propose a situation for you. A plan flying from Minneapolis to Mexico. It’s estimated to take 4 hours. After two hours your approximately half way through your fuel. Are you on track? Not enough information! What to you mean? Well, your assuming the plan is getting the estimated MPG. What if a strong headwind has set you back? Thinking about projects in two dimensions will lead to failure. Are you getting the proposed value from your estimates? Assuming you created a semi-decent task list you’ll end up with this:

Seek bar – 2 hrs estimated (3 hours actual)
Play / pause buttons – 2 hrs estimated (4 hours actual)
Volume control – 2 hrs estimated (3 hours actual)
Database creation – 1 hr estimated
GUI for login – 2 hrs estimated
API for authentication – 2 hrs estimated
PHP configuration – 2 hrs estimated
Video processing – 8 hrs estimated
Video playback -12 hrs estimated
Fade on playback – 2 hrs estimated
Easing for controls – 2 hrs estimated
QA – 6 estimated
Project management – 8 estimated ( 6 actual)

Only 16 hours into the project an you already know it’s off track. We are hitting our development estimates at 166%. At this rate we be way over budget. These numbers are incredibly accurate at forecasting the future. Unless the estimator really messed up, this project is way off track. What do we do with this data? Tell the client NOW! Let them cut a feature, increase the budget or simplify designs before you’ve capped the project budget. Trust me, they will appreciate it. I’ve never known a client to get angry after 5% of the work is done. If you wait till 100% of the budget is spent your SOL. Earned Value Analysis is the single most important project metric to track and it can be done with minimal effort, if tasks are created accurately. There are an endless number of combination’s for this metric, for this example we are covering one. Again, you’ll find more in my book.

That’s it right? Let’s do one more quicky before we leave.

Lessons Learned

It can be painful to look back at projects, especially un-successful ones. This MUST be done in order to improve the success of future projects. A few hours of review can save hundreds of wasted hours in the future. Correctly tracked EVA can show you where projects were under estimated. This article is for developers so I’ll rip into PM’s one last time. After tracking your time in meetings, calls, and reports if your PM time exceeds your estimates than there are a few options. Hang your project manager… no, wait this article is about working with them. Scratch that. Instead find opportunities to cut down on hours. Did the whole development team really need to sit in on that 2 hour call? Does the client really need a report every Friday? If so than you need to bump up your estimates! Really though, just knowing whats been over estimated will save time in the future. Joe keeps under (or over) estimating video players. Well maybe somebody should tell Joe? Sounds simple but without tracking how will he know? Are you tracking the results of your estimates?

Summary

Knowing the basics will help you. Unfortunately this is only scratching the surface. I keep hinting at my book in this article. It will contain some of the detail that I was unable to include in this post. There just isn’t enough room in a blog post. For an even more comprehensive list of information please Google these topics. This is nothing new. Just things I’ve found to be new to most interactive project managers, designers and developers. Spread the word.

Resources:
Estimating Article (Pretty self explanatory.)

Earned Value Analysis on Wikipedia (I know, it looks scary. Trust me. If you can code, you can figure it out.)

Chris Black worked as a part of the project management office at Travelers Insurance. He worked to create a comprehensive list of best practices for project managers. Chris than went on to work as a developer and later as a senior developer at Sierra Bravo (a.k.a. the Nerdery). At the Nerdery he lead a number of successful projects using the metrics outlined above. Chris will be including these topics along with more technical items in his book which will be released in the second half of 2010.