John,
With some restrictions from OS itself it's possible. First restrictions as is from MSDN :

"Windows 98, Windows 2000: The system restricts which processes can set the foreground window. A process can set the foreground window only if one of the following conditions is true:

The process is the foreground process.
The process was started by the foreground process.
The process received the last input event.
There is no foreground process.
The foreground process is being debugged.
The foreground is not locked (see LockSetForegroundWindow).
The foreground lock time-out has expired (see SPI_GETFOREGROUNDLOCKTIMEOUT in SystemParametersInfo).
Windows 2000: No menus are active. "

Now a little test form (form has custom WordHandle property):

*Load
public oWord
DECLARE integer GetForegroundWindow in WIN32API
DECLARE short SetForegroundWindow in WIN32API integer
DECLARE short IsWindow in WIN32API integer

*CommandButton.click 'Instantiate word'
oWord = createobject('Word.Application')
with oWord
	.Documents.Add
	.Visible = .t.
	.Activate
endwith
thisform.Wordhandle = GetForegroundWindow()

*CommandButton.click 'Word to Top' (or a timer event)
if IsWindow(thisform.WordHandle) # 0
   =SetForegroundWindow(thisform.WordHandle)
endif

This brought word to top under W2K as long as active window was VFP itself (working on another form timer event too did it). If I was say here on UT window than word just flashed on taskbar which was expected behaviour.
I don't think with word97 it'd differ but not sure.
Next if you should do it via doverb(-2) I think w/o a general field you could just use an OLEControl class too.

Hope helps
Cetin