The Retrospector

One of the crucial points in a project is near the end where you have to decide to simply wrap things up enough to deliver. The ability to enhance the product forevermore can creep into your scope so easily if you let it. (Scope Creep) Sometimes it gets to the point where you’ll be on an endless timeline of development where you can’t just finish it and get the product shipped.

What I’d like to talk about in this article are some of the things to watch for to make sure you can get your product delivered to your customer. Such things include avoiding scope creep, properly comparing requirements with personal opinions, and follow-through on making sure your product gets to a deliverable state.

Scope Creep

This is a subject that probably has enough issues that it could be an entire series of posts. What I think you should take away from this for today’s article is simply that allowing the scope to broaden or change too much will prevent you from every being able to clamp down on the “moving target” deliverable. You will spend so much more time trying to factor in new features or implementation approaches for a dynamic scope than ever wrapping up the ones you currently have on the table that you will never get the original requirements in a deliverable state.

(more…)

The last few weeks I’ve come across a number of things that required some sort of estimations, so that everyone involved could get a set of expectations in their minds on what would result with each endeaver. (I’ve also noticed quite a few articles about estimation lately.) Tasks range from honey-do projects around the house, to components on an application in the office, to personal estimates on some little things I’d like to just get done.

Estimation is very simple in most cases, but it can get very complex for some things. I’m going to break down some of the issues that effect one’s ability to accurately estimate projects here and hopefully share some insight on how to find your most likely results when forced to think about quantifying your abilities.

Experience

If I had to sum up the art of project estimation in one word, that word would be experience. There’s simply no replacement for what experience can do for you when you have to think about tackling a problem.

If you were given a task of figuring out how to start a campfire, you would have learned the first time around some of the things that don’t work by trial and error. You may have spent an hour trying to get it started the first time, but this time you know you should give plenty of airways to the bottom of the fire to let it breathe while you put the tinder in the flame to get it going. There’s really no way to know that without having experienced it for yourself the first time around.

Case study

Let’s apply this to a scenario at work. Let’s say your boss comes to you and asks how long it’s going to take to get the florescent green with dancing monitors background CSS generator doo-hickey working. Now you know you really need to get this really cool background generator done this week, and if you could get it done today you could impress people. Not only that, but you quickly realize that it’s just some string parsing that you could do blind-folded because it’s just some little class with a few methods for generating color and monitor outlines.

(more…)

In the corporate world, there is a very heavy weight put on successful delivery. Companies usually understand that some things have learning curves, but where do you draw the line on testing out new technologies before you actually stop and deliver something?

Are you known as the guy that knows about a lot of things but never delivers on time? Can you relate to someone that always delivers on time but ends up using the same outdated approach over and over again? Maybe you’re somewhere in the middle, but how do you know when to balance learning with delivery?

I’ll define some considerations you need to take, factors that should effect your decision, and give some tips on how to apply what’s known to deciding which approach you should take to still be successful.

Things to consider

• Time – How much time do you have? Are your customers patient? Is there a high visibility on whether or not you can deliver quickly?
• Risk – Do you already have success with similar projects? How much experience does your team have in completing like tasks? Do already know how to implement all requirements requested?
• Resources – Do you have enough help to get everything done? Are you in a volatile environment where people aren’t able to dedicate themselves long enough to be effective? Is everyone involved able to focus on just your project without worrying about other commitments?

All of these items should be weighed in when deciding on a project plan. If you know there’s a very low risk in being able to deliver on time, it’s likely a good opportunity to begin trying new things or experimenting with new technologies that can be applied to some of the components.

If the risk is medium or high that you might not meet the expected delivery, using what you know will work should take precedence over experimenting with frameworks or widgets you’re unsure of.

(more…)

In today’s competitive software development world, companies are experimenting with many scenarios to reduce the cost of their software. Some companies prefer to develop everything in-house. Others prefer to outsource everything. With both options being rather expensive as professionals aren’t exactly the most affordable, some companies are considering outsourcing to companies abroad.

Offshore outsourcing has been proven to succeed for some companies, but it isn’t the alternative choice for everyone. One alternative with many similarities is to use college students as a workforce for the same elements you would consider off-shoring. I’m sure there are some companies that have found the off-shoring business model suits them perfectly. I say “good for them” if they got it to work out the way they wanted.

I have to admit that I’ve only been involved with one major project that involved an offshore development team and the entire experience was horrible. I can’t say much for how it works now (a few years later), but I imagine things have probably gotten better. What I am interested in pointing out is an environment I’ve seen work very successfully with many similarities.

(more…)