The purpose of technical planning is not making implementation level decisions. Instead, it is to determine the relevant technical considerations and risks for a project and to gather enough information to ensure that scope is understood. After the considerations, risks, and scope are understood, high-level decisions can begin to be made.
In technical planning, it is also important to understand that the longer a decision can be delayed, the more information will be available to make said decision. In other words, waiting until the last responsible moment will often yield the best decision.
For Starters
Two initial technical planning deliverables:
List of prioritized goals and considerations upon which all other decisions should be based
List of potential project risks that need to be mitigated
The listed risks could be pre-existing or risks that are being introduced by new goals. Often this is the most important list for a project. The sooner you can identify problem areas, the sooner you can set expectations and mitigate the risk.
After these initial list deliverables are complete, any number and form of deliverable may be required based upon the project requirements.
Goals
Our three primary technical goals for the sparkbox.com rebuild are:
Make it fast
Separate content management from content delivery
Continuous delivery for our site
On the first goal, the answers are pretty obvious around why we would want the site to be really, really fast. Any web site or app can be made better by making it faster. However, we feel this is an especially important issue with a responsive website. Overall, websites have become heavier and heavier while connections can’t necessarily be counted upon to be faster (3G, Edge Network, etc). Responsive sites are as guilty—if not more—for serving up inefficient, less performant sites. We aim to address that.
Secondly, we wanted our CMS to become a multi-channel content delivery system much like we’ve heard called for by content strategy circles. Overall, we desire to support a content strategy that is agnostic of delivery platform. We want to build something closer to a true content management system.
We have strong feelings about our third goal for continuous delivery. Most development teams have built so many barriers to putting code into production that teams are afraid of releases. That doesn’t make sense. During the development of our site, we will be using and perfecting our release process. We want to make the release process so painless that changes can be made quickly and easily. While this can make it easy to introduce problems into our live site, the fix could be applied just as easily. Continuous release also encourages small releases, and that allows the type of experimentation culture we wish to embrace at Sparkbox.
Risks
The two major risks resulting from our primary goals:
Reliability decrease by adding additional layers
Overcomplicating a simple website
Risks for our own site are a little different than most client projects. First, there are few of the political or budget-type risks that can be common for clients. Also, this is a complete rebuild, so there are no considerations to integrate with existing solutions.
The largest risks for this project have to do with separating out content management from content delivery—two layers in a system that currently has only one. Since we are adding new layers to the overall system, this has the risk of decreasing availability and reliability. There are also some concerns about long term costs by adding this additional layer, as there will be two entities that need to be managed going forward that have dependencies between them.
I believe that these two risks can be mitigated with adequate testing. Since we are rolling out changes to production as we go, we will also be able to experiment thoroughly before migrating completely to the new site.
Wrapping Up
As mentioned before, our goal is to wait until the last responsible moment to make technical decisions, so several of our implementation details are still being worked out. However, the above goals and risks will be considered throughout the project as decisions are made.
We feel pretty good about the overall direction we’re headed, and we’re excited to get it rolling and test things out.
