Wednesday, December 29, 2010

Common pitfalls in SharePoint projects

Proper project planning and process management is essential for successful projects, but after working on SharePoint projects for over 4 years now, I have discovered some common pitfalls, some unique to SharePoint projects while others are general issues that seem to pop up more frequently in SharePoint projects.



The following are some common pitfalls and some tips to help make the project more successful (please note that some of these pitfalls has been mentioned in previous posts, and this posts aims to summarize my findings).




Pitfall #1: You are NOT using SharePoint correctly


One of the first things people must understand about SharePoint is that Microsoft did not create SharePoint as a replacement of their existing offering. Microsoft created SharePoint for fulfill an organizational need, and they were clever enough to create in is such a manner that it complements (NOT replaces) there other offerings.


Lets look at an example and focus on Intranets, before SharePoint, we had two extremes when providing a business user with an application or web space to achieve their business goals.

On one side we have business users requesting an application from the IT department, resources were eventually allocation and the SDLC begins, a solution is provided about a month or so later. This application had its own database, little to no integration with other systems, its own security component, meaning another set of usernames and passwords the business users need to remember, and its own unique look and feel.


On the other side, the business user will create an application themselves via Excel or Microsoft Access. The solution will be available quickly but the solution will be stored on business users workstation. The IT department may have no knowledge of this application, and even if they did, they will have a limited skill set in maintaining the solution. This application will not be backed up and will only be accessible when the business user’s machine is on.


SharePoint provides an environment that is governed and maintained by the IT department but also provides the Business User with enough control and flexibility to create and configure an assigned area of the portal to handle their business needs without the need of the IT Department allocating a developer to this task.


Using SharePoint as a workaround solution that is expected to “replace” another offering from Microsoft (for example Biz-talk or even ASP.NET), or adding too much customization so the SharePoint solution stops functioning like a SharePoint solution would mean that you are not using SharePoint correctly


Pitfall #2: Too much customization


This is really an extension of pitfall #1, but it happens so frequently, that it deserves its own point. If you need a magic number to help guide you, use 20% (it’s a number I made up, but so far, it has not disappointed me). If more than 20% of the solution is custom developed you are not using SharePoint correctly.


Also, avoid strong look and feel, rather use the correct template (based on the purpose of the site) , style it via themes only and configure to fit the business need


What people fail to understand is that the more the solution is customized the more expensive the solution; this is the cost in development and the cost in maintenance.


SharePoint provides a platform of templates and tools that assist the business users in creating solutions without the need of a developer, with custom components, you need developers to provide the solution and then maintain the solution, meaning that you are not using SharePoint correctly.


Pitfall #3: Using the wrong skills for the job


This is a common problem, mainly due to the shortage of SharePoint skills. SharePoint projects are different when compared to custom development, meaning that these projects demand a unique set of skills, and due to shifts in project demands, companies find it cost effective to convert their custom developers to SharePoint developers, this transition is not easy and is explained in detail in my previous post.


Unlike custom solutions, SharePoint projects is mainly about planning and configuration, and you would require a set of skills to focus on that rather than development. There are other skills such as defining, understanding and documenting the client’s objectives, which is frequently overlooked, especially in SharePoint projects, since the clients understanding of SharePoint is usually misunderstood and their expectations needs to be closely managed.


Pitfall #4: Clients expectations is poorly managed


SharePoint is very flexible, and has been sold as a solution that can do it all, this is an unrealistic expectation when it comes to delivery, so it’s very important to manage client’s expectations right from the start.


It needs to be understood that sometimes SharePoint is not the answer and SharePoint is about empowering the business users, this needs to be determined and understood at the early stages of the project and clients expectations needs to be well managed at this point, especially since the clients may want to use SharePoint because they happen to have the license and everyone else is using it (and if that’s the reason why you are using SharePoint, then you are using SharePoint for the wrong reasons).


Also, client’s needs to understand that they will not get what they want with a simple installation of SharePoint, SharePoint provides a platform for the solution – and that needs to be configured, and the client needs to be aware of this.


Pitfall #5: Don’t do too much too quickly


SharePoint can do a lot, but if you try to do too much, you will end up with nothing


Work on a SharePoint roadmap that spans over a few years. Identify key milestones and use a phased approach when delivering them. Be aware that, as you complete and review milestones, your objectives will change and the project and roadmap will need to adjust to accommodate the change.


Pitfall #6: Garbage in = garbage out


One of the strong selling point of SharePoint is the Search feature, but in order for the search feature to work correctly, content must be accurate, relevant and current. This involves good use to categories, metadata and taxonomy, and this is achieved through proper planning


Pitfall #7: Don’t forget capacity planning


When deploying a solution, you have a responsibility to provide an environment that can handle the current needs, as well as the predicted future needs.


Capacity planning is challenging in SharePoint as there are no hard limits, only guidelines. But capacity planning tools has been provided by Microsoft to assist you. Use these tools, but be aware that these tools tend to over compensate on the hardware requirements, so use this tool as a guide.


Pitfall #8: Don’t skip the governance plan


This step is often skipped, mainly because clients don’t understand the benefits of it, and see it as the easiest way to reduce the budget.


If you are planning to deploy a solution that will be used by many people, it is good to control the environment with a set of rules, these rules must be easily accessible to all users and it helps promote fairness and it helps control the environment rom growing too big too quickly.


Governance plan needs to include the support and maintenance of the server and network, the SharePoint technologies and even the portal as a whole.


A Governance plan defines if control of certain operations is with the IT department or the business users, it defines policies, standards, approval processes, it gets all relevant stakeholders involved and set rules to maintain a high quality output.


Pitfall #9: Scope creeps, risks and other general IT Project pitfalls.


SharePoint projects may have their own unique set of pitfalls, but they are not shielded from general IT pitfalls such as scope creeps and risk. A skilled project manager is essential for project success.


Plan for a development, QA and test environment – follow a process involving reviews and testing when coping updates to the environments, this will help control risk, can assist with training and keeps the live environment stable


Pitfall #10: Focus on strong user adoption


The SharePoint deployment project is regarded as successful if it receives strong user adoption. So providing proper training and support is compulsory. Spending some time on change management, where the new portal is advertised and there is some excitement created around the change is now seen as an essential step.


