Dr. Paul Ronney of University of Southern California has a detailed list of tips on conducting research on his website. I found these tips extremely helpful. What appears below is a distilled version of these tips that I found useful during my PhD and postdoc.
When you start any project, you need to build an adequate background. This involves developing fundamental understanding, getting comfortable using the software, and getting comfortable with coding and debugging. In order to do this, you need to start with a simple example first. For example, its ill-advisable to start with a code for 1D boundary value problem with reacting flows, heat and mass transfer, and complex chemistry. Starting with a simple isothermal plug flow reactor with a first order reaction rate is much better as the coding / debugging is simpler and the numerical result can be compared to the analytical result.
This is the first major difference a student faces between course-work and doing research. Most often in a course assignment, the problem is already formulated and your job is to solve it using various tools at your disposal. On the other hand, research problems are open ended. Not only do we need to think about what are important problems or issues that need to be addressed in our field of interest, we also have to translate these issues into a problem statement that we will tackle using tools at our disposal. This involves translating these ideas into a mathematical framework. At this stage, we need to explicitly think about what assumptions were used in developing the mathematical framework. This is not a once-only process, but an ongoing process of rechecking and refinement.
Verify that the balance equations are correct. Ensure dimensional consistency. You cannot add 1 meters with 1 kilogram. A dimensionally correct model may not be accurate; but dimensionally incorrect one is definitely wrong! Likewise, its easy to make simple mistakes; remember 1 foot + 0.2 cm = One Poor Execution.
Do not trust the code. One of my professors used to say: a code is only as smart as the coder. Dr. Paul Ronney has a good discussion on verifying your code. Some tips that I find useful in my work include:
Do not rely just on your memory. Keep a research journal, and note down every result that you obtain. You don't want to spend time re-doing things only because you were sloppy with book-keeping. Also, keep a section in your journal dedicated to new ideas. Jot down your research ideas, even the ones you think are "whacky."