Starting a new project can sometimes be fun and easy, sometimes the sheer size and complexity of what's being asked can be quite daunting. In today's guide, I'm going to cover my rough thought process when it comes to planning out a new project.

Getting Started

One of the biggest common pitfalls that I have seen numerous times are the project leads who don't take the time to understand the client's business and figure out why they want to build a new site, what the key bits on the website are to them and how the site's going to make money.

I think a lot of projects start with a design/UX period and then at some point the designs get agreed and the project gets handed over to the developer. In this handover, in a lot of circumstances the development team hasn't spent enough time with a client and don't fully understand the important aspects for the clients.

Without knowing what really matters to a client, as a team, it's really easy to focus attention and efforts on the trivial and miss out on delivering the important parts in an exceptional way. This initial stage for me is the point of finding out as a dev team where we should be extra vigilant. What functionality is mission critical. In most instances, this is usually a 1-2 day process of just asking silly questions and trying to fully understand how the business works and makes money.

Recently, I worked for a company who's highest priority feature of the website was an enquiry form. The form was very simple, but it generated most of the leads for the sales team . I was doing consultancy with this company and they were using a partner to do the actual development work. The partner kept doing releases for various bits of functionality but never understood this importance which resulted in the company losing leads.

After this happened a few times the partner was sacked. If they had understood the importance of the form to the business, then they would have been more vigilant. If they did a release and the new functionality didn't work that wasn't the end of the world. If the form broke the company lost money and that was what they cared about.

In the partner's perspective, it was important that they 'tested' their new work fully and not to worry about existing things. If they had focused their efforts on the important things to the client, they might not have been fired.

Splitting Up The Design

Next stage is going through the project and trying to split it down into smaller chunks. As we're working with CMS content that can be updated by content editors, we need to think about how the design will be broken into data-types, editable properties, and templates.

Questions like how can I group document-types properties into similar tabs to make content editors lives easier need to be considered. In most instances, I will always go with an approach where all content is configurable. Some people might think this is overkill and it can slow the CMS up, however, I always use the output cache to cache Umbraco page for speed so I tend to favour extra work now so an emergency deploy doesn't need to be made later, after the marketing department wants to change something you never imagined.

Project Size

The size of the site and how content editors work with Umbraco has a large role in my decision in how I architect the project.  A good principle to follow is try to make pages as generic as possible. This can be easier said than done, though. If you have too many document types all with slight variations, the content editor will get confused as to which document types they should use.

The more document types you have, the higher the maintenance costs become when you need to make changes. Umbraco out of the box doesn't provide a really nice modular approach to breaking up your design as some of the other CMS solutions, but it is possible. If you create rich text area on a template and provide a number of pre-set macros you can allow a content editor to have quite a large say on how they want the page to appear.

Using this approach means you can stick with a handful of document types and allow the editor to drag in custom properties, as and how they see fit. Instead of creating macros, another trick is to allow content editors the ability to add custom content to child pages.

You could design a 'carousel data type' that can be added as a child of any page. In your master page, you can have a section to check for this child page and display a carousel, where appropriate. It's this use of creating modular components that will make your website's future maintenance nice and simple, or a nightmare no one wants to touch with a barge pole.

From my experience, how a module goes depends on the client and it's usually a question I'll ask them at the beginning. It's a hard balance trying to find a structure where you restrict enough for the editor not to break the website, while still giving them enough creative control and freedom to generate the content they desire.

I used to work for a CMS vendor called Immediacy, within the professional services department, we helped partners' build projects for clients. The biggest mistake that causes the most amount of hassle and pain on any of the troubled projects was not working with the CMS. Try to keep the rendering of your website as a normal '.net website' as much as possible using Umbraco as the data container. Just because Umbraco is open source, you don't need to try and customise it yourself. If you find you have a requirement that Umbraco can't do, think maybe about implementing via JSON and Angular and create a custom section.

Business Logic

Every website will have custom business logic. Building a project in Umbraco is very similar to building a normal .NET website. The main difference while working with Umbraco is the routing is slightly different and you get a cool API to deliver your context.

With Umbraco 7 onwards, I would always recommend using MVC as a no-brainer. With MVC you can very easily create a 3 tiered approach where you separate data from logic. I'm also a very firm believer of being able to unit test my work so I would always recommend uSiteBuilder. A lot of people who haven't worked with CMS systems like Episerver, sometimes scoff at this 'extra' work. Strongly-typed objects allow you to deliver sites faster and with fewer bugs.

After I have worked out the functionality that will affect the content editors, the next step is to concentrate on the areas that do not concern content. These business logic tasks are things like pulling data in from external API's to pass down into a controller, providing web API endpoints for the website to third party solutions, working with data outside of Umbraco, content import, re-directs, content editor permissions. All these sorts of tasks will be split into classes in one or more different class libraries that exist in the solution, but, generally, will never live in the website itself.

Project Approach

After I have a component catalog of how I'm breaking the site down, the next thing is to consider how the project is going to be delivered. If you have a small project, weekly sprints until the project is out of the door is the best route.

If you are working on a massive beast of a project that might take one year plus to implement, then deciding on an MVP (the minimum amount of stuff you can show the client to prove you're doing some work) is essential to keep the project plates spinning and keep everyone happy.

My philosophy for breaking work up and prioritizing sprints is to do the unknowns and hard things as soon as you can on a project so you don't have any shocks down the road. There is nothing worse than thinking you are nearly done with a project then, at the last minute, realize you have another 4 weeks' worth of dev work to do, due to lack of understanding over something.

Starting A Project Base

When it comes to getting started a lot of people use a sample site as a base and build a website on top of it. I personally don't recommend it. All sample sites have little documentation why, how or exactly certain bits of code were used. I prefer to start from a base site I've created that contains the minimum files and configurations (like the structure map set-up and Nuget package) included to start my development.


Planning a project is a massive undertaking. You will never work on two projects that are the same so giving a one size fits all amount of advice is difficult. On most projects, I follow a very loose and flexible plan. At the start of a project, it's key to understand what's important to the business and to break the project up as much as possible to allow you to provide some resemblance of an accurate estimate. After you start development, prioritizing your hardest tasks first will give you a better chance of completing on time. If you stumble on a show stopper, the sooner the problem is found the better.