How to Properly Plan Your CMS Project

p>The hardest part of most projects is usually just getting started with a plan of attack. This stage elicits a sensation of fear and dread in some clients, most likely because if you don’t plan properly, the project’s chances of success will be minimal at best.

This concept applies for almost any undertaking, whether it be home improvement, writing a book, or developing a website. In the past, we’ve spoken about the process of developing a website or application. The first step, an essential component of any development project, is to undergo a phase specifically to discover and architect what your project looks like.

At NPG, we do this by conducting a series of sessions with potential clients and then assembling a variety of documents. These include a generalized findings document, which outlines the business objectives, overall technical landscape, and future considerations. It also includes a complete technical architecture, which is an in-depth document that outlines every aspect of a project: who the users are, what the use cases are, what features need to be built, and how all of these features work in relation to each other. Architecture documents can be complex and detailed – even in some cases hard for a client to read.

But, before you even go through that process above, how can you best plan and prepare for your project? What helps you get the most out of a discovery session? This post is meant to help guide your preparations for in-depth discovery, with the hope that being prepared for the session will produce the maximum amount of value for you and your company. With that said, we’ve assembled this list to help you plan and prepare for the architecture of your CMS project.

Prepare Your Business Logic and Top Level Objectives

There is a reason you are about to commence a CMS driven development project. It is important that you take that purpose and develop the top-level logical requirements from your perspective before proceeding with a discovery process. Thankfully, this is a mostly non-technical endeavor.

For the purposes of this post, let’s contemplate a hypothetical scenario. This sample project would be a SAAS application that offers subscriptions to industry reports and data about “widgets”. What is a widget? I have no idea. In order for this SAAS application to work, it needs a comprehensive content management system for the reports and content to be distributed.

Obviously, it also needs an integrated commerce and subscription system, in addition to tools to help manage the business.

Coming into a discovery phase, you should know at a top level that your application needs a baseline of features. It is helpful to assemble those features into a list:

• Informational, marketing website: You need this to market the business, and sell subscriptions to the service.
• The application itself:
  • How it works: at a high level, how do users interact with this software?
  • What unique features drive the value proposition?
  • What format is the content? HTML/Text, PDF, or Video?
• The tools you will need to administer the site:
  • User controls: how will you manage the users and their accounts?
  • Site content controls: how will you manage the website and application content?
  • E-commerce controls for customer service: how will you manage the commerce component?
  • Reporting: what data do you need to operate the business efficiently?
• Pricing and Subscription Logic:
  • How do users signup?
  • Is there a free trial?
  • Is it monthly or yearly? Are there discounts for long-term subscriptions?
  • Do you accept coupons?
  • What is the payment gateway?
• How all of this works together:
  • Do you want to piece together many different software platforms?
  • Do you want a custom framework with all pieces living in one place?

Phew! This list is clearly just the 35,000-foot view. However, it isn’t unusual to have a potential client who has an idea but isn’t clear on the top-level list of features and use cases. By at least assembling a list of conceptual features and requirements, your discovery session and process will be much more organized and productive.

Prepare Your List of Must-Haves, Nice to Haves, and Wants

Now that you’ve assembled your top-level list of features or a rudimentary specification, it is time to figure out what the priority of items on the list are. In any development process, you want your first completed version to be a minimum viable product or an MVP. This means you need to determine which items are the features that can enable you to prove the concept of your product and business model with the minimal amount of features or specification.

In our case, based on the above listing, what features are must haves? What features would be nice to have? What would be something you want, but you can probably live without?

It is important coming into a discovery process that you have a clear understanding of this concept. Most competent web development firms will present you with the best options to develop your project. And the best firms will give you a plan going forward – beyond the MVP – to version 2, 3 or 4 of your application.

Having an organized list of features and their relative importance makes it easier for the agency to assist you in creating that plan. However, this doesn’t mean you should leave out the future phases and plans when coming to the table. As you’ll read below – developers need to know where you want to go to make the most accurate technical predictions. Be thorough, but be realistic about what you absolutely need now, and what can wait until later.

Be Goal-Oriented

Sometimes clients have issues with the first two steps. It could be based on a lack of understanding of how an application or website can work. It can also be tunnel vision: being super focused on the product but missing out on some things they’ll need to make it a success. This is all okay – discovery as a process is here to educate you and fill in those missing gaps.

