Every greenfield CMS project I've worked on in the last twenty years starts with the same plan. Get the most in-demand page templates ready so the content team can start pouring as soon as possible. The focus is always around starting to see pretty pages in all their glory, so stakeholders can point their finger and say, ΓÇ£That's the good guyΓÇ¥. Ok, if you don't get that pop culture reference, try this one which brings everyone back to reality. 

Everyone has a plan until they get punched in the mouth. 
- Mike Tyson

Yup, things happen. On a long enough project, you can have change with no adjustment to deadlines such as new requirements, losing staff, gaining staff (onboarding time needs a trainer too), and more. Hell, I've been on a project where we lost close to 1/3 of our development time, AND the brass moved up the go live date by announcing the new one publicly, which blindsided us. Talk about Cortés burning his boats! Yes, you'll have your staff knuckle down and put in the extra hours, but you'll hear even your most dedicated people murmur, “never again”, or “I'm out”.

Changes like this push out the ready-to-author dates, which puts pressure on development and content teams, and everyone starts feeling the stress. So how do we get past this predictable pattern? 

Content Driven Development

There's a few models for this type of development but what most fail to understand is, when you get right down to it, a CMS is just a container for information. You do not have to wait for things to be pretty before people start authoring! Let's start by looking at a classic development model for these types of projects.

1. Requirements are gathered, which sets up a roadmap for development.
2. Page and component inventory is created.
3. Development prioritization is completed, setting the order of what's developed based on which pages are needed first due to authoring demand (quantity or key feature dependencies).
4. Components are also prioritized based on which would be needed first by the pages in the previous step.
5. Development starts, with pages and components being released to a staging environment each sprint for authoring (once they have passed QA).
6. Authoring / content pouring is executed on the page types that are released and this continues in an iterative fashion until development is complete.
7. Final smoke and load testing is performed, and the site goes live.

The pressure points we're talking about today really come from #5 and #6 above. Teams think they need skinning, art, styles, accessibility, and more before the content pouring starts. By using a Content Driven Development Model, you modify the above list so that:

1. The development team creates the page templates and components with wireframes only, so they will only be able to take in content and render extremely simple markup (H1, H2, P, UL). The basic scaffolding would exist as well, so CTA Left is on the left, and CTA right is, well, you know….
2. These pages and components are released to staging where all authoring starts. This is much earlier than before, and likely before 25% of the overall project timeline instead of 75%.
3. Now that both teams are working, the components are developed to completion and with each deployment the site starts to look finished. No effort is needed from the authors when a release updates the staging environment, as the content is already in the CMS. The components are mature and render according to initial designs.

The Experience

The site will look simplified while authoring, but that won't slow anyone down. As you can see, the components would be developed enough to lay out on the page relative to others, and that's it. 

As the development team continues their work, components will have the more fulsome markup and styles to support the intented visual designs.

And that's the point! Teams have been indoctrinated into thinking they need the page to be visually complete before starting content entry, but technically it won't matter.

I've Saved Time and Money, but What Else?

The benefits are clear so far since you can see that the two team's efforts can overlap more, but there's much more to this. The development team can now make better use of the authored content with certain development tasks, such as:

• The site's navigation will have the right content hierarchy in place, which also helps identify the need for dedicated navigation fields if titles are too long, etc. 
• Developers have more effective content to test features such as search, page relationships, CTAs, lists, etc.
• Authors will have their hands on the CMS earlier, which would dramatically reduce their learning curve during the critical stage of go-live activities.
• Taxonomy is getting used, which allows for more effective testing against queries for content lists, etc.
• Content components that won't accommodate long text are identified sooner so they can be addressed.
• Accessibility can be tested sooner for things like background image contrast, etc.
• Load testing has real-world content to use instead of a few dozen generated pages.
• Security and workflow can be applied sooner, since most projects leave these as a post-initial content pour task.

This overall adjustment greatly reduces development costs through a shorter time to launch and improves the team's enjoyment of the project. Hopefully you can employ this method in your next CMS project!