Blind Ape Seo

Darn!

I completely forgot to organize this years WebWriMo, simply because I am too busy.

But, if you want, you can join me for an insane month of web creation.

The old ape himself just started on two big web projects, svereal uBot creations and more. November will therefore be spent in a productive trance, typing and thinking until his hands fall off, the brain overheats and turns into a mush, and he collapses at the desk.

You can share your own stories in the comments.

::emp::

Part 1 - Introduction and Description of the problem
Part 2 - Requirements and you
Part 3 - Tracking Features and Bugs
Part 4 - The little black book that could
Part 5 - Your developers - Don’t be a prick
Part 6 - Wrapping up

oops, I completely forgot I still had to wrap this up. I even began work on a new article series already. (Closer to affiliate marketing bread and butter)

To wrap this up, I would like to reiterate the key points I was trying to make, review the concept of metawork and point you to some good literature on the subject of managing projects.
1. Outsourcing is broken
Well, not really broken, but it has difficulties. One side wants quality work for less, the other side needs money.  “Modern” bidding wars only aggrevate the problem.

2. Telepathy does not work
Make sure your requirements are up to the task.  They are the only way to communicate what you want. They are also your sole witness in a dispute.

3. Numbers are your friends
Numbering tasks, bugs, features makes it easy to track work.

4. The grimoire
Keep track of good and bad experiences to avoid getting burnt twice.

5. Be nice
Bonuses are one thing. Being nice to developers, graphics artists, writers, etc.. is even better.

Meta work

I use the term “meta work” to talk about things you have to do that are above the level of an individual project. The fact is that this work will take up a good chunk of your time once you start managing projects and people. And it should!

Meta work is thinking about the way you are working. Take a bit of time out of your busy day and reflect.

• Are you communicating clearly?
• What problems have occured and how could they have been avoided?
  (This is meta work, as there is no thing you can do NOW to avoid the problem, as it has already happened.)
• Have I been friendly to people? Why not?
• What do I need to know about? Is there anything I need to research?
• …

I am a firm believer in the value of meta work. Any manager not doing this is a waste. In fact, even as a delivering worker, all your projects will profit from this practice.

Here are some good books now:

The Art of Project Management (Theory in Practice (O’Reilly))
This textbook is a good introduction into project management. Highly recommended and not as dry as most books on the subject.

Code Complete: A Practical Handbook of Software Construction
Code Complete is a very technical book. You will benefit the most of this if you are a developer or if you are managing highly technical projects. Probably too dry for  a lot of people. Good nonetheless.

This about wraps it up, young grasshopper.

Good luck with your projects and… Have Fun!

::emp::

Part 1 - Introduction and Description of the problem
Part 2 - Requirements and you
Part 3 - Tracking Features and Bugs
Part 4 - The little black book that could
Part 5 - Your developers - Don’t be a prick
Part 6 - Wrapping up

If you fear that your old simian has abandoned this article series, don’t.
It just took me fotever to write this entry,mainly because

You should know this since Kindergarten!

Sadly a lot of people still don’t seem to get it.

What is getting to me are the hostile to upright racist and insulting remarks often targeted at foreign developers.

To make one thing clear, I am far from the touchy-feely, the world is one big bundle of joy, all people are wonderful type of guy.

The reality is: you will meet assholes everywhere, all around the globe, of all nationaliries and heritages.

But I have worked with people from all over the globe. Indians, Russians, French, Germans, Swiss, Italians, Spaniards, Americans, Italians, English. and honestly, most of them were good people, taking pride in their work and doing their best.

My advice to freelancers:

Keep a black book on employers just like the one I described in my last post.

Assholes are not worth the money you could earn.

My advice to entrepreneurs outsourcing work:

Don’t be an asshole.

Simple as that.

::emp::

Part 1 - Introduction and Description of the problem
Part 2 - Requirements and you
Part 3 - Tracking Features and Bugs
Part 4 - The little black book that could
Part 5 - Your developers - Don’t be a prick
Part 6 - Wrapping up

Part 4 - The little black book that could

So here comes another insight into building projects with outsourced labor found online.

You are going to get burned.

Yes, no beating around the bush. You are going to have bad experiences, you are going to get burned.
Granted, the cost of those burns is going to be manageable - we are looking at cheap, outsourced labor, after all. Still, it is going to sting.

So we are going to try and keep that sting to a minimum.

So what am I proposing to avoid those half-built websites, shoddily thrown together backends, badly designed layouts?

Of course, making one of those trusty excel sheets to keep track. (you knew that was coming, didn’t you?)

Fool me once - shame on you. Fool me twice - shame on me.

It will still happen. You write great specs (of course), you communicate clearly and concisely (naturally), you offer a fair payment for the work (par for the course) and still - shit happens. Or in the age of the net - excuses happen.

