Planning and Architecture
Front end technologies can do some cool things, but from a programming standpoint they're pretty limited. In addition to maintaining the website, planning and architecture are necessary to mimic the illusion of application like functionality on the client side. These jobs typically can't be jumped into, they need some time to at least figure out what the project is, what it should do, and why it should be done at all.
Requirements: We need to look over feedback from our users and generate potential projects. We need to conduct reviews of our operational systems to locate opportunities for feature enhancements. We need to perform gap analysis to see if there is whole new functions that we need to implement. And we need to create a dialogue with our users to hone all this data down into detailed requirements and project specifications. Written documents that specify what a project should do, what it won't do, why we want to do it, what the alternatives are, why we chose the approach selected, why we didn't choose the options that were passed over, and what our expectations are for the final results of the project. And somewhere in there, we need to prioritize projects and encourage people to jump in on high priority items (even if there are sexier projects lower down the list).
Planning: Once we have a target to aim at, we can figure out how we're going to get there. For a large project this may be fairly involved, but for small to medium projects, the requirements are actually much harder to complete than planning because users are so intimately involved. Once you sit down to planning, it's now a technical problem. With that said, project planning needs to consider two main features of code construction. First and most importantly, you must manage risk. Push easy parts to the end of development. The more risky something is, the sooner you want to do it. It requires more time to attack these difficult problems, so you need get started; and in the unlikely but disastrous event that you cannot complete the project, every minute you've spent working on it is wasted. If the project is going to fail, you want it to fail quickly. Once everything is ranked by risk, modify the order based on testing needs. Testing must occur throughout the process and should be as real world as possible. If you need to build one piece in order to properly test another, you should build it first, or if not possible, as soon as possible. The faster you fix a problem the smaller it is.
Architecture: Large projects especially require some high level construction decisions to be made. The physical and software setup of a project need to be decided: where is it going to live, what are the advantages and limitations of those choices, and why were those decisions made. The deployment and maintenance of the new components, applications, or features need to be considered. How are the new features going to get into the production environment? Are there new tasks that will be necessary once the new pieces are in place? Are there old tasks that will be eliminated or changed? Are there ways to mitigate potential problems? No feature, regardless of how amazing it is will be workable if it requires hours of daily maintenance to operate. Once all these decisions have been made, the architecture needs to be implemented. This serves as a foundation for construction of the project, and until it's in place, you literally have nothing to build your program on.
So if you have a knack for working with end users and research, and documenting those results into specifications, or if you're a planning / architecture guru, check out our beta website to see what you can add to our project planning and development process.