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.
I may be irritating KPI-addicts, mathematicians, or other people who like counting, measuring and comparing, but what gets measured does not always get done!
Of course that requires some explanation.
When we moved from a custom-built intranet to SharePoint, we had to think about usage statistics. We were accustomed to measuring usage by company unit, which allowed us to see which countries or functions used the intranet the most, and where we had to spend more time to increase adoption. It turned out that a link with our Yellow Pages was impossible in our SharePoint implementation, so we commissioned another party to develop this for us.
When our implementation partner returned with their proposal, their eyes sparkled with dollar signs. They proudly proclaimed that this would be their largest Business Intelligence deployment in Europe!
At that moment, all kinds of alarm bells should have started ringing.
Unfortunately, we thought that this was actually a cool idea.
We spent a lot of time specifying our requirements. As an intranet team we needed information about usage of portal, sites, pages, and documents, about referrers and referrals, by location, country, continent, company unit and discipline, and everything had to be exported into html, xml, csv, excel, pdf and a handful of other formats.
Our content owners would also have nice statistics such as distribution of visits by country and discipline (very useful to see if you were reaching the intended audience), the most popular documents and “just” the number of unique visitors and clicks on their content during various time periods.
When it was finally working (many months later than the launch of the new intranet), we got lost in a slow loading slurry of numbers. With every report we wanted to make, we had to spend an hour calculating, and/or had to read the manual to see how these numbers had been defined. As the company changed, and businesses were divested or merged, the mess kept growing because all the old data was still in the system and contaminated the results.
Because we stored a large amount of data, the system became slower and more sensitive to disturbances. We had to remove data on a regular basis because the server was full. Our service providers were not familiar with these custom statistics so they could not solve the problem. At one point the daily update took about 20 hours. Try explaining that to your users, especially if the 4 hours uptime occur in their night!
So, what have we learned?
1. If you suddenly are someone’s largest project, in not exactly the right discipline (Business Intelligence? For intranet statistics?) please think again. Is this the right partner for you, or are your goals too ambitious for your purpose?
2. Focus on what you REALLY need. We also specified lots of “nice to have, just in case” functionality.
3. Make some scenarios for the future: can this be maintained and supported over time, what happens when major changes occur in your organization, or if you are storing many years of data.
And now, out-of-the-box functionality suddenly sounds very desirable 
.
When I was developing snack products, I was never allowed to talk about my work with people outside my company. Others might copy our ideas! I always felt this was a real pity, because I was convinced that other product developers would have exactly the same problems that I had and we may have shared solutions. Of course I am not talking about sharing secret recipes, but about topics like: how do you do consumer tests, how do you set priorities, how do you work with marketeers who want new products NOW while you, as a developer, want GOOD QUALITY products?
Now we all had to re-invent the wheel ourselves. (Which I hate with a vengeance!)
But now that I find myself in the wonderful world of intranets, life is suddenly very different! Intranet managers continually share knowledge and experiences with acquaintances and strangers, at home and abroad, online and offline, because we share a profession.
Is that because many intranet managers have a background in Knowledge Management? Because we have learned how inspiring, comforting, or just easy it is to listen to the experiences of someone else? Do we all have the same “evangelist gene” that causes us all to passionately change our organizations for the better? Or are we all just lazy, er…I mean efficient, and do we all hate to re-invent wheels ?
Or is it perhaps because we realize that this profession does not have many secrets? Our secrets are in the content. Our secrets are NOT in our design, our platform, our governance or information architecture. What an organization does with its intranet is always based on the strategy and culture of that organization. (Well, at least I hope it is!) So copying another’s design, navigation or position of the web parts on the page is useless, because it will never fit with your organization.
But you can always learn from other intranets of course – if only that you have made the right choice for yours!
Of course I have also had my doubts about the amount of information I could share in my presentations. I have given lectures and removed the screenshots from my presentation for the handout. But later I have just hidden any sensitive information from my screenshots and just left them in. (Screen capture tools like Snagit allow you to “erase” confidential information easily)
A picture really says more than 1000 words! And whether your company news is in the center or left, with a summary or not, is interesting, but it is certainly not mission-critical information.
What then is your confidential content? In general: sales and customer data, financial data, employee personal data, and information about projects in such areas as innovation, lawsuits, contracts and acquisitions. This is generally information that an intranet manager will not have access to, anyway. We may facilitate the collaboration, but we do not own the content.
So…let screenshots do the talking and let’s share more screenshots of our intranets!
Have you ever been involved in a product recall or another crisis? If yes, you will know that this is a stressful time! A recall is very important, it has to be dealt with NOW, and it has to be dealt with correctly to avoid risk, and all on top of your normal work. Everything that can relieve the stress is more than welcome.
What was the problem?
One of our larger countries had occasional recalls. It did not happen too frequently, fortunately, but it was a real hassle when it occurred. There was an official procedure, and many people from different departments and external partners were involved, lots of documents were being sent in various formats and versions. Since people were in a stressful mood, they did not want to spend time on thinking.
The briefing was:
- make all essential information as easy to find, read and edit as possible (not everyone was Team Site savvy, especially the external partners, and everyone was hurried)
- avoid sending documents and emails back and forth – but notification emails are welcome
- have the option to archive the generated information for legal reasons and for learning
- make it re-usable
What is the solution?
We have set up a Team Site collection, with a templated subsite for every recall. The subsite can be created from the top site by the process owner without any help from the intranet team – he has Site Collection admin rights, a rare gift 
The site is set up to deliver maximum info with minimal effort. The process owner only has to check and update the Team Members list which is in the template. The email addresses are displayed in the list so process owner can copy these and give access to all in one step.
Next to that, there is an ongoing Live Meeting to be used exclusively for emergencies. The access information is incorporated in the template.
The Homepage displays the essentials:
- Announcements
- Picture of the product and the problem, if it can be visualized
- Last 5 documents
- Actions assigned to me
- Decisions taken
- Links to set Alerts (all changes, immediately) to Announcements, Documents and Actions/Decisions
- Content editor web part with information for the Live Meeting
- Content editor web parts to inform people how to work in the site
First I created a sort of wireframe, to test if we could display all the most important information on one page.
Wireframe. The items in red contain the most important information.
We decided not to display two lists: the Evaluation (survey), which was only used at the end of a recall, and the Expense Declaration form, which was only used by a few individuals. The process owner will announce the path or link to those lists when necessary.
When a recall is finished, the process owner removes all users except himself and the designated legal person, and stores the site for the legally required period.
Recall Subsite Homepage
What are the benefits?
After the first recall that was managed in this new setup, all team members were very positive:
- The Alerts mean that people receive many emails, but smaller in size and they do not need to be stored, since the actual information is in the site.
- The Alerts ensure that everyone receives the same information – nobody is accidentally left out of an email.
- Sharing everything in one Team Site creates one official version-controlled dossier instead of various personal ones. This saves everyone time and stress and creates confidence.
- The Live Meeting allows people to discuss anytime from anywhere, saving time and travel. (especially since you need to meet at least once a day)
- The evaluation survey and the expense declaration are now online, and no longer in individual documents. This saves time in aggregating the results, and creates instant transparency.
This is in fact a very simple setup, without any complicated lists or workflows. The most time-consuming part was making sure that a new subsite copied everything correctly, so it was ready to use instantly. I had to make some sacrifices, e.g. display the lists and libraries and train people to set an Alert, rather than displaying the direct links to the alert pages. But because it is tailor-made for the situation and can be used almost instantly, it is a real time- and stress-saver!
Further improvements are possible, like using an Issue List for the required log, but at the time it was too complicated for the users.
Have you used Team Sites in a similar way? Please share your examples!
“What’s in a name? That which we call a rose, by any other name would smell as sweet.”
Well, if William Shakespeare has said this, who am I to disagree? But I think that the name DOES make a difference when it comes to content!
Take a look at this screenshot.
Local news functionality in two countries
Both countries use exactly the same functionality for the same purpose. But the language of country 2 is both more informative and more inviting: You know you have a new colleague called Annette. If you are curious about where she works, you can click on the article to find out more. But if you have limited time, you know at least the essentials. This title has a good “information scent”: it immediately gives you an idea what the information is about.
This seems very logical. Yet sometimes we forget to think carefully about names and titles. My communications colleagues have been known to send a weekly newsletter from “”ic@company.com” (and not “Internal Communications” or other descriptive name) with the subject line “Newsletter week 43, 2010″. That just does not smell nice!
Another example: in the Netherlands the first truly relevant documents on our intranet were about employee benefits. All Dutch employees had the link on their homepage for easy access. Yet we received complaints:
The content owner complained that people kept calling and emailing for information, even though “it was all on the intranet”.
Employees grumbled that they expected to find employee benefits information on the intranet, but they did not know where to look.
What was the case? The link was the same as the acronym of the originating department, and that was, very intuitively, “CSPO”.
Fortunately the solution was exactly as simple as you think!
Tips:
- Always spend time thinking of titles of documents, emails, navigation elements, links, “from” and “subject” lines in your e-mail, etc.
- Look for alternatives and test them with a few colleagues, especially if this is information which is important, has a large and diverse audience, and/or will remain on your intranet (or website) for a long time.
- Keep in mind that what is obvious to you is not always as clear for your audience. Your content may be a rose, but if you call it ” manure” you will definitely have fewer visitors!
Further reading:
Helping people find the content they want, from Step Two Designs, with explanation and examples
Boosting Information Scent, from WebSiteOptimization.com, with useful tips
Keep People on your site …. of VanSeoDesign with the theory
And your own examples are welcome, too!
“And, did our French colleagues decide to use the Local News functionality?” my manager asked me one morning, when I had just returned from a visit to our Paris office.
I looked up from my desk in surprise. “How do you know we discussed that?” I asked him.
“Well”, he smiled, “I saw a news item on the intranet”.
Oops! I felt my face flush and did that office floor just sink a few centimeters? It turned out that I had created a news item, just for demo purposes, and forgot to target it to France, and forgot to delete it. Since I was a global administrator, I automatically published to all countries. So “A new intranet for France’ was visible to all employees, with a “blah blah” as the text. Luckily it was programmed to show at 8 am, and it was only 8.15 am when it was discovered, so the damage was small, but I felt so stupid!
Of course this did not happen again. But others did; and because I always like to see the bloopers on my sitcom dvd’s, I thought you might want to learn about my mistakes too; after all, it makes us human!
Another great blooper was the deletion of a complete Team Site while I was configuring it. Or rather, after I had configured it. I thought I was deleting a subsite, but I was on the top site! Three days of configuration down the drain, and on top of that, I was working in Spain, because that way I could work more closely with the business owner. I had promised him that he would have a working prototype by the time I left, which was a few hours later.
Luckily I had a very able colleague who restored my site in 5 minutes, but it were 5 very long minutes! Since then I have always looked at the URL at least twice before deleting a subsite, so I have never made this mistake again.
But my biggest mistake must have been my failed efforts to streamline our Investment Request process. The Investment Request is a complicated form to ask approval for a large investment such as new machinery, a commercial, or software licenses. Depending on the purpose, the business and the amount it had to be approved by different people, and that meant that the process took a long time and was completely opaque. It happened freqently that nobody knew where the form was or that it was lost completely. Everyone agreed that this needed a better process. And since we agreed that it would be wise to try and use our existing SharePoint platform before blindly buying a dedicated tool, we decided to try and describe the current and ideal processes.
The idea was that the forms would be in a Document Library in a secured Team Site, with a Nintex workflow enabled. We would add the approval procedure to the Team Site, with an agenda of the next decision meetings and the deadlines for submission, to give all people submitting a good idea of what they could expect.
There was general agreement about the process, but it turned out that the exact routing was decided afresh every time. Even while we had only about 8 people involved in the approval, the sequence varied and I could not find the deciding factor. Did one amount needed a different routing than another amount? Did availability of the participants play a role? Was it the part of the business the request originated from? I needed this information because the Nintex 2003 workflow was not very flexible and we needed some structure. But I was convinced that with 3 or 4 different workflows we would be able to capture 80% of the requests easily.
I was rather shocked that nobody could provide information on the sequence. Just for a joke, and to make people aware of the strangeness of this situation, I asked if it might be the moon or the pollen count?
As it turned out, this was not appreciated. I have made a Proof of Concept and tried to interest the business owner to test it, but to no avail. Lack of time, too difficult for his assistant to understand, not flexible enough, all excuses were made.
Still, this is a mistake I will happily make again and again! I firmly believe that, with a bit of flexibility and structure it would have worked and would have saved the company a lot of time and hassle.
Do you have any bloopers that you would like to share? Please add them to the comments!
If you are doing well with helping the business reap the benefits of your SharePoint implementation, you will always have several projects running.
Assuming you have the right people, have decided on the priority of each project, and have the process steps defined, you will also need a way to keep track of all upcoming, current and finished projects.
A good tracking system will enable you to:
- manage your resources
- calculate the priority for each project
- see how many projects you have completed and how well your pipeline is filled
- calculate how much money you have saved the company
- track the number of projects you have done for each segment of the company
- generate information about your projects, such as time from start to completion, average priority etc.
It will come as no surprise that we have used a Team Site list for this purpose. An Issue List allowed us to see the history of each project, which was useful to track progress.
The List
Some of the fields that we have used were: (images are clickable for better display)
Project information, such as problem description, business owner and deadline.
Project Information
Status information, such as the project step, a description of progress, and % of completion. These fields were on top of the list so we could edit details quickly
Status Information
Priority information, as described in an earlier post. We used 0-3 to score each dimension, and calculated the final benefits score with a calculated column
Priority Information
Technical and maintenance details, for example the way we had built the solution or if any long-term maintenance was expected
Techical and Maintenance information
The Views
By creating different views of the resulting list we had a wealth of information at our fingertips:
Various views
- My projects
- All active projects, grouped by project manager
- Projects by status (not started, in progress, completed, cancelled, etc.)
- Projects by business segment
- Projects by year, to see how we had performed
By doing this in a structured way, we have also collected many interesting learnings. But that will be another post!
You can find earlier posts on the process via the DMWS-Process tag.
Earlier I have shown you some examples of external business partners being able to read (New packaging requests), or edit (CRM) list items in a Team Site. This time I would like to show you an example where an external partner creates the new item. Not because that is technically very impressive (although it means a lot of testing from a home PC and a test account with no admin rights), but because it shows once again that you can do this type of thing in SharePoint, without having to invest in another tool with a different interface, different support model and what not.
What was the opportunity?
Since this was a new process rather than an existing inefficient process, let’s use another header text .
The company I worked for was exploiting coffee & tea stores. It was a logical step to use an External Team Site for communication between central management in the company and store managers and employees.
We started with sharing information top-down, such as manuals, promotion information, recipes etc. Later we asked store managers to confirm (in the Team Site) that they had received their promotion supplies and we installed a discussion board for all employees to add recipes and other suggestions etc.
Next was a promotion where consumers could enjoy a High Tea in our stores. Since stores had limited capacity for High Teas the consumers had to make a reservation via an external call center. And guess where the call center collected these reservations? Indeed, the same Team Site.
What is the solution?
We used a Custom List to capture store, customer name and telephone number, number of visitors, date and time. We created a number of views, such as grouped by Store Location and a list of Today’s reservations. We added a sum of the visitors so the call center knew how many places were left on any given date and time, and the store employees knew what they could expect that day.
Central management set an Alert (Added Items, Daily Summary) to keep track of the reservations, and therefore of the success of the promotion.
New Reservation Entry Form
High Tea Reservations (Today and later, only), by Location
What are the benefits?
- The promotion was a big success, and while that was of course not due to the Team Site, it meant there were many reservations being entered into the system. The process went smoothly because the call center did not report one single issue.
- Store employees had a good overview of the number of reservations, so they knew what was expected of them. They could also see other stores’ reservations, so they knew how succesful the promotion was. This transparency was much appreciated.
- Central management could monitor the reservations as they were added, and was able to do a good analysis on the preferred locations, dates and times, which helped them plan new promotions.
This might have come as a pleasant surprise for them, but not for us. We know how easily these things can be done in a Team Site !
Although this example is actually about Live Meeting/Lync and not about SharePoint, is does illustrate my point that you can do more with your existing toolset than you think!
What was the problem?
One of our content experts needed to train about 150 people across Europe. She had always visited each country when there were a few people who needed training, but she was now looking for an option that would save time and money.
An official e-learning module was rather expensive, especially if it was for only 150 people. Also, only an external person would be able to make adjustments to the module afterwards. And she did not need all the functionalities of a dedicated Learning Management System (LMS).
So we had to think of another way to meet her needs.
What is the solution?
We decided to use PowerPoint, a Team Site and a standard Live Meeting (web conferencing) with poll and recording functionalities.
To make her feel comfortable with the tool, we helped her with
- setting up a meeting with the desired options
- sending out custom invitations
- creating and managing polls
- handling the Q&A panel
- looking at the meeting reports (attendees and poll results, which would serve as her “LMS”)
- creating a recording
- a “dry run” to fix any functional issues she might encounter, and to give feedback on other aspects of the training
- attendance at the first session to make sure she felt comfortable and could focus on the content of her training
The PowerPoint, the training schedule and the recording were stored in a Team Site, along with other content on the topic.
The different parts of the training
One of the poll questions
What are the benefits?
Of course this saves her time and money, but also
- All trainees can easily access the training, since there were no password barriers.
- Doing the training via Live Meeting enables her to have personal interaction with all attendees. This would not have been possible with an e-learning module.
- The interaction and discussions are much richer than in her one-country-trainings, since every session attracts attendees from different countries.
- New employees have a faster learning curve because they can watch the recording as soon as they need it.
- Giving this training several times, and analyzing the poll results, allows her to continuously and quickly adjust the training to the needs of the audience.
- She can make any changes herself – it just needs an update in the presentation and a new recording.
So, once again it shows you do not always need a lot of fancy new shiny software to be able to meet your business goals! Check what you already have at your disposal, use your creativity and off you go!
Do you have a good example of using web conferencing? Please share it!
So, you have a business process that does not run as smoothly as it should; it is not (yet) in scope for your ERP, and you and the Business Process Owner have agreed that you will make a (temporary) solution in SharePoint. You have a team, you know how to set priorities, and now…
How to start? And how will you do the next project? Will you re-invent the wheel for every new project? You may do that for the first few projects, but then it is time to collect your learnings in a standard process to give you a good guideline. And especially when working with others in one team, it is important that all of you work in the same way.
Basically, this is an IT-type project; the main differences being:
- no financial investment – your platform is already available
- no technical implementation – the focus is on business change and configuration, not on code
- the Site Owner is responsible for ongoing maintenance, including small changes
We have defined the following major steps. Every step has a set of substeps, that you will apply depending on the complexity of the problem and solution.
1. Project Definition
You discuss the project, scope, mutual expectations and business case with the business owner, and agree on the next steps.
2. Design
You create a prototype or proof-of-concept to test your understanding of the issue, to give a business owner a tangible solution for initial evaluation and feedback, and (optional) to validate your functionality assumptions.
3. Build and Rollout
Upon agreement of the proof of concept, you build, test, rework, and finish the solution with the business owner. Next to that, you also support the business owner with implementation in the business. Finally, you train the business owner and back-up in maintaining the solution and how to get support.
4. Ongoing Maintenance and Support
While your business owner should be able to make small changes and maintain the content, you may need to help him or her with the more major changes or bugs. Also you will want to monitor the site’s usage over time, and keep track of housekeeping issues.
I will elaborate on the different steps in later posts. You can find earlier posts on the process via the DMWS-Process tag.
