A software developer deals with unique situations almost every day.

Every project, every bug fix, every issue has its own unique challenges and one of a kind circumstances.

Even if the functionality has been built before in other systems or is available on other pieces of software, implementing it on a specific system or integrating it with existing code has its own set of challenges.  A developer really does work on “projects” in the sense that they work on unique endeavors that have some degree of uncertainty and risk of failure.

As far as the other side of the formal definition of a project, having a defined start and end date, that’s often a matter of controlling scope creep or change requests

Because developers are working on projects there is no single body of knowledge they can master to have answers to questions right off the bat.

When you ask a doctor about a pain in your side, there is a well documented set of potential answers and a huge body of research on the most probable answer based on other data points/symptoms reported.   They can usually give you an answer off the cuff.  And if not, there are prescribed recommend tests to further find the answer.  This isn’t the case with a software developer.

A software developer is not a doctor. No two bodies of code are the same.

Next time you ask a developer for an answer or an estimate, don’t surprised if they need time to come up with the answer. Or, if the answer they give is inaccurate or if the estimate is off.

The same is true of designers and creative knowledge workers.

Formal project management methodology can be overkill on some projects or a lifesaver on others. In general, it’s clear on when to go through the detailed steps of a methodology and when not to. It depends on the overall size of the project.

1. A short project doesn’t require much in terms of formal project management. The steps you’d go through in putting together all the documents and spreadsheets of a methodology are done automatically as part of getting the project done.
2. A long project should go through formal project management steps to make sure all bases are covered and that nothing is dropped or forgotten. (This is especially true during when gathering requirements for the project.)

The problem comes when you think the project will be short and it turns out to be a long one.

To avoid this, do a quick, 10,000 foot estimate on the project’s size before getting started. In the language of formal project management (like PMI’s Guide to the PMBOK), this is called a top-down estimate. It can be based on experience and past projects you, or other people in your organization, have done. Templates or archives of these past projects can be helpful sources of information for the estimates.

Take the time to actually put together an estimate, as opposed to just eye-balling it or basing your estimate on “gut” alone. It can save you from the headache of underestimating the tools, resources or information you need to get the project done.

Estimating a project’s schedule can be a real challenge.  There is potential uncertainty and unkowns to consider when creating a schedule.  I’ve found it helpful to categorize projects when estimating a project’s schedule so you know what kind of margin-of-error to build into it. Three categories I find useful are:

1.  New Work
2.  Old Work
3.  Combo Work -Combination of New and Old

New work is an effort or process you’ve never done before. This could be using a new technology, an upgraded tool, developing a new type of solution, implementing a new program or designing an entirely new asset e.g. a website, if you are used to designing print pieces.

Old work is an effort or process you’ve done many times before with the same tool set.

Combo work is a combination of new and old. This could be doing a standard project using a new tool or technique or working on something you’ve done before but which you wouldn’t call yourself an expert at just yet.

MARGIN-OF-ERROR

Each of these categories carries a different degree of uncertainty. You can capture that uncertainty by creating a margin-of-error for your schedule estimates. Here are some guidelines for margins-of-error. 

1. New Work - a margin of 8x.
2. Old Work -a margin of 1.5x
3. Combo Work -a margin of 4x, though you can shift that higher or lower, depending on how much is new vs old.

DON’T FORGET CLIENTS

Clients are another element to consider when deciding what category to put a project into. Doing work for a new client or a new contact person at the client can add as much uncertainty as using a new tool or developing a new solution.

QUESTION (from LinkedIn): Forecasting the same as prediction? Which one is more realistic and easier to do?

ANSWER: Forecasting is different from predicting. Predicting is much easier but far less accurate.

Predicting is when you start making guesses about things. For example, you predict that laying sheet-rock will take 45 hours to do and you guess that it will be done in 2 weeks.

Forecasting, on the other hand, is when you take information from past jobs and apply it to a new job. For example, if you have seen that laying the sheet-rock for a 3,000 sq ft space takes 65 hours and it usually done in 4 weeks then the next time you have to quote out the same job you’ll be able to forecast how much its going to cost and how long it will really take i.e. when it will really be done after work starts on it.

The big difference is predicting is based on your best guess from experience. Forecasting is based on data you’ve actually recorded and tracked from previous jobs.