Deadlines seem to have a bad effect on pets and relatives of all kind.

Time to go meta

After cutting your losses, renegotiating or transfering your work to another worker, comes the time for your meta-work.
(I define this as work above the level of the project or any ongoing work, defining strategies and processes.)

In this case, this means keeping track of people you gave work to and how they performed.
Besides keeping track of nicknames / avenues of contact, keep track of the deadlines, slippages in deadlines, failures and reasons for failure.
(This is the time for some humble reflection on your own work, such as specifiactions as well.)

Then you have to deliver the

Consequences

1. Someone who does not deliver on the first or second project - never going to work with them again.
2. Deliver two projects without fail - ask for a direct mail adress and keep on file.
3. Three projects without fail - ask for direct contact and the possibility of giving projects privately and on short notice, also bumping up the rate a bit without them having to ask.

After three projects, a dev will still be blacklisted from my list if he fails to deliver for shitty reasons and being rude about it.

But a good dev is cut some (some!) slack.

Why? Because shit happens. Pets do get sick, grandmothers die and sometimes the sky falls on your head.

Here it is important to keep track of how many times this happens and if the person is forward and honest about it. If you are going to disappear for weeks at a time and then come back with a lame excuse - well, you are not on the list of good people to work with anymore. And although I do not think that “outing” people on forums, etc is a good idea .. do not hesitate to contact friends and tell them to avoid that person.

To end this on a more positive note:
People who perform well or even above the specifications should get a slight bump (or bonus) in their pay and should be recommended.
Just fair play.

With a few bad experiences, you will build up a nice little black book of good and exceptional performers who you can contact for your projects.

The little black book that could.

::emp::

Part 1 - Introduction and Description of the problem
Part 2 - Requirements and you
Part 3 - Tracking Features and Bugs
Part 4 - The little black book that could
Part 5 - Your developers - Don’t be a prick
Part 6 - Wrapping up

Part 3 - Tracking Features and Bugs
Now that we know how to write better requirements, here is another secret project management kung fu technique:

Numbering

Oh wow! Yay! Man! WTF?

I am being serious.
Number and name your requested features.
Each and every one of them.

This could look like this (taking up from the last part)

23 Affiliate offer site

23.1 Affiliate button
At the end of the text container, put a green button. The button should be labeled “Claim your prize NOW!”. The color code for the button is #00FF00. See attached screenshot of layout (layout_mockup_01.jpg).

23.1.2  Button function
When the user clicks the button, he is directed to redirect.php in the same directory. The link opens in the same window.

This way, you get a handy method for tracking the work and bugs.

For this, make yourself an excel sheet with the numbers, the name, status and note.

Then, whenever the project comes back into your hands, you can test each number and note the status and eventual bug note.

23 Affiliate offer site Buggy  23.1.2 Does not work as it should, leads direct to affiliate link.

Why numbers?
Numbers are easy to communicate. There is no ambiguity with numbers. Instead of saying “Ya know, that green button at the bottom of the offer page does not work.” I can point the coder to “Feature 23 is buggy, please see the report.”

That way, a lot of misunderstandings are ruled out and development and bug fixing are faster.

Yes, this is a lot of work, but it will save you time and money in the long run.

How so?

First off, you will come to grips with what you are actually asking for. Making a list like this, it becomes easily apparent when something is missing.

You will also come to grips with the size of the project - timewise and moneywise.
If you need an estimate, ask for an estimate by numbers. You don’t need to ask for each and every task, but you can ask by chunks, in the above example this would be #23 - Affiliate offer site.

Hint:
Try to keep the work packages at approximately 1 day or less for small projects, 1 week or less for big (multi-month) projects.

If you are trying to improve your project management skills, keep tabs on how your estimates compared to the times it really took to complete a task. Learn and adjust.

This will also help your estimation skills as a developer, so you don’t end up taking more than you can handle.

::emp::

Part 1 - Introduction and Description of the problem
Part 2 - Requirements and you
Part 3 - Tracking Features and Bugs
Part 4 - The little black book that could
Part 5 - Your developers - Don’t be a prick
Part 6 - Wrapping up

Part 2 - Requirements and you
When you give away a project to be done by someone else, the first thing that you will have to do is to come up with the requirements.
This seems to be easy, and everyone wonders how their projects become so garbled in the process.
Now, here is a little secret:
Writing requirements is hard.

Writing good requirements takes practice, patience and a little secret.

The secret to a good requirements document:
Treat the requirements document as if it would be the only thing that stands between you and checking off the task on a list.
Because that is what it is.

Someone who would not know your project or anything else about what you are trying to do has to be able to look at the list and see if an item has been done. Because this is what is going to happen the moment you enter a dispute over a project outcome and - ultimately - your money.

As this all seems cut and dry, here is a real-life example.

