Hi John,
Staging for content managers is where you will have to engage closely with the business, document their processes, read up on their strategic goals, and build a system that compliments their work and meets their measures; always remembering that you're trying to improve their work, not yours.
The latter point is often not full appreciated when a traditional IT group is tasked with implementing a CMS. The IT group has to understand that the CMS ultimately give the business control over the prupose, use and content of their web site or intranet. The old-style content management role within the IT group is and should be made defunct. I've seen myself how difficult it is for IT to give up these roles, but it means jobs in some cases and that is understandable.
Once you have all the stuff written up, you then spend a lot of time testing and assessing modules for their suitability. It's only a starting place to ask in forums "which module is best for this or that purpose because they all vary greatly in small but often very important details. You have to really get familiar with DNN and how modules work together,
Some modules provide draft and approval workflow built in. It all depends on the procedures you're trying to implement. Staging content means that someone has all the tools they need to create and revise that content without having it made visible to people who don't need to see it. If many people are involved, you will have to devise a complete set or roles and responsibilities and apply appropriate permissions to folders, pages, modules, module functionality, and the FCK editor.
One stumbling block you will face is that many modules do not allow for a complete content creation workflow without providing page-edit or even administration rights to the user. This is something I spend much time trying to get developers to understand and implement, but it is only successful with those who have some corporate experience.. or simply have good customer focus.
For your own staging as the system maintainer, it depends on how big the system is. A portal system that doesn't have a lot of raw images or video files is not really all that big. I do it by simply duplicating the live portal to my staging setup and then I can test modifications and updates on that to ensure they work before applying them to the live site. Carry out your developer updates on the live system at regular intervals... e.g. once a week or once a month at a set time. By then you will have done your testing on the duplicate portal and will know if it works or not.
I realize it's a bit of a mind shift from the old ways, but any active live site is managed like this... there's just no way to run Facebook on a dev server and have all the users post their stuff to that hoping to see it go live by the end of the week. Dynamic sites are meant to be live... and that's why we see scheduled outages for system maintenance.
Hope that helps,
Rob