Don’t Over-Build for the Cloud

Christian Buckley

Christian is a 6-time Office Servers and Services MVP, internationally-recognized technology evangelist and collaboration expert, and the Founder & CEO of CollabTalk LLC, an independent research and technical marketing services firm based in Salt Lake City, Utah.

  • Christian:
    I’m not sure that I agree with the “reduce your requirements to fit within the out-of-the-box capabilities of SharePoint” statement. Requirements are requirements. But very often, the things people see as “requirements” are more like “nice to haves” or “impress my bosses”.
    To me the key is to be realistic in deciding what your requirements are in such a way that you try to implement exactly what is going to drive improved performance in your organization. (Reduced costs can be good, too, but there’s not a lot of blood left in those turnips these days.) Taking a long hard look at what really matters in your collaboration software may lead you to a cloud deployment more easily than you might think.
    Just like any “upgrade” to SharePoint, in considering the cloud we shouldn’t view the efforts as technical move. Instead, we should be right sizing our collaboration efforts to make the performance of the people in our organization soar. Aim for innovation and excellence, not prettier logos or font sizes. Lip gloss may make us prettier, but it don’t make us smart. If the cloud can support the collaborative strategies in your organization, then get your team moving on it.
    M.

  • I don’t think we’re in disagreement here, Marc. I constantly advise people to “know their requirements” which means have purpose, understand the business results you are trying to achieve, establish clear measurements of success so that you know whether or not what you’ve built is meeting those requirements, and adjust your tools and systems and measurements as needed to fine tune.
    What we know is that simply “turning it on” and hoping end users figure it out does not work. Neither does attempting to replicate your last intranet platform with all of its integrations and complexity, but this time out in the cloud, and assume that this strategy will work. What what has shown to work again and again is a more thoughtful approach, piloting key workloads at first, then expanding as it makes sense. And I do believe people have caught onto the idea that using native capability and configuring the OOTB features before turning to development is the right approach.
    I do believe that most organizations over-build for the simple fact that they 1) do not understand their business requirements, and 2) they fail to understand how their end users work, and what they need to be more productive. So my argument is not so much about to build or not to build, but about having an understanding of what to build before attempting to build it.