Sure, in the back end you may have a million moving pieces, but the point is that your content publishers must have an easy time publishing workaday content.  Failing that, you risk many problems in a CMS implementation, like CMS user revolt (or at least high agitation), inconsistent content (by non-standard workarounds being used), and an unsustainable system (by concentrating too much on the one-offs).

Before diving into this more, note that concentrating on the simple use case is important for even the most complex implementations.  This isn't just a small site issue.  In fact, small sites can probably get along fine with a clunky publishing process.

Assuming you are following the Real Story Group's suggested approach for selecting a CMS by evaluating against use cases, some of the characteristics of a good publishing use case include:

• Start with where most publishers will start.  If you are in a high volume publishing environment, then perhaps you can assume everyone is already logged in and at the right place.  Usually, though, this isn't the case, and have to consider the log in process up to getting to the right place for publishing the content (sometimes placing the content can take time).
• Do not include any side-tracks, but do list the activities that will routinely occur.  If a publisher always has to include an image, then include that in the process.  If they rarely do, then exclude it.  If you plan on restricting what styling can be applied to the text, then include it.  If you plan on leaving this wide open, then this should be the same in the use case.  In other words, there isn't a one-size-fits-all use case, but needs to reflect your needs.
• Include the preview process.
• End with content being published to the live production environment, and viewed by an external site visitor. If multi-site publishing is a key part of your vision, then the content should appear on all the relevant sites.

Another key is to keep a razor focus on the maximum end-to-end elapsed time that elapses here.  In a news environment, perhaps the whole process needs to take less than a couple minutes.  In other situations, an hour may be acceptable.  In all cases, you obviously want to ensure that the publisher knows where they are in the process and what the next step is.

So where does this use case come into play?

• CMS selection.  CMS vendors usually want to emphasize the flexibility in their platform, but you need to keep your eyes away from the glitter at least long enough to make sure the simple publishing process is indeed simple.  Even if you have a simple use case, CMS vendors will want to emphasize all the bells and whistles during demonstrations.  Be bold and make sure that you see a walk through of your simple use case without all the possibilities thrown in.  In many cases, you will find that the straight through process is actually more crooked than it seems when looking at all the what-ifs.  
• Implementation.  Our attraction to complexity will perhaps spike during implementation, and so you need to make sure the implemented system successfully results in a simple publishing process.
• Training.  Training needs to be particularly high quality for this most common use case.

In sum, implementing your simplest publishing process may actually prove difficult, but at least you should be aware of this as early as possible...

Here are some steps you can take to reduce coordination time:

• Make the process understandable. Clearly communicating the process, delivering to that process, and communicating about the new system will work can reduce coordination time.  For reference, see this list of steps.
• Use simple forms where possible. By asking subsite owners to fill in the blanks of a simple form, the core team is both communicating expectations and also allowing the business unit site managers to provide feedback clearly and quickly. For example, when requesting a standard subsite, the subsite owner could provide: a) acknowledgement that they're read all standards documentation, b) agreement on particular points (such as that the subsite will need to follow some templated format), and c) answers to some simple questions such as site name, root folder, names of people who should get access, and so forth.
• Design to deliver in meaningful chunks. Instead of trickling information to site owners, deliver in meaningful and complete batches. For instance, when forwarding an inventory of current site assets the core team should highlight those areas of the subsite that represent issues that need to be resolved before migration can be initiated (such as embeded codes, forms, and such), rather than this turning into a long back-and-forth discussion.

The goal here is to avoid:

• Long discussions at any point
• Multiple handoff points
• Confusion

By not considering each new site as a completely novel implementation requiring in-depth discussions, you limit suprises.  Do this right, and you can deliver high-quality subsites relatively quickly with much less hassle for everyone.

What's the case for doing both at the same time?

