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.
(30:51)
Listen:
Related links:
Like this? Here are some of Mitchell's recent posts.
- Netbooks: Popular but will you buy a Netbook next time?
- My 15 favorite smartphone apps - From TweetDeck to Math Blaster
- Podcast: Virtual Machine Manager + Hyper-V Live Migration = Enterprise Ready
- The Curse of the Ribbon Menu
- Windows 7 Feature Focus: Libraries
Recent Podcasts:
- Mike Schutz, Microsoft. Essential Steps For Securing Hyper-V
- Sarah Haase. Guiding SharePoint Users To Success at BestBuy.com
- Sam Ramji, Microsoft. Why Microsoft contributed to open source
Mitchell's book recommendations:
- Pro Hyper-V: Expert's Voice in Virtualization
- Beginning SharePoint 2007 Administration: Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007
- Beginning Ruby: From Novice to Professional, Second Edition
- Beginning C# 3.0: An Introduction to Object Oriented Programming
- Programming .NET 3.5
Also visit Mitchell's other blogs and podcasts:
Visit 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.)