Is this table designed properly I am trying to model the process of where one co-worker enters a statement of their proposed work procedure and another co-worker commenting and approving the statement.
Currently I have one table as such:

METHODOLOGY
  methodology_id
  entered_by
  statement
  entered_date
  status_code
  reviewed_by
  reviewer_comments
  reviewed_date


status codes are as such: 

1 = in progress by originator
2 = finished and locked by originator
3 = in progress by checker
4 = finished, locked and rejected by checker
5 = finished, locked and approved by checker
6 = approved method was unlocked due to revision to methodology
7 = the originator was changed with a new originator after method was approved
8 = the checker was changed with a new checker 


Should this be broken out as such:

METHODOLOGY_STATEMENT
  methodology_id
  entered_by
  statement
  entered_date
  status_code

METHODOLOGY_REVIEW
  methodology_review_id
  methodology_id
  status_code
  reviewed_by
  reviewer_comments
  reviewed_date


Right now the requirement is only one Review per Method Statement.
Either way could be correct.  

Choose 1 table if you want to make it difficult to change the number of reviews possible.  It may be counter-intuitive to want to make something difficult, but if it would actually be a bad idea to make it 1:n, then building in some pain to make the change has some logic.

But, you almost certainly want to go with two tables for long term flexibility.  If it was me, I'd put a trigger on there to enforce the 'one review per methodology statement' rule.  If that changes, just modify or drop the trigger.

One question to keep in mind, though:  if you go to multiple reviews, how would you resolve status codes that conflict?  For instance, what if you had one code 4 and one code 5 for the same methodology statement?

UPDATE:

...or you can do the much better thing and use a unique constraint as @Max Vernon suggests.