Scaling your SharePoint application

Very often there is a moment in a project where one or more people go “uh oh.” What happens next usually defines the final result. Typically it is one arm of the overly dreaded triangle that is the immediate root cause of concern.

  • Time
  • Money/Cost/Budget
  • Scope

It is important to note that quality is not an input. It is essentially the output of the sum of the three. The quality level you’re shooting for is not absolute — it’s really part of scope. You have to articulate and repeatedly verify the bar needed to satisfy your customers. If a system performs the functions you say you wanted and you still don’t like it, then you got the requirements wrong. If you update the requirements to address your objections, you’ll discover that the scope is greater than you identified. That confusion is a telltale sign of a team with immature design capability. (It should never be forgotten that Project management is a subset of Program management.)

Enterprise deployments of environments such as SharePoint require careful pre-planning, expertise, and thoughtful consideration for “future proofing” the final deliverable. A little now, or more later really does apply. Knowing the difference between scaling up or out is not sufficient. Sometimes you need to step back and redesign and redeploy everything along with updating the project initiating processes as well. SharePoint is a nebulous product which requires understanding of SQL, WSS, HIGs, peple, and more. 2010 is going to make things even more “difficult” so take your time, talk to everybody involved, and have a process.