in

SharePoint Blogs

The Best Place for SharePoint-related Blogs

This Blog

Syndication

News

Clicky Web Analytics

Sharepoint Use Cases

This blog delivers real life use case and my opinions about Microsoft products.

June 2008 - Posts

  • Bulding a SharePoint team

    A friend of mine asked me a very good question: How do you form a SharePoint team?

    All development teams are similar, but SharePoint projects are not a pure development effort so slightly different team members will be required. I will try to compare my idea of a SharePoint team with existing roles in MSF. Roles in MSF are complex and you should consult MSF Team Model Overview for more details.

    The key person in your SharePoint team is a consultant. Consultant should be familiar with the complete Microsoft platform offering. SharePoint solutions are built on various Microsoft infrastructure products so in order to deliver the best solution to your customer you must choose proper Microsoft products, licensing models etc.

    Consultant's key abilities should be: the ability to recognize customer's key business challenges and map these to SharePoint feature areas. Your consultant will also be a part of pre-sales process; making presentations and delivering various sales documents. In small teams consultant will also handle project management and education activities and in some cases development. In your team consultant knows most about SharePoint, but he can also consult your customer about collaboration, document management, records management, enterprise search etc.

    In the following table I outlined some differences of the basic MSF team model and roles in a SharePoint team. Please note: for smaller teams you do not need 7 roles because some team members can be in more than one role. Please consult MSF for details on this.

    MSF Role Cluster MSF Goal In a SharePoint Team
    Product Management Satisfied customer When selling services you need an account manager. AM is responsible to find open new sales opportunities, he needs only basic knowledge of technology but a fair knowledge about business processes surrounding it.
    Program Management Delivering a solution within project constraints Similar to MSF, but your program manager must know his way around SharePoint very well! Managing a SharePoint project is not an easy job for a PM that is not familiar with the product itself.
    Development Build to specification A SharePoint developer is not a regular .NET developer, this guy needs to know some additional "tricks". Patrick did a great job outlining requirements for a SharePoint developer. If you plan to hire a newby please note that it takes 3-6 months for an ASP.NET developer to become completely productive in a SharePoint environment.
    Test Approve for release only after all
    product quality issues are
    identified and addressed
    For a larger project you should definitely hire a QA Lead. Consider unit tests, continuous integration, daily build and smoke test. Testing SharePoint solutions automatically is hard but is not impossible! It is a must have for a larger project.
    User Experience Enhanced user effectiveness If you are building a SharePoint solution that includes custom design you will need a designer. Designer should have advanced knowledge of HTML and CSS and he should be familiar with ASP.NET. In order to produce some work he will have to learn SharePoint Designer, the key tool for adapting SharePoint design. It will take some time for a newbie to learn the tool and SharePoint in order to modify the design properly. Give a newbie enough time since design customization is not easy.

    For larger projects will need a trainer to conduct education of the end users.
    Release Management Smooth deployment and
    ongoing operations
    It is a good practice to add a system engineer to your team. This guy should know his way around IIS, SQL, ISA and other core infrastructure server components. Although most customizations will be done by developers having a good system engineer will ease the deployment customizations of production environments.

     So, the ideal SharePoint team is:

    1. Consultant
    2. Account Manager
    3. Project Manager
    4. Developers
    5. QA Lead (QA engineers)
    6. Designer
    7. Trainer
    8. System engineer
  • Document libraries: Specify which items users can edit/delete - explained - Part 1

    In my previous post I tried to explain how can you forbid your end users to delete files from document libraries. I did not provide much details on how to setup this and some visitors raised additional questions about that.
    In this blog series I will provide step-by-step description how to achieve this.

    Creating custom permission levels
    In order to achieve our goal we will need to create custom permission levels. Permission levels allow you to define what a user can do. Default permission levels are not sufficient for our case so we will have to customize them.

    1. Create a new WSS site with custom permissions

    2. Select Site Actions > Site Settings

    1


    3. Under User and Permission select Advanced Permissions
     

    2

     4. From the permissions toolbar choose Settings > Permission levels

    3

    Your permission levels are inherited from the top level site. In order to achieve our task we need custom permission so:

    5. Click on "Edit Permission Levels" and then confirm that you want to create custom permission levels

    4

    6. For the purpose of this article we are going to modify Contribute permission level.
    Click on Contribute
     

    5

    7. To disallow deleting de-select Delete items under delete permission.

    6

     8. Save your changes.

    By default members of "Your site members group" have Contribute permission level. Add an user to that group in order to test the changes you made. If you follow these steps correctly members will be able to create and modify document but they will not be able to delete documents.

     The picture below shows contributor's interface. The delete option is missing from the context menu.

    7

    In part two I will describe how to create a workflow to delete these documents.

  • Running MOSS and Project server on the same machine

    Running more than one Microsoft server product on the same machine is always tricky. If you really do not need them on the same machine you should consider running all these machines as VMs.

    We usually advise our customers to use virtual infrastructure instead of physical machines. VMs are cheaper to implement and easier to manage. Our usual infrastructure setup is one (or more) physical machines and storage cluster. On physical machines we are running every Microsoft server product (CRM, MOSS, PerformancePoint, Project Server) on a single machine.

    If virtual machine approach is not acceptable, and you really need to run MOSS and Project server on the same machine, take a look at following article

     


Need SharePoint Training? Attend a SharePoint Bootcamp!

Posts (c) their respective authors. Everything else (c) 2007 SharePoint Experts