I was working for one of the top international banks as a project manager at the time when this happened.
One part of the project I was involved in (thank you, I was not involved in the part that went south) had the following requirement written down and sent to India.

Requirement 3465x/b: Implement a print button as seen on graphical mockup 577254b.

What happened?

Well, the print button was implemented as per reuirement and mockup from the graphics department. One tiny thing: It would not do anything when clicked on. Yes, you heard that right: Nothing would happen.

Whose fault?

Although it would be easy to blame the programmer (and it was tried) He did NOTHING wrong.
He implemented the feature exactly as requested and specified.

Yes, you could say “But he should have known that it should print the page when clicking on the button.” But I disagree.

Why? Because there are easily a few dozen questions like this:

• How should the printout look?
• Which print function should I implement? Is there a print function available for this program already?
• Should or could we use a third party library?
• Should it print physically or convert the page into a PDF?
• Which part of the pages am I supposed to print?
• Should a legal notice be attached to the printout?
• Which font should I use for printing?
• Should the logo header be included? Where is the high resolution logo?
• …

This is what happens when you write shitty requirement documents.
Another drawback is insecure and less productive coders, as they are having to guess your intentions along the way.
Time and cost estimates done on bad requirements are also way off.

How to write a good requirements document

• Treat the document as what it is: The only evidence of what you want to have done. Telepathy does not enter the picture at any point.
• Divide the document into sections according to screens / pages
• Divide the sections into features / work packages to be done.Each feature should be described in a way that makes it easy to identify it as “done”. For a bonus, it should be possible to identify a good implementation from a bad one.

In the above, badly done requirement, implementing the button was “done” flawlessly.

Also:
Update the requirements document with every change and communicate this clearly to your programmers.

Another example:
I want a button on my landing page that leads to my affilate offer versus a redirect page.

Bad:
Make a green button, leading to redirect.

Better:
Put a green button on the lower page, leading to redirect.php

Better still:
Put a green button on the lower page, just before the footer.
Clicking the button will lead to redirect.php.

Best:
- At the end of the text container, put a green button. The button should be labeled “Claim your prize NOW!”. The color code for the button is #00FF00. See attached screenshot of layout (layout_mockup_01.jpg).
- When the user clicks the button, he is directed to redirect.php in the same directory. The link opens in the same window.
- Please contact me with any questions.

Drawbacks to this method
I am tempted to say “NONE” but of course there are.
You will be spending more time on your requirements and you will still mess it up sometimes. Live and learn.

Advantages of this method
Your coders will know exactly what is required of them, leading to them being more productive and feeling more secure in what they are doing.
You will get better results and the chance to dispute badly done work.

Join me for more fun in part 3 -Tracking features and bugs

::emp::

Part 1 - Introduction and Description of the problem
Part 2 - Requirements and you
Part 3 - Tracking Features and Bugs
Part 4 - The little black book that could
Part 5 - Your developers - Don’t be a prick
Part 6 - Wrapping up

Introduction and Description of the problem
In this series of articles (yes, this is going to take a while) I am going to give away advice on how to manage those freelancers.
Some people who know me for a while do know that I am an IT Project Manager at day, and an affiliate marketer and SEO freelancer at night.

I have also given away free advice regarding project management.
As this was often the case in answer to some thread complaining about idiot programmers or stupid Indians, it normally fell on deaf ears. Because - let’s face it - what the people wanted was someone to chime in, not someone to tell them they have been doing it wrong.

Now, this series of articles is going to be about how not to get burned when using freelancers to outsource your work.

Every article is going to present some problem you will encounter in your outsorucing and also provide a pointer on how to avoid or remedy that problem.

In this first article in the series, we are going to take a look at

Why outsourcing sucks - the root of all evil

Looking at the complaints about outsourcing, it seems as if it is a really, really bad idea.
And often times, it is:

• The workers speak another language
• The workers do as little work as possible
• Corners are cut whenever possible
• The end result is not what was expected
• Work is not finished
• Work ends up costing more than planned

The sad truth is, that all of these are traits that are inherent to outsourcing.

Like an ugly child, outsourcing was born like this.

To understand my point, we have to look at the model of outsourcing, as it is done on the web nowadays.

Person A <— fixed offer <— Person B
Person A —> requirements —> Person B (worker)
Person A <— finished product <— Person B
Person A —> fixed payment –> Person B

What we see here is a crude diagram of how it is supposed to work. As the employer, I have an amount of cash, which I am going to spend for a product or service. The worker is supposed to deliver the products of his work to me when finished. Depending on the product, I will also have the right to some minor edits before signing off on the work, or to refuse to pay when the work done is abysmal.

This, however, is a fairy tale dreamt up by some stoned economics majors seeing pixies in the sky.

In the real world, this model quickly dissolves into a pile of horse manure. And, believe it or not, all the reasons can be found in that diagram without altering any of the ingredients.

