I'm not going to re-write the article here, but I think that some key considerations and things to remember is that not every test can be automated. There are different reasons, whether it's because of tool limitations, feasibility or your own knowledge of automation.
I'll usually create 3-5 phases for an automation project. First, I start with the things that will show the greatest amount of return on investment. Note: This may or may not be the simplest tests to automate. For instance, a test that tests a drop down box may not be something that will show much ROI. The reason being, I can test it once and be quite confident that it won't show a defect after that, as long as the functionality of it doesn't change.
However, there are things that can be automated which will directly impact my time. This might not be tests either. These could be administrative tasks. So let's say, for instance, that every single morning I have to manually compile data from a spreadsheet and put it in an email to my PM. Well, why not automate that? What about ghosting a system for a new test cycle? What about installing daily builds to test machines? What about setting up test-specific variables, registry keys, input files, databases? These are all tasks that use up your time during the day that will provide an immediate ROI to the company. In fact, they'll probably be the biggest provider of ROI to the company, since every single test case you write will be variable in its degree of ROI, because some areas that you test may never show a defect, so this is automation time wasted.
9 out of 10 people I prove wrong agree that I'm right. The other person is my wife.