In this tutorial, you will learn how to create a solid release plan for your new Episerver CMS project. As a contractor, I work with a lot of clients and a lot of people who are new to Episerver. This means that I am fairly used to seeing companies struggle to figure out the best way to plan an Episerver project. In most instances, this is why the company hired me to help them 😊. Over the years, I have tweaked and improved my project delivery plan. In this tutorial, I'm assuming you know how to do all the design work and that you have a selection of pages as PSDs, I will help you create a project plan that will take these PSDs and if followed will result in an end Episerver website!
Agile or Waterfall?
The first question a project manager, or lead developer will ask on a project is agile or waterfall? Depending on where you work, you might not have much of a choice about the approach you take, but from my experience, Episerver websites seem to go a lot smoother when you follow an Agile methodology.
When I first started designing CMS projects, the convention at the time was to spend a solid week at the start of a project writing some giant monolithic specification document. Ultimately, no one ever read the document and half of it changed by the time the project was finished. This is why the upfront waterfall is a pain. Defining scope and cost upfront without knowing the end goal will not go well.
If you do a lot of up-front research and define how everything should work at the start of a project, in 6 months time the chances are things will change. Life moves on. You realise your once amazing plan that was based on assumptions is not perfect. As you gain a better understanding of what's required, things change. Changes mean the spec needs updating. As we are all busy people, often the spec does not get updated. Meaning that after a few weeks on the project it can not be trusted. All that work wasted 😢.
This is why only defining the minimum to get you through the next 4-6 weeks is good. It saves you wasting time and is more efficient. So assuming we agree waterfall is bad, let us assume you will follow an agile process. The next step is to identify what are the key steps that will need to be followed so you end up with an Episerver website!
Planning An Episerver Project
When it comes to project plans there is probably a near-infinite amount of ways that you can successfully plan and release a site. From my experience, this process works as well as any of the others I've tried out, so why re-invent the wheel?
01: A UX review is performed. User journeys, a top-level site map and some wireframes that define how the site hinges together get created. These documents roughly define what will get delivered in the project
02: Based on the designs and the user journeys, a number of Episerver pages and blocks will need to be defined. Examples of Episerver page types might be ‘Content Page With Left Sidebar, ‘Contact Us Page’, ‘HomePage’, ‘Full-Width Content Page’, ‘Listing Page’ etc. This needs to happen before development begins. I use something called a component catalogue to map out this process. As part of the component catalogue. I’ll define the components. Which blocks will be hardcoded and which will be editable by content editors (what will be converted into blocks/components). This split will be based on these criteria:
What content editors should be allowed to edit. For example, on a log-in page, the page template should be very rigid and shouldn’t be editable by content editors. You don’t want someone to delete the log-in component from that page, otherwise, the whole site would be screwed
What can be generic? If most pages will have the same page structure and the same components in the same order, it makes development easier to create a reusable component. If they have templates pre-set with these components installed content creation will be very quick. From my experience, creating every page in Episerver completely out of components is very tedious and long-winded.
Life is much better if you have a pre-set template that might take 5 mins to create and edit, on the other hand, a blank template that requires 15 components to be added onto a page and edited might take a content editor 15-20 minutes. A general room of thumb.. the more configurable you make templates.. the longer it will take for people to use them.
03: With the Episerver templates and components defined, go through each one and figure out any data feeds required. Define what properties the component needs, what need to be CMS editable, what global settings are required etc...
04: After looking at the components catalogue, at this stage technical constraints are usually voiced, rough timescales are considered and the design is usually refined to create an MVP/first deliverable that meets the client's expectations and timeframe. This is the time when you look at things asked for in the design and figure out if you can do it within a reasonable timeframe, at this stage certain things are usually de-scoped, or, simplified as it will take too long to build/not realistic.
05: A static HTML build can now begin. This is the site the front developers will work in
06: The Episerver website can be created
07: When the static site has been created and signed off, HTML can be integrated into the Episerver website.
08: With the website created, QA can begin
09: Create infrastructure. Production environment set-up.
10: Content population by content editors
11: Performance testing should be undertaken with time allocated to fix things
12: Go Live! (create a release runbook)
13: Drinks down the pub 🍻🍻🍻
That in a nutshell is a very simplified project plan. Follow the main steps are you will have an Episerver website out in production. Happy Coding 🤘
