I wanted to dig into the subject of striving for a goal verses being happy with what you have. I have touched on this topic in the past but I want to expand on it a bit more. This is a balance is difficult and different for everyone.
Ron Morriss used to say that a lot of discontent comes from a person seeing what others have and then comparing themselves to that person (I don’t remember his exact words so I am paraphrasing).
In the self improvement arena we encounter a different type of monster than most people encounter. We are constantly trying to improve ourselves, so we read about people who have achieved what we want to achieve. One example is the Four Hour Work Week by Tim Ferris. This book is a great resource of information but we must remember that this book is to teach you a path, not the exact actions to follow to reach a specific goal.
If we get too caught up in following the exact actions of a “successful” person with the goal to reach the same height of achievement, we are setting ourselves up for failure. We are all different and it takes millions of small decisions to achieve a goal. If you don’t make the same decisions as the successful person then you may not reach the same heights they did.
So there are 3 take-aways from this.
The overall arching principle is to improve yourself.
When striving for a goal, be willing to accept that you may not reach the exact same point of achievement as the person you have modeled yourself after
Sometimes reaching a goal takes longer than you hoped so enjoy the ride.
I am going to make this a short post since I burned out a little working on the soccer site project. The one week project finally ended after 6 weeks.
Lately I have been thinking about how my actions can possibly negatively effect others. I feel pretty confident how my actions effect others when immediate feedback is available. What about those times when the feedback is delayed and/or diffused?
For instance, I used to spit my gum on the ground when I was done with it. I was okay with this since I only spit it in places where people were very unlikely to walk like on the highway. I also assumed that it would biodegrade pretty quickly so it was no big deal. Then I started to think about things like how that gum spot would look or the was rare chance that someone would step on it. I did not want my actions to effect others negatively so i stopped spitting my gum out on the ground.
This is the same reason I am slowly starting to compost instead of throwing everything in the trash or down the disposal. I know if it goes in the landfill it will slow down the degradation of other materials or even contribute to pollution is the decomposing comes into contact with things like old batteries. Also, if I put those things down the garbage disposal I will be burdening the water processing plant more.
I know I am not going to change the world by doing these things and I know that I am not doing everything I can possibly do but by moving in this direction I am able to make myself feel better and maybe make the world a little bit better.
I have been working with a developer over the last few weeks building a site which will be used to connect indoor soccer players to teams who need players. I have learned quite a few things about working with a developer through my frustrations during this project.
Prior to this project I had some experience working with virtual assistants (VA) and I will also include what I learned from those experiences too. I may interchange the terms virtual assistant, contractor, and developer for this blog though they are not always the same thing.
Initially I wanted a site which would help me find players for my soccer teams. I set a budget of $300 and went to Elance to find a developer. I defined a pretty basic scope and stated the full scope would be available once they signed a nondisclosure agreement (NDA).
I received 3 bids for the job $800, $300, and $278. I think the $800 job would have been the best since it seemed they asked the most questions and seem like they have done this many times before. If I had the money I would have chosen them. I decided to go with the $278 bid because of money constraints and it just felt right (I sometimes make decisions on feeling). This would be his first project on Elance and, going in, I understood that since the financial cost was low there would probably be non-financial costs to the project. Though I was not sure what those would be.
So here are my lessons learned from this project.
As I stated before, there would be costs for this project which would not be financial. Here is what I have found so far.
The project is way past the original completion date. Though, this is not a big deal for this project.
The developer knows how to make websites but is inexperienced in project management, which means he is unorganized and did not seem to build the site in a step by step process and he did not seem to review the scope document thoroughly. He wanted me to check things often for him even though they were outlined in the scope. He did not seem confident in what he was doing. I feel like I am babysitting him sometimes. This made me feel like I needed to check for messages from him all the time on Elance. To remedy this, I only allowed myself to check for messages 3 times per day.
His English is a bit lacking so it was sometimes hard to understand what he had written me. I had to ask him to clarify several times.
There were certain things he did not know how to do and he could not find a coding solution. I ended up finding him some of the solutions which was silly since I am not a coder whatsoever.
Before you accept a bid ensure they sign the NDA and review the full scope so they understand what is expected of them.In hindsight, my contractor did not do this and I felt he may have charged more if he knew these things. That is why I was willing o pay him more than $300 (which I explain a little more below).
By the way, you can probably find form NDAs online for free or even very cheap.
Define the scope thoroughly
This gives you a document to refer to so you and the developer know what the expectations are. The more thorough you are the better. For instance, consider how the site will look and how the final product will install.
I used Balsamiq to create a mock-up and gave written instructions along with pictures to the developer as the scope.
Another piece is to define the skill level of the people who interact with the final product. For instance, I want the theme to be easy enough for someone just starting to work with Word Press (WP) to have the capability to easily operate it and install it.
Though, there will be some things you may overlook. For instance, I assumed a Word Press theme would install like other themes I have used but since I did not define it well the contractor started developing it where it was a difficult process to install.
On top of that, I assumed that the Word Press installation would automatically have blog capability. Since I did not define this well, it was not initially set up.
These types of things will take some negotiation between you and the contractor.
Because of the items I overlooked I ended up offering the developer another $72 to do these things. I felt this was reasonable.
Finally, give examples (like other websites). This helps the developer understand what you want.
Pay per project, not hourly.
This is because the project may take longer than expected and you don’t want to go over budget. Plus it gives you leverage when you are trying to hold the contractor accountable.
For this project the developer stated it would last 1 week but as of right now we are going on 5 weeks.
A couple of times in the beginning he tried to do things that did not meet scope so I told him I was not comfortable paying him the full amount if he did not meet the requirements of the scope.
He ended up correcting things according to the scope.
Make sure the contractor gives you acceptable milestones.
My developer did not define milestones. This made it hard for me to understand the process he would follow. Plus if you define milestones it gives you the opportunity to make milestone payments for larger projects. Though, on a small project like this one final payment is acceptable.
Do good market research before you decide to have something built.
There were a couple of times in this process I thought I found an already-built Word Press theme that did what I wanted. I initially felt pretty stupid, but luckily I did find that those other themes did not do what i wanted.
At the beginning of the project create a checklist to ensure all parts of the scope are completed.
Also, create a second checklist for anything you ask the developer to do. You guys will be conversing a lot and you want to be sure everything you ask is completed. Also, while reviewing the final product you may find problems. You can also add these to this checklist.
I used Google Docs to create this checklist but in hindsight I found Elance has something like this built in.
Be Ready to pull the plug
A couple of times I was concerned that the developer could not do the work so I considered pulling the plug. It is better to do this early in the project so time is not wasted. When I thought I would have to pull the plug I began researching the process Elance because I did not want to pay the developer for work which was not completed. Elance is set up to handle this but I bet it would still be a pain in the butt. Luckily we were able to work through the problems and persevere through the project.
By the way, there are some cultures in the world who are unwilling to admit they cannot do something such as certain steps in this project. It has something to do with avoiding shame. I believe this was part of the problem I had with my developer but I got around this by clearly communicating to him we need to complete the project as stated in the scope and that I would not be willing to pay him everything if all of the scope was not completed.
Tell Them Why
There were certain parts of the project the developer struggled with so I explained my thinking and my goals. This helped him to walk in my shoes, a bit, and build in a similar mindset as me.
Consider including instructions in the scope
If you do not want to write instructions then request the developer write them.
Define how you will interact with the Developer
It may be helpful to tell the developer how often you will check for messages and about what times. This will allow them to understand that you cannot be available at the same times they are. For instance, my developer is located in India so he is awake when I am sleeping and vice versa.
General Virtual Assistant Experience.
Prior to this project I had some experience working with virtual assistants. This was more ongoing work that required pay by hour. In these cases you need to be sure to trust the VA. Also, these VAs did things like edit audio and post blogs.
Here are some key things to consider
Interview the VA for ongoing work like you would another employee. My friend did this and he loves working with his VA from the Philippines. I have also worked with that VA and he is freakin’ great.
Set deadlines. One of the VAs I worked with did not tell me when he would be done with a project after taking the job so we thought he was working on it when he was not.
Follow up. Luckily I followed up with the same VA mentioned just above because he was not responding to our requests for an update.He had to be fired.