Now, of course, comes the point where I dissect the problem. I will do this by pointing at the elements in question and explaining the real world equivalent.

It starts with the amount being paid.
This amount can be the outcome of a bidding war (freelance sites), or a fixed offer by the employer. Anyhow, this amount is often times a slap in the face of any real person having to buy food, etc. This is also why freelancing work often wanders to countries such as India or Russia, where the mighty US $ can still buy stuff.

This is also the root of all your worries. That, combined with your requirements.

The requirements are supposed to build the basis of the work. They describe the product as it should be, the form the matter on which the amount for the work is based and also serve as the document on which faulty work can be disputed.

Also, the requirements I have seen on the net so far can for the most part be described as a giant load of horseshit served with a side of sucking sweaty donkey balls. Don’t even ask about the dessert.

Combine these two and you get the current state of outsourcing:
Worker B will cut any corner he can find in the requirements to be able to still make a living on the shitty amount employer A is willing to pay.

Mostly, this state of affairs doesn’t make anyone happy.

The following articles will try to help you find a way to make it bearable, or even succesful.

::emp::

I admit it, I am a bit of a gadget freak. I had a digital pocket camera (a nikon) very early on in the game and paid a premium for it. I have gone through several PDAs and got an iPhone now. For our car, my wife and I got a GPS, for my online endeavours, I got a few scripts lying around.
Doing only this - buying tools or gadgets will do nothing but cost you money.
Those tools, as they are lying around unused are nothing but costly.

Some might even keep costing as they need electricity or monthly fees of some other kind.
But the only thing you need to do to turn your posessions into assets is to simply use your stuff to create wealth.
Here are three simple steps:
1. Inform yourself
This means to inform yourself of which tool / gadget / software is the best for the job and the most cost-effective solution. Look around, get informed, shop smart. An easy way to cut costs is not to fall into the brand-name trap and look around for competitors to the big name. Review sites and user opinions can be a big help in this.
2. Buy
After deciding go out and aquire your new toy.
3. Use it until it breaks.
I am not even kidding around with this. I have used aforementioned camera until it stopped working after seven(!) years. On the way it got dings and scratches and got lugged around all over Germany, Portugal, Tunisia and Switzerland, taking several thousand pictures and even a handful of good ones to be turned into memorabilia and presents.
I have personally broken an electric saw after 2 years of abuse and kept my favorite CRT monitor for 8years util it gave up. The amount of abuse my scanner and printer have to take up with is criminal in several countries.
The same should hold true for every tool, domain and software you own. Until you do that, it will only be a cost, not an asset.
As you read this, I know that you own a computer and an internet connection (another returning cost) - great, write some content, tweak a PPC campaign, code a script - turn your computer into an asset.
As for writing content, why not take part in my WebWriMo scheme?
(404 words right here)

Right now, the old simian just thought he would point out two of the stumbling blocks new Affiliate Marketers often do not know about.

These, young grasshopper, are 2 things:

1. The time it takes to get paid
2. Fees of all kind

Net n - the time until the money hits your wallet

“Net n” Where n can be almost any number - is a common industry term for the time in between the transactions and the time the money gets send out to you.

And I am not even kidding, n can be any number - we can observe net 30 (very common), net 15 and many others in the wild. There are also bizarre constructs, like amazon.de’s net 30, but 90 days later payment.

Now, on to the stumbling blocks.

You have to reach the limit first, bub!
Net n normally only comes into account AFTER you have hit the magical limit of the advertising company. Be that 10$, 50$ or 100$, you have to reach that limit first before the clock starts ticking.

.. and then you have to reach the end of the month
Normally, if you hit the limit, the net n period does not begin ticking until after the end of the month.

With net 30 that could mean: You reach the limit on the 15th of July, the transactions are processed on the 30th of july, but the money does not leave the company until the 30th of August.

..and then it takes some time
Then you add processing and transfer time (checque or wire) which can add up if you are an international affiliate not sitting in the US of A.

What to do, what to know
Get informed. Know what your network means when it says “net n”. Get to know the limit, ask for rule of thumb times and figures as they apply to your payments.

Fees

Hey, anyone knows how to avoid fees, right?

Well, maybe not anyone.

Case in point - the credit/debit card for AMs
The blind ape was just recently offered a debit card as a means to get faster payments.
You register for the card, you get it and then your future payment arrive in a snap.

Only a thorough examination of the terms and conditions (spread over several files on two different servers) revealed this card to rob you blind with transaction fees and more.

AM beware.

What to do, what to know.

Again - get informed. Talk to your AM contact about fees, wire payments, transaction costs, etc..

Remember, if you want to start out on your own, it pays to be frugal and to be informed.

Unbelievable, but this makes the new iPhone even more attractive.

No, the old simian does not have one (yet).