The SharePoint solution needs to resolve current problem areas, when launching SharePoint, make sure you shut down alternative sites that achieve similar objectives, otherwise people who are set in there old ways will never move to SharePoint.


Pitfall #11: Remember to measure the ROI


People decide to measure the return on investment after the SharePoint solution is deployed, at that point it’s too late because you don’t have enough data before the SharePoint deployment for a proper analysis. So gather feedback from end users before and after deployment to determine if you have received a positive ROI or increased productivity. Missing this step makes it difficult for the project owner to secure funding for future phases.



Pitfall #12: Dont speed through the planning phase


For the search feature to work well, content needs to be correctly classified.  For business rules and policies to be implemented and executed correctly, your content types and workflows configuration settings needs to be designed and configured correctly.  This involves alot of analysis before any "SharePoint" work is done, you need to do a "as-is" analysis, determine the "to-be", and work out how (or "if") SharePoint  can fill the "gap".  

If you are spending less than 20% of the entire project time on planning, you probably dont have a clear plan when configuration, meaning that you are relying on a "trial and error" approach when developing, which is going to cost you more money in the development phase and the support phase.

Pitfall #13: Migration will be quick quick (yeah right!).


If your site deployment involves content migration, treat it as a seperate project, because that alone is a big and difficult requirement, and is essential for project success.

The cleaning up of the content so the new site contains information that is current, accurate and relevant will on its own be a very time consuming process, now add to that the correct classification of the information, applying the correct meta-data, properties, content types.   This is not a 1 week job so stop thinking it is when you are drawing up a project plan.

