July 2008 - Posts

• Why SharePoint projects fail?

  This blog has moved. Click here to open the new site. Dan from Integrated Services, Inc. asked me to share my opinions on how to maximize your SharePoint investment. I will try to focus on how to avoid some of the classic mistakes that could ruin your project. It does not make sense to reinvent the wheel here, so I will try to reuse some the classic mistakes made on various IT projects. These mistakes are listed in "Rapid Development" by Steve McConnell. Steve is probably the greatest author when it comes to software project management. His books are "a must read" for anyone managing a software project. Steve calls these mistakes - Classic mistakes, and I will try to review those that might be related to a SharePoint project. Classic mistake No 1. Undermined motivation As I wrote before SharePoint is a tool for end-users. They will resist anything new. Your goal is to motivate them from the day one. There are no recipes how to do that, it all depends on your project. But you must have a business problem you are trying to solve with SharePoint implementation and you will probably need to start from that. Try to see how solving your business problem might also help your end-users to solve theirs. Classic mistake No 2. Weak personnel I wrote on building a SharePoint team before. Educate your people properly before you start a SharePoint project. Classic mistake No 4. Heroics A hero in a SharePoint project is usually a developer who thinks he can build his own version of SharePoint. SharePoint frontend looks simple, but it took Microsoft 6-8 years to build it, so a hero cannot do that on his own. In a SharePoint team you do not need heroes, you need a team of developers that can read documentation, blogs and troubleshoot problems. Although developers like to write code, take a look at 3rd party solutions like Nintex Workflow or Bamboo Solutions. These guys did a great job of building the cool software that can help you solve your business problem. Classic mistake No 7. Friction between developers and customers When building a SharePoint team you need a project manager (consultant) to handle customers and developers. Customers wishes on these project might be "fuzzy" so you need a person that can translate them to your development team. Classic mistake No 19. Wasted time during the fuzzy front end Fuzzy front ends? There should not be fuzzy front ends on SharePoint projects. There are books, seminars, blogs, articles etc. If your developers/system engineers would like to be best in bread they must educate themselves all the time. If they know everything about SharePoint, maybe they should learn more about Project Server, Groove, Performance Point, you name it. Classic mistake No 21. Inadequate design / site planning The worst thing you can do on a SharePoint project is to transform demo environment to the production. Once you educate your end-users on how to use SharePoint, establish a demo environment for them. The best approach is to use a virtual machine. Microsoft already prepared these for you, and you can download them here. You should motivate end-users to play with demo environment as much as they can. Their experiences will be very useful and you will be able to learn from these experiences and incorporate them into your production portal.  Classic mistake No 25. Omitting necessary tasks from estimates SharePoint is flexible but that does not mean you do not need to plan your project properly. You can download a sample SharePoint project plan here. Also review other articles about Planning and architecture for Office SharePoint Server 2007 on Technet. You will not be able to use these guides on every project but they are very good to start with. Classic mistake No 28. Requirements gold-plating Stay agile, expect change! If you did the motivation properly your end-users will have 1000 ideas on how to improve their SharePoint portal. These requests will probably be coming late in project lifecycle. Be prepared to fulfill them. Classic mistake No 30. Developer gold-plating Once your developers get use to SharePoint they will also have 1000 ideas how to use latest-cutting-edge-technology in your SharePoint implementation. Yes, I know Silverlight 7.0 sounds cools, but do you really need it? The primary goal of a typical SharePoint project is to increase day-to-day productivity. For that you need reliable tools that are easy to use. Classic mistake No 33. Silver-bullet syndrome Yes, SharePoint is cool and great. But it not a silver bullet. Analyze business problem very carefully and propose the proper solution. As previously mentioned you need a good consultant that can map these problems to SharePoint features that can solve them. Do not promise what you cannot deliver! If you are not 100% secure you can do that with SharePoint ask someone to help you before you promise anything to your customer. Classic mistake No 36. Lack of automated source-code control Developing custom code for SharePoint is usually done in Virtual Machine. Do not forget to backup your code to a physical machine and backup device. VMs are great, but sometimes get corrupted and you might loose everything.   Every project is unique but I hope you will find some valuable advices here.   This blog has moved. Click here to post a comment. Posted Jul 29 2008, 03:15 AM by toni with 8 comment(s) Filed under: classic mistakes, sharepoint project, mcconnell