One trick that can be helpful in this case is to focus on where you want to go. Much like any journey, it’s good when you start with an idea of the destination. Granted, start-ups and online software oftentimes will pivot. And there is a lot to be said about agility throughout the development process.

But at a high level, what are you attempting to accomplish with your MVP? In our scenario, your vision for the future can be simple. Maybe you want a fully functioning application that allows users to have control over signing up for an account, the ability to search all of your research documents and mark their favorites with the ability to download. And, you want this done in 4 months. That is a clear goal.

Or maybe you have business objectives. You know you want to build an application, you know you want to distribute these reports as there is a need in the marketplace. You aren’t sure how to build out the platform, but your goal is to have 500 subscribers one year from today. This is a valid objective too. The point is, having a goal in mind is going to help you wade through the development and design options and nuances.

Your development team can take your goals and build out technical requirements that will get you to your finish line in the most effective way, with an eye for the future. Without this clear vision, the smaller decisions get more and more difficult to make, and those small decisions can become highly consequential.

Research the Market and Competition

It’s important to research all the competition in your industry quickly to see who the other players are in the field you are about to pursue. There are a variety of reasons why. First, we’ve been through many development projects where halfway in the client loses interest because they found someone already operating the same model they are working on building out. Finding an idea-killing competitor exists after you already invested time and effort is a common reason that projects fail.

Hopefully, you’ve already done that level of research before reading this post. Most entrepreneurs do! In that case, the challenge is conducting more low-level research, which is necessary because it’s the best way to learn from the successes and failures of your competition.

Research means finding who the competition is, signing up for their service, and being an actual end-user of their product. It means scouring their support forums to find user pain points, reading reviews by trade publications that detail the best and worst part of their platforms. You must immerse yourself in the competitor’s products that are available to understand how you can make your future product a better alternative. If you don’t feel you are an expert in the arena you want to play in, then conduct more research. Being as thorough as possible during this phase will lead to a much more productive discovery phase.

Think About Branding and Messaging

Branding and messaging is something that every entrepreneur treats a bit differently. About half of our potential clients come in with a logo and brand guidelines already developed. I think that for some clients, having these assets make it more of a “real thing”, and provides an inspiration to dig into the more challenging phases of developing the project. For other clients, it’s a complete afterthought. Sometimes customers come in without any idea of what to call their project. The former scenario is much better than the latter.

Ideally, you want to start developing your product’s personality as early as you can. It’ll guide you during decisions you make along the way. And, it becomes immensely helpful during the development and especially the design phases. In many ways, undergoing a quick design project before doing discovery is a positive to bring to the table. It reinforces your commitment to the project and gives everyone a feel of what your company is all about. Even though many think a logo, tagline, and color schemes may not perform any particular function, you can be sure that they indeed matter when determining the user experience for your future application.

Plan for Post Project Phases and Scenarios

This is another important consideration that you should contemplate prior to discovery. What are your future plans? What does your business or product look like one year from now? What potential features or additions are possible?

This is difficult for many clients to consider. After all, it’s challenging to predict how a business will progress and grow over time. But it’s important to have some idea. Remember, an MVP is just what it says it is: a minimum viable product. So coming to a discovery session with a plan of attack for future features and possibilities is vital. Why? Because as technical advisors and your development team, we must make sure we consider those future possibilities when we architect the software solution for your business.

Sometimes we may make a technical recommendation not based on the MVP, but based on a future iteration of the software. This pre-planning is how you avoid building a successful project only to have to rebuild it a year later – a nightmare that we’ve seen happen more than a few times with customers who failed to consider what the future may hold.

Conclusion

Although the process of a discovery session may sound a bit arduous, it’s really designed with the success of your project in mind. The more time you spend researching, thinking about the details, and preparing before your meeting with a development team, the better your discovery will go. The goal is to make your business plan, build it, and then watch it come to life. We are always pleased to be your catalyst in making this happen, especially when you come prepared!

Remember, all of the hard work you put in pre-project will dictate how long the process of planning takes. Your effort is well worth the reward of organization and a clear timeline, bringing you that much closer to the finished product.