Building a Reputation: Knowing When to Experiment and When to Deliver

Posted June 9th, 2006
Categories: Technical, Corporate Life, Programming, Planning, Project Management


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.

Factors that change everything

Sometimes, things just happen that effect the plan that are out of your control. These factors should also be considered in your decision to play with new stuff or just concentrate strictly on delivery.

  • Unknowns exist in the implementation plan – If there is anything defined in the implementation plan as an unknown. (i.e. a “we’ll have to figure out how to do this piece when we get to it” piece) You will have to experiment regardless to make sure you have a feasible solution in place. If you have these when planning a project, put this high on the priority list within your schedule. If what you’re planning doesn’t have a solution, there’s probably no point in relying on it.
  • Management gives extremely unlikely requested delivery date – If you’re given the task of delivering a project in a time you simply know you cannot complete regardless of warnings given, it might not be a bad idea to go ahead and experiment with new technologies that could help you deliver in a fraction of the time.
  • Resources available suddenly changes – This generally affects the first two points in this section. If you all of a sudden get more resources to apply to the project, you may be able to meet the target without experimenting by being able to fill the unknowns or spreading the workload differently. Likewise, if you lose resources you may be pressed to go into experimentation mode for the very opposite reasons.

How to avoid the conflict

  • Do the experimenting on your own time – Not everyone has this luxury, but the individuals that really want to succeed will build their knowledge and skill set outside the workplace to make them more effective on their work projects.
  • Schedule experimenting/learning into the project plan or between projects – This is a very effective way of encouraging your employees to keep up with new technologies and motivating them to learn more for the benefit of both the company and themselves. If the company is willing to invest this learning, great. Not many will allocate much time for this, so consider yourself fortunate if you can.
  • Work somewhere that doesn’t expect “on time and under budget” from project schedules - If you simply can’t deal with the pressure of delivery and want nothing more than to learn new stuff all the time, maybe you should get a job in a research facility or educational institution.

Basically, when you’re given a project as an assignment at the professional level, you’re expected to already know how to do your piece. That’s how planning and budgeting is made possible. If the company wants to push technology limits within the team by forcing the “unknowns” into the plan, it must be willing to give its professionals ample learning and experimentation time.

Once you actually can go into delivery mode and possibly meet all expected schedules, you definitely should and toss experimenting to the wayside. Then after you’ve eliminated the risk of not making your deadline, you can feel free to work in more learning time.

For most companies “on time and within budget” is the most vital project success measurement. If you intend on not meeting the deadline within budget, you better make sure all stakeholders are willing to take the risk of a little learning or experimenting being added to the schedule since it might affect you’re your ability to meet expectations.

One of the most crucial reputations you can make is being a dependable resource for your company to meet expectations. It’s also one of the fastest things you can lose if you decide to spend too much time daydreaming about the next latest and greatest technology out there. Be smart, and spend your time wisely.


del.icio.us  Digg  Reddit

Related Posts:


Explore posts in the same categories: Technical, Corporate Life, Programming, Planning, Project Management

One Comment on “Building a Reputation: Knowing When to Experiment and When to Deliver”

  1. Wrapping up the Project: Completing Deliverables · The Retrospector Says:

    […] During the lifetime of the project from concept to delivery, you absolutely must delay new features such that they be brought back into the picture after the first delivery unless the stakeholders are willing to deal with a huge time delay. Check out my post on knowing when to experiment and when to deliver for more related points on delivery focus. Want or Requirement? […]

Comment: