one good way to start seeing more objects around you is to try to search for a pattern like this one in your procedural code : a group of functions operating on a certain kind of data structure. A classic example would be the stdio functions in C. You have FILE (which is your data structure) and then fopen,fclose,fscanf etc. which are the functions operating on FILE. This is object orientation at it's most basic (an object is some data and methods to process that data) even if C is not regarded as an OO supporting language.

There is only a small step from writing stuff like this :

FILE* ofile = fopen("test.txt","w"); fprintf(ofile,"%s %s %s",1,2,3); fclose(ofile)

to writing code like this :

FILE ofile("test.txt","w"); ofile.printf("%s %s %s",1,2,3); ofile.close();

So. you've grouped some data and some code together so it's easier to work with it. This is just the first step though, but the small objects you make will be very useful. You can make a small library of useful objects that way : file, string, date, time, point, rectangle, socket, regexp etc.

Also, you don't have to make the whole program OO. You can keep it procedural (and for most scripts that's the case), but you can use the above objects just like you'd use their procedural counterparts before. Slowly, and with experience both with OOP and larger programs, you'll see other parts of your work that would make sense as an object. On the other hand, some of them won't. And it's perfectly ok - not all problems can be naturally modeled as a system of objects.