Podcast: Are you doing what it takes to succeed at implementing SharePoint?

What should you do to help your SharePoint projects succeed?

I talked with Dux Raymond Sy, author of O'Reilly's SharePoint for Project Management and Innovative-E SharePoint consultant, on this week's podcast about what we can learn from successful and failed SharePoint projects. Both of us had our various views and experiences, but a very common theme that emerged is working with business leaders and end users to help insure you're solving a valuable business problem, rather than offering SharePoint as yet more "features" from IT. You probably have your own philosophy about how to deploy SharePoint in an organization. Maybe it's the organic, decentralized, or users in full control model. Or maybe you provide guidance and expertise in implementing SharePoint. Or, maybe SharePoint is shunned, considered a big unknown or feared as something that could easily get out of control. Sometimes SharePoint is looked down upon because it's not a "real" development platform because many things done in SharePoint don't require writing traditional code. I've encountered all of the above when it comes to SharePoint.

SharePoint's strengths can also be its weaknesses. SharePoint is great for incremental, iterative development. Small groups of users can create solutions tailored to their specific needs. SharePoint is also built around a very powerful, distributed architecture. And it can be customized to do just about anything, sort of the Swiss army knife of IT platforms. But like any flexibly, powerful technology, SharePoint can become a solution looking for a problem, or used as a tool that eventually gets abandoned because no one thought about how it would be supported. And like most home grown applications, IT eventually gets involved as the business needs require access to data in and integration with other systems and databases.

During the podcast, Dux and I explored the topic of just how do you get SharePoint projects started off on the right foot. That usually means setting the tool and technology aside long enough to get clear about the business problem we're trying to solve. Then, figure out how SharePoint and/or other tools might be used to solve the problem. The old adage, "you can't get lost if you don't know where you're going", applies well. It's always good to raise periscope at the beginning and during any project to set direction and correct course when needed.

One of the things Dux recommended is not trying to solve too complex of an application at first. I'd say something similar, don't get so enamored with all that SharePoint can do, that you create a project so complex it's guaranteed to fail. Getting started with something simpler actually leverages the incremental, iterative model SharePoint facilitates very well.

Those are some of the thoughts on what we talked about on the podcast. If you're involving in using, supporting or creating SharePoint apps (or even at the consideration stage), definitely check out the podcast with Dux.



Related links:

Like this? Here are some of Mitchell's recent posts.

Recent Podcasts:

Mitchell's book recommendations:Also visit Mitchell's other blogs and podcasts:

Microsoft Subnet for more news, blogs, opinion from around the Web. Sign up for the bi-weekly Microsoft newsletter. (Click on News/Microsoft News Alert.)
Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2009 IDG Communications, Inc.