• The ribbon wars

  When I am advising customers about potential SharePoint to implementation I often hear questions like this one: Q: Toni, we would like to use SharePoint 2007 but we are still using Office 2003, what should we do? If you ask our friends at Microsoft the easy answer is: Upgrade to the latest version now! Bear in mind, that although this is the correct answer will probably encounter many problems along the way. Office is used by end users; they are not IT guys so most of them hate new versions of any program. In many aspects Office 2007 is superior to Office 2003. It uses new formats, it is easy to use, it gives you numerous new features… It also poses a big problem for an end user. The biggest problem is the new interface (ribbons). End user got used to classic menus so they will hate (will not use properly) new interface for months. Here are some advices for companies that are going to implement SharePoint 2007: If you are going to implement SharePoint you should also upgrade your current Office to the latest version. There are some 3rd party solutions that can make your Office 2007 look a like Office 2003. I would strongly advise you against these solutions. Old Office is history and your users will face even more problems with Office 2010 if they do not get use to the new interface. Ribbons are becoming standard part of various office suites like MindManager and others. Ribbons are here to stay  Prepare your end users for the upgrade; invest time in educating and supporting end users. Period after migration will be stressful and hard for them so plan some time for learning and adjustments. In the following posts I will try to explain what are the potential problems is you stick to Office 2003 (or older). Posted Jul 23 2008, 10:24 PM by toni with 3 comment(s) Filed under: upgrading, office 2007, office 2003

• Versioning Hell – Part 2

  In my last post I tried to explain what are the limitations of SharePoint versioning and things you need to know when you are planning and configuring a SharePoint site. In this post I will try to prepare you for the questions you will be asked on SharePoint end-user training. As in last post, the topic is document versioning. Versioning Level 0. - No versioning If you decide to implement SharePoint without versioning support end users will probably ask you why they need to learn a new technology without real benefits. SharePoint without versioning is only a web-based file share.   Versioning Level 1 - Major versions Major versions are good and end-users will love to play with them, but you will be asked the following questions: - Toni, can I control the next version number? - Toni, I do not want other people to see my drafts, what can I do? It is time to move to the level 2.   Versioning Level 2 - Minor-Major versioning When you turn on minor-major versioning your customer will just love you, however be prepared for: - End users do not count versions from 0, this might be a problem - Minor and major version numbering (Major.Minor) is not a clear concept for an end-user. It might be too complex for them to understand, so be patient and prepared for dummy questions - Minor and major versioning is too hard for the end users Questions: - Toni, while I am working in Word I like to save documents every two seconds. I do not want to have 1000 versions of one document. (As you remember for the part 1 you cannot limit the number of minor versions) - Toni, I was just reading my document and someone else managed to change it before me... It is time to go to the level 3.   Versioning Level 3 -  Check-in/Check-out At this level most of your problems is solved and end users are able to do a lot of things new things. What is the problem with this concept then? Well... it is toooooo complicated. In an ideal situation customer is using Word 2007 (Although in Word 2007 check-in/check-out is not so simple.) and SharePoint 2007, but that can only happen in an IT company. If your customer is a large bank or a government agency it might take years before they decide to upgrade to Office 2007. At best they are using Office 2003 and SharePoint 2007 and that is far from ideal combination. Check-in / Check-out is not an easy concept, and when you have to use web browser and Office client to achieve all that, it is complicated.   Conclusion The moral of this story is: Do not underestimate problems you might encounter on a SharePoint implementation. SharePoint project is not just installing SharePoint and developing web parts. The key of successful SharePoint implementation is the adoption of the end users. Plan additional consultant/traniner effort to traing the end users to work with the solution. With good training and detailed and tailored user manuals and the end your users will be able to work with all these features just fine. In part 3 I will describe infrastructure implications of versioning. Posted Jul 14 2008, 11:10 PM by toni with 2 comment(s) Filed under: versioning

• Versioning Hell – Part 1

  This blog has moved. Click here to open the new site. One of the key features of SharePoint is versioning. But if not planned correctly versions can become your nightmare on a SharePoint project.  During project planning phase perform requirements analysis on versions and once implemented educate end-users on how to use versioning correctly. Versioning is a very good feature but Office documents can be huge so it is a good plan to limit the number of versions you want to keep in your document libraries. Lesson 1 – Setting versioning limits This lesson is very important, and, as a SharePoint consultant, you must know this by heart . It will also be useful for the following posts in this series. You can restrict number of versions in following ways: 1)    You can limit the number of major versions 2)    You can limit a number of major version that will have minor versions 3)    You CANNOT limit a number of minor versions to keep for a major version   Lesson 2 – Reaching version limit When you hit your version limit the oldest version will be deleted. If major version limitation is set to 3, the following will happen when you publish version 5.0 Before After  In next post I will try to explain the most common questions you will be asked about versioning by end-users on a SharePoint training. This blog has moved. Click here to post a comment. Posted Jul 08 2008, 08:16 PM by toni with 3 comment(s) Filed under: versioning

• Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software

  Last week I read a great book by Scott Rosenberg (founder of Salon). If you ever worked on a serious software project, you will probably experience a deja-vu (like I did ). The book is a real-life story about a company founded by Mitchell Kapor and a team of developers who tried to develop a new PIM software called Chandler. This book is great material for anyone planing to start a big software project. Posted Jul 06 2008, 10:42 PM by toni with no comments Filed under: books