Sure, you can copy and paste all the content from the old site to the new,  but then you will end up with the "Garbage in = Garbage out" problem (see pitfall #6), and the truth is, if you are not classifying you content correctly, you are not using SharePoint correctly (pitfall #1).








Saturday, November 20, 2010

Outsourcing, how to make it work


I have been studying project management in the last few months; the course is very interesting but works on the assumption that you are a project manager working on projects for your organisation. In my case, that is not true. I work for a consultant (outsourcing) company, meaning that the “projects” I work on is really for the benefit of my client’s organisation and this small distinction makes a big difference in how the project manager handles the project.


Firstly, let’s look at the purpose of a project. For an organisation to finally decide to invest into a project the organisation must see that the success in the project will lead to the success of the organisation; the project also needs to fit strategically within the organisation, the following considerations needs to take place:
  • Does the project fit with the organisation’s technology architecture?
  • Does the project follow corporate standards, policies and methods?
  • Can the project last with the organisation’s business and IT strategic plan?
  • Can the project co-exist with existing systems?
All of these questions are answered in a document, usually called the business case document, and is compiled by the Project Owner, who is most probably a permanent staff of the organisation. After approval is received and a project sponsor is defined, it may be decided to outsource this project to a consultant company that specialise in the type of delivery the project requires, nothing wrong with that, in fact there are many advantages to this approach, some of the key advantages are:
  • Reducing costs - labour is usually cheaper via outsourcing, also its cheaper, quicker and easier to find the right consultant company that to hire (and then manage) a resource with the correct skills
  • Improved business focus – with a portion of the work outsourced, the organisation’s permanent staff can focus on the organisations core competencies
  • Access to unique skills – The shortage of IT skills makes it difficult for the organisation to find the required skills directly. Outsourcing makes these skills more easily accessible
  • Experience - By outsourcing, the organisation is not only gaining a skillset, but experience, this helps identify risk that the organisation may not be aware of and can greatly contribute to the success of the project

    Unlike the popular series called “Outsourced”, you may also require the outsourced company to provide a project manager. Again, nothing wrong with that approach, in fact, a project manager from the consultancy company …
    • Has great experience on similar type projects
    • Has a tried and tested approach for your project
    • Knows the common high risk areas and has a strategy in mitigating it
    • Knows the type of stakeholder involvement required for project success
    • Is familiar with the outsourced team and knows how to manage them
    • Can provide more accurate estimates (cost and time)
    But the project manager works for the outsourced company, and while there is an expectation for the Project Manager to make decisions that for the benefit of the organisation as a whole, this type of expectation is not expected from an outsourced project manager (since there can be a conflict of interest when the Project Manager can make decisions that will benefit the consultancy company). For example, Project Managers will NOT …
    • Identify kill points (points in the early part of a project, where it needs to be decided if the project should continue)
    • Focus on the return of investment. The outsourced project manager will define the requirements of the project and produce a solution that matches the requirements. The return in investment will be the responsibility of the Project Owner, not the project manager
    Also, since the project manager is not part of the organisation, the project managers will not know the …
    • Organisation’s “Big Picture” strategy
    • Organisational structure, and thus will not know who are the key stakeholders needed for project success
    • Organisation’s standards and procedures
    • Existing systems and technology infrastructure
    So how do we create an environment where the organisation can gain the advantages of having an outsourced set of resources, included with that, the advantage of having the outsourced Project Manager, but without the disadvantages? 


    There are really 2 approaches. 

    Organisation provides a project manager that works closely with the outsourced project manager. This approach is great for short term projects. This resource needs to understand the organisations “big picture” strategy, standards, procedures, etc. He also requires sufficient authority in making quick decisions, and by working closely with the outsourced project manager, he will ensure that decisions are made for the benefit the organisation. 

    This is great if an organisation can place a dedicated resource to this project, but may not work for long term projects. For long term projects, it would be better to establish a strong relationship between the organisation and the outsourced company. 

    If an organisation forms a 5 year contract (involving many resources) with an outsourced company, that’s a 5 year commitment, the project is no longer seen as a short term project that will benefit the client’s organisation. It is now a long term project that will require significant investing from the outsource company and ultimately benefits the outsourced company as a whole. 

    With this level of commitment, the outsourced company will understand the organisational structure, organisation objectives, standards and procedures, etc. a lot better, that will assist in delivering successful projects. 

    Also, as part of the 5 year commitment, organisation should place the more senior outsourced resources in decision making position within the organisation. The outsourced company now has responsibility and authority for a particular organisational business requirement. With this power, comes responsibility, so ROI and kill points are now considered more carefully and impartially. 

    This type of commitment helps the outsourced company grow, with the steady income flow provided by this contract, the outsourced company can focus on training resources, improving processes and providing a better service. This really is a win-win situation that is rarely practiced because of …
    • Loss of control – outsourcing to this level is seen as giving the management and control of a business functional to another company
    • Hidden Costs – requirements not defined in the original agreement are subject to change control with can lead to additional costs
    • Quality problems – contracts with fixed prices, places a large amount of risk of the outsource company which may force them to reduce their expenses to maintain a profit
    • Dependant on stability of outsourced company – if the outsource company goes under, the organisation is left with a huge problem
    This is where the strong relationship between organisation and outsourced company is essential, Also look at the costing structure. A fixed price places all the risk on the outsourced company, while the time and material approach places the risk on the organisation. A well balanced costing contract is the CPIF (Cost-plus-incentive fee) contract, where the price paid changes in relation to costs (http://en.wikipedia.org/wiki/Cost-plus-incentive_fee). This type of contract with the strong relationship will resolve most of the concerns mentioned above and truly enforce that win-win situation.

    Sunday, October 10, 2010

    Demonstrations with VHD files

    My current role involves more than just department and project management. it also involves pre-sales demonstrations.


    Prepping for a demonstration is very time consuming and very difficuly, especially since its not my primary job function. Over time, I managed to define an approach that produces great demonstrations with minimal prep time. I am going to share this approach with you.

    This approach is constantly improving and I value any feedback and recommendations you may have that can help me improve this approach.




    1. Do not re-invent the wheel.

    As a Microsoft Gold Partner, focused on SharePoint and ASP.NET solutions.  My demonstrations are focused on showing off Microsoft products. If my pre-sale demonstration leads to a sale, my Company and Microsoft wins. Microsoft is aware of this and they want my demonstrations to Rock! If fact, it’s in there best interest to build detailed demonstrations for me, and that’s exactly what they did.

    Go to the following site, http://mssalesdemos.com/, log in with your Microsoft Partner account (Usually your Windows Live ID), and you will have access to a great selection of demonstration solutions that you can download and use. If you can not find your desired demonstration there, don’t worry, contact Microsoft directly, or visit your local Microsoft office with a hard drive and copy your desired demo directly. Its well worth the effort (and bandwidth). You can spend days creating your demo from scratch, and it wont be as good as these.

    2. Understand the VHD file.

    The demonstration solution provided by Microsoft is very big, the full download would be about 40 – 70 gigs, so make sure you have enough space.

    You will notice that most (if not all) of the space is taken up by the Virtual Hard Disk (VHD) file. This file contains content that is found on a physical Hard Disk Drive, content like like files, folders, file systems and disk partitions.

    VHD files are created for virtual machines like Microsoft Virtual PC. This file contains its own Operating System, with all the necessary software, configurations and data needed for the demonstrations. VHD files are created to run off Windows Server 2008 via Hyper-V (a virtualisation system), but since we are planning to demonstrate this solution via our laptops that’s (most likely) running Windows 7, we have to run the VHD file without Hyper-V.

    3. Prepare the laptop for VHD demonstration.

    Chances are, your laptop is not as powerful as the server the demonstration solution was expecting. So running a normal Windows 7 operating system and then assigning half your memory and other resources to the virtual solution will most likely give you a frustratingly slow environment which is not demo friendly, instead, what you want to do is give all the laptop resources to the virtual solution, and the only way you can do that is if you boot directly from the VHD file.

    The ability of a physical computer to mount and boot from an operating system contained within a VHD is called “Native VHD Boot” and is supported by Windows 7 Enterprise and Ultimate, so make sure you have the right OS installed.

    Also, your laptops virtualisation feature must be turned on, this feature is off by default. You will need to enter the bios and turn that on, if you can’t find that setting in your bios, chances are, your laptop may not support it, meaning that you will not be able to load VHD files and its time to start motivating for an upgrade.

    A high end laptop is the obvious requirement when you are trying to run a server environment on your laptop, but if you can only focus on one thing. Let it be RAM.

    These demo’s run multiple SQL servers, its own active directory and many other systems that, in real practice, should be installed on multiple servers, your demo may even show off the capabilities of handling millions of rows of data and producing results from complex queries and calculations, all this requires a memory, and lots of it. My recommendation is 8gigs of RAM at the very least.

    Regardless the physical size of the VHD file, if the virtual size of the VHD partition is 200 gigs, you will need 200 gigs of free space for the Native VHD boot to be successful. So make sure your VHD file is copied on a hard disk with enough free space.

    I understand that this is a difficult requirement, and also unnecessary, especially since the demonstration may only need about 70 gigs but you are forces to allocate about 200 gigs, so follow these steps to reduce the virtual size of our partition.

    1. Load your Computer Management Console (run compmgmt.msc), Right Click on “Disk Management” and select “Attach VHD”, browse and select the VHD file.

    2. The new disk with a new drive letter will be loaded, right click on the main volume and select “Shrink Volume”.

    3. Select a new reduces size, allow for about 5 gigs above the minimal allowed size and ensure you have enough hard disk space for this new virtual size. Click “Shrink”


    4. You will now have a reduced disk partition, while the rest of the disk contains unallocated space. All we need to do now is delete the unallocated space.


    5. Detach the VHD file and load the VHD Resizer tool to remove the unallocated partition space (it’s a free tool available here : http://www.brothersoft.com/publisher/xcarab-inc.html).

    4. Setup the VHD for Native Boot.

    You now need to configure your laptop, so you have the option to boot from the VHD when your computer starts.

    1. Attach the VHD via Disk Manager as defined above. Note the dive letter assigned to the partition.


    2. Run “Command Prompt” as an administrator (this will not work if you do not run as administrator)


    3. run the following command “bcdboot g:\windows” where “g” represents the drive letter of the attached VHD file.


    4. That’s it, to confirm that all is configured correctly, run “msconfig” and select the boot tab. Details of the VHD boot settings should be shown here, you can also use this screen to delete the boot setting or change the default boot.

    You should now restart your laptop and select the VHD option during the dual boot option screen. You may get a blue screen, with some details on what went wrong, hopefully it can be resolved, but if all goes well you will have the virtual Hard Disk running on your laptop, using all the resources available from the laptop.

    5. Preparing for the demo

    Unfortunatly, getting the VHD to run on your laptop does not mean you are done.   You need to make sure that your virtual environment is demo ready and that YOU are prepared to give a great demo.

    For your virtual environment to be ready you need to ensure that all the drivers needed for the demo is installed correctly, especially the USB driver and the Display Card driver.

    With the USB driver, you may attach your mouse and modem which may be useful for the demonstration. The Display Card driver may be more critical, especially if you are planning to demonstrate via a projector, which may not be possible if the drivers are not updated.

    To quickly update your drivers, follow these steps:

    1. Your original Windows 7 drive is accessible via the virtual environment, look for that drive via “file explorer” and note the drive letter,

    2. Go to the Device Manager screen, select the device thats needs to work correctly, right click and select “Update Driver Software” and then select “Browse my computer for driver software”, select the following path “H:\Windows\System32” where H is the drive letter of the disk with your Windows 7 OS. The correct driver should install automatically and the selected device should work.

    To prepare yourself for the demonstration, you need a good script and time to practice. Microsoft made it easy by providing a Presenter Script with the VHD download file that’s gives you a scenario that highlights all the features you are demonstrating.

    Learn the script. If your demonstration is estimated to take 1 hour, you will need about 6-10 hours in learning the script and understanding how each feature is configured and how the desired results are achieved, this knowledge will come in handy during the Q and A session of your demonstration.

    These VHD demonstrations have a trial version OS, set to expire in a few weeks.  Once the OS expires, functionality is limited and your demo is ruined.  Thankfully, there is a way to extend the expiry date:

    1. While in the virtual environment, click start and then Command Prompt.
    2. type "slmgr.vbs -dli" to view the status of the evaluation period
    3. type "slmgr.vbs -rearm" to reset the evaluation period
    4. you wil need to restart the PC

    And thats it.  Just one more note worth mentioning, the demonstration environment may take about 10 minutes just to boot up, and there is no sleep function available on Windows 2008 OS's, so start your PC and cache up the environment before the presentation starts and good luck.

    Saturday, September 18, 2010

    The “All in One” SharePoint Guru does not exist – so stop looking and focus on plan B (Part 3 of 3)

    This article is a continuation of Part 2 - Please read that article first.



    Phase 3: Development
     
    In the development phase, the solution is built according to the specifications defined by the architect (As defined in Part 2). 

     The development phase requires 2 key players, the SharePoint Administrator and the SharePoint Developer.  Yes - this is two different roles with two different skill sets. 

    You may want to add SharePoint data-capturer to the list so basic tasks like deploying a taxonomy and site population can be completed by a cheaper resource, allowing the higher skilled resources to spend time on more complex requirements.

    The SharePoint Administrator

    The SharePoint Administrator focus is on the setting up, configuration and management of services running on SharePoint.  Anything available "out of the box" from SharePoint can be deployed by the SharePoint Administrator, which should be at least 80% of the entire solution.  (If anything less than 80% of the requirements is "out of the box" - chances are, SharePoint was not the right solution, and you may be creating a maintenance nightmare).

    The SharePoint Administrator is skilled to action the following:

    • Create new sites and lists
    • Install and configure web parts
    • Create BDC connections
    • Manage the SSP (Configuring Audiences for example)
    • Creating InfoPath forms
    • Creating and management of governance policies and permission groups
    • Management of the Central Administration
    • Use of the SharePoint Command line tool (STSadm)
    • Good understanding of IIS and Active Directory
    • Create and manage standard workflows
    • Configure and manage the backup strategy
    • Restore deleted content from Recycle Bin
    • Configure site usage statistics reports
    • Configure Search (including managing Best Bets)
    • Configure Security
    • Configure Navigation

    To the SP Administrator, its all about providing what SharePoint can do OOTB (out of the box).  The SharePoint administrator must provide what is required via configuration made in the Central Administration, Shared Service Provider, Site Collection or in a specific sub site.  In some cases, SharePoint designer is used for more advanced configuration and reporting, but this tool is usually reserved for the SharePoint Developers.

    The SharePoint Developer

    The SharePoint Developer is the resource that is used to complete the other 20% of the project.   The SP Developer is focused on custom development and has strong knowledge on how to use the SharePoint API.  There delivery is usually focused around the following

    • Custom Web Parts
    • Complex workflows
    • Event Handlers and Receivers
    • Custom coding SQL
    • XML/XSLT Development

    The SharePoint developer is skilled in IIS, .NET 2/3, SQL Querying, windows workflow foundation, C#/VB and how to apply these skills to the SharePoint API. 

    Strong HTML/CSS/JavaScript skills is required when applying a brand.  Understanding how SharePoint applies a theme is needed so it can be manipulated and also knowledge on changing the master page and site definition page is extremely valuable.

    Skills in ASP.NET infrastructure is needed as a SharePoint Developer is required to edit web.config files and work with code-behind pages.

    To the SharePoint Developer, its about providing what the user requires that cannot be provided OOTB, but providing a solution that uses as much of SharePoint as possible.  The tool available is SharePoint Designer and Visual Studio.  Strong SharePoint Developers usually started off there career as ASP.NET Developers.

    Phase 4 and 5 : Stabilisation and Close

    After the solution is built, it is tested and corrected.  Training manuals are created and administrators are trained.  Acceptance documents are signed, and the solution is launched.  The site is supported and the project is concluded.

    At these phases a SharePoint project requires the same resources needed in any other type of IT project.  These phases are managed and controlled by the Project Manager.  Resources used in the previous phases, i.e. Business Analyst and Architect can be used to QA the solution to ensure the business requirements are met, the SP administrators and developers can be used to correct the solution, and the business will do the final testing and sign off.  A SharePoint Trainer may be added to the resource set to focus on providing training material and holding training session to train the administrators.

    At this point the support team are educated on how to maintain the current solution and the next phase is envisioned and then we are back to [Part 1] of this article.

    Conclusion

    Every IT project is split into phases, and each phase has a specific purpose, with a specific set of skills.  Why are we not applying this structure to SharePoint deployment?  In short, the following resources are the minimum requirements:

    • Envision
      • Project Manager
      • Business Analyst
    • Planning
      • Project Manager
      • SharePoint Architect  
    • Development
      • Project Manager
      • SharePoint Administrator
      • SharePoint Developer
    • Stabilising
      • Project Manager
      • Business Analyst
      • SharePoint Architect
      • SharePoint Administrator
      • SharePoint Developer
      • SharePoint Trainer
    • Close
      • Project Manager
    Anything less is expecting too much from your existing resources which will affect the quality and prolong the date of delivery.



    Saturday, September 04, 2010

    The “All in One” SharePoint Guru does not exist – so stop looking and focus on plan B (Part 2 of 3)

    This article is a continuation of Part 1 - Please read that article first. 



    Phase 2: Planning

    After the Envision Phase is completed, the Planning Phase starts, that requires a different set of skills.

    If the Envision Phase is all about "What the Organisation wants", then the Planning Phase is about  "How are we going to give them what they want".

    Successful projects (SharePoint or otherwise) places a lot of time into planning, on average, 20% of your entire project should be placed in the planning phase, if you get that right, the future phases is just about applying the plan.
    The experts needed for this phase are as follows:
    • Project Manager
    • Business Analyst
    • SharePoint Architect
    • Infrastructure/network administrator
    • Database administrator
    • SharePoint Designer
    • Steering Committee
    From the last phase, the Business Analyst would have defined the scope and document what the organisation wants.  

    In this phase, the SharePoint Architect is the key player.  The SharePoint Architect has a strong technical understanding of SharePoint and a strong understanding on how the business operate and what is required to meet the business needs. He/She understands how SharePoint can satisfy the user requirements, what configuration options are available and with that knowledge, define an approach.

    With the assistance of the infrastructure/network administrator, database administrator, SharePoint Designer and a few other experts, the SP Architect will review the requirements and will define a detailed approach on how its going to get done.  The following analysis will take place:

    • Define what existing infrastructure is available (i.e. Mail Server; Database Server)
    • Define what infrastructure is required is meet the expected capacity (i.e. Traffic; hard disk space)
    • Define quota’s, storage limits and file restrictions to control capacity
    • Define approach for connecting via internet (if required)
    • Design Site Topology needed to meet user requirements (i.e. # of SSP’s, Site Collections, Sub Sites required and the structure)
    • Design Content and Navigation Structure
    • Define branding requirements (need the assistance of a SharePoint Designer)
    • Define the purpose of each site component in the topology and define what features are required
      • Define what Data Topology is needed
      • Define custom development requirements
      • Define Content Type requirements
      • Define Page Layout
      • Define Brand and Brand Consistency
      • Define Audience requirements
      • Define Security configurations (Who needs what access to what)
      • Define data view requirements
    • Define what Search configuration is required
      • What iFilters needs to be installed
      • What content needs to be indexed
      • Define Search Scopes
    • Define Development and Test environment
    • Plan for Change Management
      • Awareness campaign
      • Demonstrations
      • Training approach
    • Define Governance Plan
    • Define integration approach (BDC, Excel Services, may need to communicate with Product Expert for integration options)
    • Define Migration Approach
    • Define Maintenance Plan
    That’s a lot of information, once the SharePoint Architect has defined the approach, documented it and received acceptance from the stakeholders the Development Phase starts.

     Phase 3: Development

    Article continues here

    Sunday, August 22, 2010

    The “All in One” SharePoint Guru does not exist – so stop looking and focus on plan B (Part 1 of 3)

    I published my “Shortage of SharePoint skills” blog post on numerous sites, many readers were in agreement with the points made in the article but the comments surrounding the blog post indicate that the shortage exists because companies are looking for ONE person to handle the entire SharePoint delivery.




    I have a few theories why this is happening. Bottom line, the business does not know what SharePoint is; they see it as a product similar to Word and Excel, so they get there IT administrator to install this product, and expect everyone to use it.

    Unfortunately, it’s not that simple. Unlike Word and Excel, SharePoint is a platform, not really a product, and this platform is very flexible. It’s designed that way so it can be adjusted to fit within your organisation, be it a small business or a multinational company.

    SharePoint also offers a lot. It’s described as a collaboration platform, but this platform offers Content Management, Intranet Portals, Business Intelligence, Workflow Automation, Records Management just to name a few. This high volume offering makes SharePoint a rather complex platform.

    To add to the complexity, SharePoint is a platform designed to empower the business users to update their website and add features and functionality to satisfy their business need (in a well controlled and governed environment). This was a role previously fulfilled by the IT department, so a successful deployment would ultimately mean a shift in control and a process changes which can be a challenge to implement in large organisations.

    This level of flexibility and complexity means that a lot of information, planning and input from many different types of experts (technology and business related) is needed for a successful SharePoint deployment.

    I have been working with SharePoint projects since 2007, from then till now I have defined a list of essential skill sets needed for a successful SharePoint deployment. This is my findings (grouped by typical phases you would find in a SDLC).

    Phase 1: Envision

    In this phase, you need to determine what the business wants. A Project Manager and a SharePoint Business Analyst is needed to hold meetings with Stakeholders and define the requirements.

    Lets focus on the SharePoint Business Analyst, the BA is expected to have a good understanding on what SharePoint is all about, this means a strong SharePoint overview (not necessary technical) skill set. The BA will need to know what SharePoint can offer and how it is offered. With that knowledge, the BA can determine the following...

    • Is SharePoint the right solution for the business requirements? The truth is, it may not be, rather figure that out now, before investing more money.
    • Can SharePoint provide the features requested “out of the box”? Must custom development satisfy the business requirements or can an alternative “out of the box” solution be provided.
    • What is the business expecting? Are these expectations unrealistic or not in line with SharePoint’s offering? Assist in managing the expectation.
    • Determine a phased approach, as mentioned before, SharePoint offers a lot, determine the immediate success factors and focus on that
    • Determine “who will need what access to what”. For all the business requirements requested, determine the owners of that feature, the administrator, the approver, the contributor and also the viewer
    • Compile a Governance Plan to determine rules, standards, processes and what SharePoint features should be made available
    • Determine how the business would like their content structured
    • Determine how the business would like to search for content (taxonomy)
    • Gather information that affects capacity planning such as expected number of concurrent users or expected amount of content that requires indexing.
    • Determine what SharePoint License is required. Can SharePoint provide all features requested via the Standard License or is the Enterprise License required?
    The Project Manager need not have a strong skill set of the SharePoint offering, but having it will be advantageous. His focus will be on the management component of the project which is not the focus of this article.

    I do want to add that the PM needs to initiate the forming of a Steering Committee, that will provide direction to the SharePoint Solution as well as support to the governance plan

    For the BA to gather the information mentioned above, he will have to engage the following people:


    • Project Sponsor - to determine his requirements and objectives
    • Business IT Manager – to determine hardware and software availability, details on existing systems that may require SharePoint integration (or SharePoint is replacing) and other IT specific or technical information
    • All Business Unit Managers – to define their unique business requirements (it is recommended to meet them via a phased approach if the organisation is large)
    • The Steering Committee – for proper decision making and governance support

    Phase 2: Planning

    Article continues here

    Sunday, August 01, 2010

    Why there is a shortage of SharePoint experts



    Microsoft has been very successful to promoting their SharePoint product, even though SharePoint has been around for a while, there 2007 and now 2010 version is something every organisation wants.


    With Microsoft practically giving away SharePoint licenses to organisations via EA agreements – we are reaching a very unique and rather unexpected situation where the demand for SharePoint developers is surpassing the demand for Web developers.

    This shift in demand are forcing IT departments and Web Development companies to reduce the size of the web development teams and increase the size of their SharePoint team, in other words, take staff originally hired for web development and get them into SharePoint development.

    This is currently the "normal" approach in getting SharePoint experts, many IT Recruitment companies still don’t understand this shift in demand, and are not yet focusing in the SharePoint space, some recruiting companies haven’t even heard of SharePoint and see it as a specialist skill.

    Restructuring organisations to handle the shift in demand is a change that will naturally lead to resistance and conflict. To the managers and other decision makers, this change seem minor, especially when “converting” ASP.NET developers, since SharePoint is built on ASP.NET, and it is assumed that the same skill set and approach is needed with minimum training on the SharePoint basics. That is not the case.

    An ASP.NET web developer became a web developer by studying and gaining experience in the following...


    • HTML
    • CSS
    • DHTML
    • JavaScript
    • JQuery
    • ASP.NET (C#, VB, etc)
    • SQL
    • AJAX

    They also use a range of products created especially for ASP.NET web development, mainly...


    • Visual Studio
    • SQL Server Management Studio
    • Some code repository like SVN or Team Foundation Server
    That’s the tools they have in their tool belts, over time, they become experts by continuously applying this skill set and learning the best approach in using them when completing tasks.

    For SharePoint, the approach is different, very different. All the HTML, CSS, JavaScript and so on is provided by the SharePoint product, SharePoint experts are not suppose to touch that space, deploying SharePoint solutions is more focused on planning, installing and configuring, with less emphases on developing.

    If development is required, it’s because SharePoint cannot satisfy the organisations unique requirements “out of the box”, and something “custom” needs to be built. Custom development in SharePoint is regarded as the last resort, while an ASP.NET developer sees this as the first option, placing them in a situation they are not comfortable with right from the start.

    Since a SharePoint solution is different from standard ASP.NET web applications, tools like Visual Studio and standard code repository tools have their limitations and the Web Developers are forced to use another tool, mainly SharePoint Designer, which is another learning curve hurdle that can limit adoption.

    If the bulk of the SharePoint project is focused on planning and configuration, then the skills that the developers were perfecting as an ASP.NET developer no longer drives the success of the entire solution, but rather the success of a small component (if any custom development was required).

    The SharePoint developers are also faced with a challenge that they never experienced as an ASP.NET developer, there are restrictions when developing and providing a look.

    An ASP.Net Developer is used to having full control over every component of the web application, from its functionality to its look. SharePoint is a product with a large amount of functionality built in, and developers need to configure the required functionality and make it available to the end user.

    They need to move away from creating a SQL database, the foundation of their solution, and move towards using the existing SharePoint database via SharePoint lists.

    Look and feel is template based; adjusting the default look usually creates an environment that SharePoint is not expecting that can lead to drop in functionality (Read my Post for more details).

    SharePoint may add these restrictions and limit what the developers can do but the end users are unaware of these restrictions and expect all their unique requirements to be for filled. It’s not the end users fault, there requests don’t seem unreasonable, it’s just that SharePoint was not built to work that way, the following are example of “simple” requests that cannot be done via SharePoint without something custom being done:

    • “I would like my site to have 3 navigation menus” – SharePoint manages a Global Menu (Site Collection Specific) and a Current Menu (Sub Site Specific) only, that’s 2 menus.

    • “I would like my menu to hover down to 3 levels” – SharePoint Global Menu hovers to 2 levels only, SharePoint Menu Configuration screens do not allow the levels to be modified.

    • “I want to use an AJAX/Silverlight menu” – It is not recommended in SharePoint 2007, this is explained in detail in my previous post.

    • “I want the same menu across my entire site, all managed in one place“– Global Menu is Site Collection dependant while the current menu is sub site dependant, a different site collection or subsite means a different menu, managed in a different place.

    I limited my examples to SharePoint navigation menus only, just to show you how one component can give a developer a big challenge from “simple” requests that would have been a lot easier to complete if the SharePoint was not used.

    So what does this tell you? Demand shifts are forcing managers to turn web developers to SharePoint developers. This is not what web developers signed up for, the approach for these projects is very different, and in many ways restrictive and frustrating, so they don’t do it, leading to the shortage in SharePoint skills.

    How do we solve this problem? Stop looking at converting Web Developers, when seeking SharePoint Developers, unless the developer shows a strong interest in SharePoint, you will have a lot of resistance in this change, rather get the ASP.NET developer trained in custom development for SharePoint only, the skills required for that are the skills web developers are already comfortable with, and focus on getting different set of people for SharePoint installation planning and configuration.

    Another approach is to understand the purpose and restrictions of SharePoint and communicate that to the end user so there expectations are well managed; unrealistic expectation places unnecessary pressure on the developers which leads to frustration and will draw them away from SharePoint development.

    Sunday, July 25, 2010

    Training Users after deploying SharePoint 2007/2010

    When deploying a SharePoint solution, the business often place most of their budget and allocated time to SharePoint Features, configuration and that strong look and feel and forget about end user training.


    They understand that the assigned administrators require training to help manage and update the features available, and that type of training is usually included in the project planning – but they forget that the general, every day users may also require training, and they usually try to throw in a quick fix just before launch.

    I planned to talk about the “SharePoint Learning Kit”, available from CodePlex, it’s a SharePoint e-learning site with tracking created by Microsoft that you install in your existing SharePoint farm, but there were a few things I didn’t like about this solution, mainly:

    It’s not open source, meaning that I cannot edit this solution

    Its uses a separate database, so I don’t see it as a true sharepoint sub-site anyways, and installation was difficult.

    It was buggy, I have experienced some errors with this kit, and since the solution is not open source, it was difficult to fix.

    Difficult to customise, the site has a strong Microsoft brand, its limits us in branding it for client's and since strong, consistent look is very important to clients, deploying a solution that cannot fit with the rest of the site seems very unprofessional.

    But now I discovered the "Microsoft Productivity Hub", available for SharePoint 2007 and now SharePoint 2010, it is more community based and it is built to resolve all the problems I mentioned above.

    The following blog post covers the Productivity Hub beautifully, thank you Muneer Natha for bringing this to my attention.

    Saturday, July 24, 2010

    Minimum requirements for a good on site working environment

    In the past, when a software solution needs to be developed, my team build the solution in the office, tested it in the office and only when everything is built and ready, we would go to the clients offices to install and configure the final solution.



    These days, it’s more common to deploy the entire team onsite (clients’ offices) right from the start of the project, and while on site they do all the development, testing and configuring directly on the clients servers.


    This results in easy accessibility of the team, better focus, commitment and dedication from the team which ultimately means faster more accurate delivery of the solution.


    But the team is moving away from an environment they are comfortable with to the clients’ environment which may not be designed for this purpose, and if a few basic requirements are not in place, delivery of the solution is compromised.


    So if you are looking at getting an outsourced team to work in your office to deliver a solution, make sure these minimum requirements are in place.


    Free, safe and close by parking – Not providing this is de-motivating to the team – so if it can be provided, do it; it makes it easier for the team to work late at night if needed.


    Access Cards/Tags – If security is controlled by access cards or tags provide the team with the necessary, staff without access cards usually have to go through additional security checks which is time consuming, it also restricts move ability in and out of the building.


    Proper Desk and Comfortable Chair – They going to be working there for the majority of the day, don’t give them that broken down desk lying in the store room – give them a comfortable environment, a chair with a high back and wheels if possible – you will see the results in the delivery.


    Network access – Access to the network allows the team to build a solution that will work on your network – it’s one of the reasons why they are on site in the first place.


    Internet Access – This is important for delivery, developing software solutions involve frequent access to the internet for trouble shooting and software updates – it also allows the team to communicate with subject matter experts and gain access to knowledge based content.


    Email Access – An email account provided by the business, makes it easy for the team to communicate with the organisation and vice versa, it’s a frequently used communication channel that needs to be in place right at the start of the project.


    Telephone Access – another communication channel that can speed up delivery.


    Shared Folder Access - I should be saying SharePoint, but we are usually on site, installing SharePoint, what’s needed is a space for the team and other business members to easily share files and reports.


    Printer Access (including colour printer if solutions include design work) – The solutions we provide involve documentation that requires sign off, as well as user manuals – we need a printer to deliver this.


    Meeting room with projector Access – We will need to present our work to key decision makers, so access to meeting rooms with projectors is important, even access to small meeting rooms for team discussions is needed.


    Microwave Oven Access – some of us bring food from home, help us enjoy that meal.


    Drinks/Coffee/Snacks Access – If the team can get the things they like without leaving the building, the team will leave the building less, allowing more time for delivery.


    Toilet Access – Easy and convenient access to toilets is something you desperately miss when you don’t have it.


    Full Access to Development and Staging server – These servers are used for proof of concepts, initial design, development and testing. Full access to this environment is required for the team to work out the best solution.


    Access to Production server – We understand that access to the production server is more strictly controlled, so a clearly defined change control process will be useful when defined at the beginning of the project – so we can factor in the time required and plan accordingly.


    Access to people responsible for network and sever support – We are on site for a short period of time, our timelines are planned on the assumptions that all systems provided by the business is running smoothly, if not, we will require quick resolution.


    A “Driver” from the Business – Since our stay is short, we are seen by many in the organisation as strangers – meaning that when we approach them without assistance from the business for information and support, we usually don’t get the information we require, with someone from the business that can drive support from the rest of the organisation – delivery is much more faster.


    Failure to provide the following will affect speed and accuracy of delivery, as the team may not have sufficient tools to complete the required tasks or the work environment, provided by the business, is not comfortable enough to get the team to focus properly.

    Saturday, July 17, 2010

    Auto Provisioning, the next step in SharePoint

    The thing that makes SharePoint great is the way it was built (yes – that narrows it down!). It was built for the business users (not developers), to have sufficient control and power to create their own web space, that will assist them in achieving their business goal.



    Before SharePoint, we had two extremes when providing a business user with an application or web space to achieve their business goals.


    On one side we have business users requesting an application from the IT department, resources were eventually allocation and the SDLC begins, a solution is provided about a month or so later.  This application had its own database, little to no integration with other systems, its own security component, meaning another set of usernames and passwords the business users need to remember, and its own unique look and feel.


    On the other side, the business user will create an application themselves via Excel or Microsoft Access.  The solution will be available quickly but the solution will be stored on business users workstation. The IT department may have no knowledge of this application, and even if they did, they will have a limited skill set in maintaining the solution. This application will not be backed up and will only be accessible when the business user’s machine is on. 


    So a big thank you goes to SharePoint, with this product, the IT department has an environment that is easily maintained and governed. If a business user require a feature/reporting tool/web space, the people in IT can select an appropriate template, create the site and give the business user sufficient privileges.  Business users do not need to memorise new login credentials, that sub-site is automatically added to the existing maintenance plan and it can easily integrate with other systems. You are now getting the advantages of using both extremes mentioned above.


    Now lets add "Auto Provisioning" into the mix, with auto provisioning, sites are created quicker, governance rules are still followed, and no human intervention is required.

    Thanks to SharePoint workflows and event handlers, sites can be created in code. Not only that, governance rules can be applied to the site via code. So things like themes, site quotas and permissions can all be automatically implemented without the need of getting someone from the IT department.


    So what does this mean? It means that a business user, who requires a feature, can fill in a form and select a template that most closely fits their requirements, they submit the form and two seconds later the site is created, skinned and ready for use with governance rules, like site quotas, already in place.

    Its magical, people in IT can now focus on more important things like improving processes, learning new technology and keeping the movie server up to date.

    Sunday, July 11, 2010

    Please don’t pimp your SharePoint site



    Look at this picture, someone spent allot of money on a Benz, but decided that they wanted to make the car look like a sports car instead, so with a little extra time and money, they added design elements that made the car look different, the new look gets a great deal of attention and everyone wants to drive it, but later people notice that the car cannot drive faster than 30km/h or drive up an incline without breaking something, the lights didn’t work as well as they use to, you can only enter the car a certain way, sharp turns has not been tested but is not recommended and only people with special training or knowledge on how this new look was implemented will be able to wash, repair, drive or fuel up the car.

    Sounds crazy doesn’t it, well, that’s what you are asking us to do when you ask for a SharePoint site that does not look like a SharePoint site.

    Sticking with my Benz example, the Benz comes from the factory in silver, black, white and red, and a special colour can even be created for you. That’s how Microsoft expected you to change the appearance of a SharePoint site, they gave you a wonderful selection of themes (colours) and they gave the developers the ability to create a custom theme, that’s it, that’s the tools SharePoint provide, more extreme looks are possible, but it involves digging under the hood of the car, and adding things that SharePoint was not expecting.

    Yes, drastic looks are possible, not recommended, not supported, but possible, and providing a drastically different look usually comes at a cost, but before we get to that, let’s look at the advantages of providing a strong look.

    The key advantage in providing a strong look, is that it will look great (assuming it was designed by a professional designer), and great looking sites naturally leads to better user experience and better user adoption – two big components that needs to be well satisfied in order for you to see a good return on investment (ROI).

    And to many decision makers, that reason is good enough to spend that extra time and money on the look. Good ROI directly translate to “successful project”, which means good review meetings and bonus, right? Strangely yes, but only if the client does not know why they wanted SharePoint in the first place.

    SharePoint has become this thing that everyone wants, but few know why. This is not uncommon; it’s why the Blackberries and iPhone’s are purchased by people who just want to make and receive phone calls and occasionally send and receive text messengers.

    "Strong" look and feel, i.e. look and feel that involves developers and designers changing code and templates, compromises some of the features that SharePoint provide. This is a fact.

    One example is the search feature, the developers can change the look of the search component located on top of every page, but SharePoint has certain expectations from this control and treat this component differently on different pages. Since changing the search components look is not a supported approach, Microsoft has not provided documentation on how the search component is treated on different pages, and with so many different templates and pages available from SharePoint, it is not practical to test this new looking search component in every possible page available from SharePoint. Meaning that if you add a component the developer did not test, say a wiki site, there is a good change that the site will not look right, or potentially not work correctly.

    The “not look right” problem may happen frequently and should be easy to fix. The templates provided by SharePoint was designed to “look right” in the standard look, if your new look have thinner menu’s and wider content areas or you moved something that was originally placed on the right to the left, each template needs to be adjusted to handle this new look. That means that if the client is planning to add a wiki site, the developer must create a special wiki site template that fits with this look and feel, and don’t forget that this new template must be tested because it has to work as well as the original template, and since each template provides features like mobile friendly views and integration with outlook – these can very easily be things that the developer forgets to test.

    Now, After getting a SharePoint site with a strong look, look at what you have, SharePoint was created to help the business users create and manage sites and collaboration space, SharePoint was created in such a way that the tools and power were given to the business users, not the developers, allowing the business users to directly create the space needed for them to complete their task’s and objectives in a well controlled and governed environment. By adding this strong look, the power is forced to shift back to the developers and designers, because the environment is now too fragile to leave in the business users hands, scenarios requested by the business needs to first be tested by the developers, corrected and only then be given to the business to use, in other words, you are not using SharePoint correctly and instead of resolving the problems that SharePoint is trying to solve, you are just finding new ways in achieving them.

    As always, there are exceptions to the rule. If Microsoft is going to showcase this beautiful SharePoint Ferrari site (click here for showcase), then I must be talking a whole lot of nonsense.

    Well, no, that site is beautiful, no question about that, it got me going to the site, frequently, and I recommend it to friends, and from everyone’s point of view, it is a very successful SharePoint deployment, but how much of that site is using SharePoint, and how much is custom built?

    The site features a discussion forum, did they use the SharePoint Discussion Forum or did they create their own, for better design flexibility? The same question goes for the Blog.

    Apart from the content management component, is there anything else there that’s from SharePoint? And, while talking about the content management component, are they using it the way it was designed to be used, or are they embedding their own HTML/CSS/Javascript/Flash into the content area to achieve this look? Can a business user update the site or must it be maintained by a web developer?

    So, if you want to build a site that have a small amount of content administrators and a large number of readers (like any typical inTERnet site). Then you want a site that is content/images/video/flash heavy, but not necessary feature heavy. This means that the features been compromised when applying a heavy look on a SharePoint site is not used anyways, allowing you to achieve your design objective without anyone noticing the compromise, and as a result, you got a beautiful site with good user adoption.

    InTRAnet sites that are focused on public content only, i.e. information for the entire company to see with no focus on collaboration type content or features, can also have a Strong look, you will compromise the features that will not be used, and still be regarded as a successful implementation.

    But this is an inTRAnet site, at a later stage, people will ask for collaboration features, or will want to implement a SharePoint template that was originally not planned for. That’s when the developers are forced to tweak, modify and add special SharePoint templates, instead of getting the business user’s to add the standard template themselves.