• If you can't separate redesign from migration
• Budgeting ease
• Easier to sell internally
• General bandage removal approach (rip off the bandage all at once so the pain passes quickly)
• Potentially avoid doing some work twice
• Organizationally can't manage a program lasting longer (at least in the "best case" with nothing going wrong)
• If redesign is an extremely minor component, so separating would be forced

So, why consider separating migration from design?

• Fundamentally, to limit what needs to happen at the same time -- reducing significant project risk
• It always takes time to understand your requirements, and a redesign throws in more requirements that need to be understood -- separation means the various stakeholders can more easily be on the same page about what needs to happen and whether the site is working as it should
• Probably higher quality at the end
• Results sooner
• Can separate out different decisions
• Reduce chances of the entire project grinding to a halt

Ideally you could find a practical middle ground, such as minor (but high impact) redesign changes while undertaking a major CMS replatform.  I believe a deep redesign during a complex implementation / migration presents high risks. 

Hopefully the factors above can help you make the right decision for your organization.

Let's start with the assumption that if you have a large number of subsites, chances are you have complicated politics.  Your reaction may be to just do whatever it takes to get business units into the system, including adding complicated functionality specific to a unit.  I've personally been a party of this approach, but you can easily end up with Frankenstein systems that cannot be maintained or innovated.  Why?  If you implement a disjointed system then it's harder to regression test and to add features since you don't know all of the impacts you will have in making changes.

Let's consider the steps of a subsite launch:

1. Request.  The process for requesting a subsite.
2. Approve.  The process to approve or reject a site creation.
3. Negotiate.  Negotiating the details, especially the functionality.
4. Train.  Training the team that will be managing the site.
5. Create.  The technical creation of the subsite.
6. Embody.  The site owners adding their content.
7. Review.  Quality review before launch.
8. Launch.  Launching the subsite.
9. Maintain and Innovate.  Ongoing maintenance and innovation across all the subsites.

When deciding on your architecture and processes, consider the cost of each of these steps, and not just some.

There are several approaches / philosophies to subsites, but one extreme would be the completely lenient approach where everyone can do whatever they want on whatever platform they want.  In that case, steps 1 through 8 are easy (or last can be dealt with on a group-by-group basis).  But watch out for number 9: if you wanted to add a new and innovative feature across all the sites?  Share content across sites automatically?  Standardize look and feel for you site visitors?  Next to impossible. 

Probably the most common approach is a centralized platform, but where the core web team is lenient about what sites are created and the functionality details.  This can happen when there is weak governance, with the basic idea of "let's just get them in a common system first."  In this case, the request and approval process is easy.  But watch out: the Negotiate stage can take a long time.  Now you've got to not only work out site or group-specific functionality, but argue about which features should be added.  Also, the training and creation process isn't standardized, so takes more time.  Similarly, the review process can take a long time as there may have been misunderstandings of what is possible and not possible.  But the real problem is the maintenance and innovation.  The system becomes so complicated that it's difficult to maintain.  Also, if everyone did their own thing, then it also is difficult to roll out innovative features across all subsites.

Another approach is to "package" your subsites so that creating a new site is almost trivial.  This could include an extremely simple form that would be filled out to create a site, that would just have selections (no free-form written requirements) for the different options of creating your site.  In general, the negotiation would be simple since most folks would want to just fill out the form and get a site.  But if an option wasn't available for a particular group, then there could be a discussion of whether it was worth adding the functionality to the core system (or adding a parameter for an existing piece of functionality) so that it is preferably available to all sites for use.  Obviously negotiating changes to the core system would take time, but by carefully guarding the core functionality, and biasing toward packaging items for everyone, you wind up with a more stable system.  In addition, your system is more maintainable and features can be rolled out more easily across all subsites.  Training should be easier as well.  To pull this off, you will need strong web operations management, and in particular strong product management. 

Yes, there are other possible approaches.  But one thing is for sure: consider all the steps of your subsite and platform lifecycle when deciding on your subsite creation approach.