Project Management in a Team Site

Over the years, we have used Team Sites extensively for managing and working in projects. Depending on the type of project, we have used them in different ways:

Simple Projects: stand-alone Team Sites

The majority of projects were simple, short-term projects where a Team Site was used mostly for sharing documents, and perhaps a calendar for meetings and deadlines. Everyone with a good business reason could request a Team Site. We left it to the project manager to configure, which he or she seldom did, but as long as they let us know when the project was finished and the Team Site could be removed, we did not mind. The basic setup was generally sufficient and the target audience small.
We only actively tried to discourage the use of  Team Sites with Tabs; they were very popular but also took a lot of work to set up properly. For a short-term project we thought this was not efficient.

Recurring projects: Team Site with templated subsites

There were also teams who had one project after another, such as product development and IT.  Some of the project managers wanted to have a standard setup for their Team Site for each project. For instance a standard lookup field in every Document Library with the project phases, a custom list to manage time spend, or a world clock because they were working with people from all over the world. Since we did not like to configure stand-alone sites every time, we usually created a subsite template, which we or they could activate whenever necessary. For the project managers it had the additional benefits that all project sites were under one Team Site “umbrella”.
My earlier Crisis Management in a Team Site is another example.

Multiple projects: 1. PMO Team Site.

As every large company, we often had global projects with local or functional sub-projects. You may think of a Sustainability project, the follow-up of  the yearly Employee Satisfaction Survey, or a company-wide Cost-Reduction program.  It was essential that the progress of these projects could be monitored in an easy way. 
Many of those projects were therefore facilitated by a simple Team Site with an Issue Tracking list as the main component. Every project was a line item, that the respective project manager had to update on a regular basis. By cleverly configuring the list and the views we could give a great overview of project progress to the Program Manager.
The individual projects could be managed in a subsite, a stand-alone site, or in a different way.

The first few times we really had to push this functionality to the various Program Managers, but after a few succesful implementations, people came to us immediately when a new global project was planned.

Multiple projects: 2. Program Site Collection.

For other major global projects we created a dedicated site collection. We only did this when it was absolutely necessary, for instance when many people had to contribute (increasing the risk of accidental overwriting), lots of documentation had to be shared, and/or it was important that one country or function did not have access to another’s information.
In those cases we used a templated subsite per country and/or per function. We generally made use of (Corasworks) rollups and rolldowns. For instance, announcements and manuals were posted in one site, and rolled down to all subsites, while the results of the project were rolled up from all subsites into another site for reporting.
All these rollups influenced the performance of the site. Next to that, it was essential to think about security because there were many people who needed access to one subsite or another, and if you wanted to be able to see the rollup of results, you had to have access to all subsites. And then we are not even talking about any changes in template – if the program manager wanted a change to the template after it had been implemented,  it meant that you had to make changes to many individual subsites and to the rollups.
But in the few occasions when we have used this setup, it has worked well.

I will describe and show an example of the PMO Team Site setup in my next post.


5 thoughts on “Project Management in a Team Site

  1. PM Hut January 3, 2012 / 7:07 pm

    HI Ellen,

    We would like to republish your post on PM Hut where many project managers will be able to benefit from it. Please contact us either by email or through the contact us form on the PM Hut website in case you’re OK with this.

  2. Pingback: Intranet Lounge
  3. Stéphane January 4, 2012 / 4:59 pm

    HI Ellen,

    I would like to how you manage the Sites directory :
    How users to access the different sites ?
    How do you update this directory ?
    In SharePoint 2010, there is no more this site directory OOB features which enable directory management (scan link..) as we previously had in MOSS 2007..

    • Ellen January 4, 2012 / 5:47 pm

      Hi Stephane, thank you for your reaction. I do not really know the technical answer since I am not a technical/system person 🙂 There is a site directory, but it is just a list and not very organized. Whenever a new site is created, it is automatically added to the directory. The system is very customized so I am not sure if that is different from OOB. If people have access to a site, they have the link to the site on their intranet homepage, and we also have various places where similar team sites are grouped, e.g. by function or business unit. So people generally can find their own sites easily. But for the intranet team, it is more work to keep track of everything. Hope this answers your question!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s