On October 5 I participated in IntranetNow, and a wonderful conference it was!
There were plenty of interesting and enjoyable presentations but below are the ones that resonated most with me:
1. An excellent Yammer use case
Baxter Willis of WM Reply shared a great Yammer use case from one of his clients, drinks business Diageo.
Apparently they have an archive of all bottle types, advertising materials, recipes etc. Nobody was really aware of that department, until recently. They are digitizing their content and the archivist posts something interesting on Yammer every day, e.g.
“Did you know that Pimm’s has been associated with Wimbledon from the 1930’s?” accompanying a picture of a nice old newspaper ad proving her point.
This lady is now the toast of the company and her Yammer group is very popular.
I like this because it is another easy way to share knowledge, which would otherwise be hidden in the archive. Posting it on Yammer costs nothing more than 5 or 10 mins a day. It helps the Marketing and Social Media people in their current work by giving them new insights to the company and its history.
The new Smirnoff label is now based on earlier labels throughout time, and this is also caused by this work!
What I liked about this is that they used a simple but effective approach of lunch sessions, and shared their learnings.
The “let them rant” or “whine and dine” idea resonated with me, as I have also found that sometimes people just want to vent, sometimes not about the intranet itself, but about related things.
In my situation I have heard from several annoyed people who had been handed over a team site due to reorganizations – either because they had a new role and the team site came with it, or because the previous owner had moved on. Someone else’s team site can be quite hard to handle as the setup and especially the permissions are not always documented or intuitive.
I have learned that the best way to help them is to go through their site together, trying to make sense of it (looking at site contents, checking permissions), rather than trying to defend something or taking it personally. 🙂
No, I am not going to bash the SharePoint Most Valuable Professionals! I have received help, feedback and support from many MVP’s including Veronique Palmer, Jasper Oosterveld and Gregory Zelfond, and I have read and used the posts and presentations of many others.
Let’s celebrate the unsung heroes: “The @MVPAward recognizes individuals who, over the past 12 months, have demonstrated superior knowledge, leadership and passion, combined with a desire to help and accelerate other’s learning, careers, and abilities.” https://t.co/R0eebaLcz5
This blog will be about another MVP – the Minimum Viable Product, a common word in Agile development, meaning you will launch a product that meets the basic requirements (as defined at the start of the project) and will be improved incrementally over time.
I think I have been woking somewhat agile when I was configuring solutions, and met with my business counterparts on a very regular basis to discuss the proof of concept/prototype and checked if this met their expectations.
I only created a very small list of requirements, as I knew that many business partners only had a vague idea of what they were really looking for, and when confronted with my interpretation of their requirements all kinds of unexpected, or in any case, unspoken, things came up.
Is there an option to leave this field blank?
Yes, but that means that we either leave this non-mandatory (which may lead to more blanks than you want) or we add a dummy value such as “please select”. What do you think is best?
Can we have a multiple choice for this field?
Ofcourse, but that means you will be unable to group on this in the views, so we will have to resort to a connection for filtering. Oh and then it is better to make this field a look-up field instead of a choice field. Let me rework that.
What if someone forgets to act on the email?
We may want to create a view that allows the business process owner to see quickly which items are awaiting action.
And more of those things. I generally met with my business partner once every fortnight, if not more often.
So I am all in favour of especially the short development cycles of Agile.
“Users” does not mean “end users”, exclusively!
I also think that “user stories” are much more realistic and human than “requirements”, although they sometimes look a little artificial.
By the way, I would recommend any team to think not only of “end user stories” but also of “tenant owner” stories or “support user stories” as other people involved have their own needs or requirements.
I also like the idea of launching a Minimum Viable Product and doing small, rapid improvements on that, based on feedback and experiences, because
You can show users that you are listening to them
You can show that you are not neglecting your intranet after launch
It gives you something new to communicate on a regular basis
So, when we were launching our intranet I was quite interested to be part of the project and to work towards an MVP.
When we finally launched our MVP we also published the roadmap with intended improvements, and shared the process of adding items to the roadmap. That way users could see that we had plans to improve and that we would be able to spend time and attention on meeting the needs of the business.
When launching an MVP with a promise to make ongoing improvements you are more vulnerable than when you do a Big Bang Launch & Leave introduction. What about the following events?
Cuts in the improvement budget.
Those can be a blessing or a curse, but they may happen.
People who leave before they have documented what they have created.
I have never liked the extensive Requirements Documents and Product Descriptions that go with traditional development, but if you are handing over your product to the Support organization, you really need documentation of what you are handing over. End users can have the weirdest questions and issues! 🙂
Reorganizations which turn your product team or even your company upside down.
Microsoft changes that mess up your customizations. We have a webpart that shows your Followed Sites – it suddenly and without warning changed from displaying the first 5 sites you had followed to the last 5 sites. Most annoying!
So before you know it, you end up with a below-minimum viable product. ☹
What can be done?
So before you start singing the praises of Agile development and put on your rose-tinted glasses
Make sure you have a safe development budget that can not be taken away from you.
Ensure you have an alternative no-cost optimization plan, such as webinars, Q&A sessions, surveys, configuration support, content changes etc. to make the most of the launch of your MVP and to get feedback for improvements for when better times arrive.
Insist that everyone documents their configurations, codes, processes, work instructions etc. as quickly as possible. It is not sexy but will save you a lot of hassle in case your team changes.
If you are in need of extracting knowledge from leaving experts, here are some tips for handing over to a successor, and some tips for when there is no successor in place yet.
Be prepared for changes in processes, data or organization. You do not have to have a ready-made plan, but it is wise to think about possible implications for your product or process if the Comms team is being reorganized, someone wants to rename all business units, or you need to accomodate an acquired company in your setup.
Keep customizations to a minimum. Use existing templates and simple configurations.
Personally I would be totally content without a customized homepage. The SharePoint landing page or, even better, the Office365 landing page as the start page to my day would work perfectly well for me, but I have learned not many people share that feeling.
Any experiences to share?
Have you had similar experiences? Have you found a good way to handle budget cuts, a way to develop budget-neutrally, how to deal with people changes or another way to deal with unexpected events that endanger your MVP? I am sure there are many people (including myself) who would like to learn from your stories!
Recently I have been helping to launch a new Office365-based intranet.
While we set out with the idea of “out of the box” (a sound strategy, knowing my earlier experiences with extensive customizations) we have had to create some custom things to meet the requirements of several stakeholders.
I was therefore very interested in Clearbox Consulting ‘s evaluation of 26 “SharePoint intranets in a box“.
Unfortunately this report was published when we had already progressed very far in our intranet journey, so there was no reason to buy it.
Still, it kept nagging me because I was really curious if we could have used one of the “out-of-the-box” solutions.
So you can imagine my surprise and elation when Sam Marshall provided me with a copy just before Christmas, as well as a discount code for the readers of this blog.
What is this report about?
It compares 26 products of companies claiming to have a ready-made SharePoint intranet. This means that you do not have to do any developments yourself. It is just some configuration and a little branding.
The researchers have made the evaluation by comparing a set of standard scenarios that most intranets will need:
The major strengths are:
Many offerings compared – I never knew there were currently 26 different products!
The evaluators are all experienced intranet peeps who know what they are doing.
The evaluation is based on recognizable business scenarios.
Consistent and objective evaluation. (We could never have done it, since we would undoubtedly be biased by our own requirements)
To think about
The cases provided are all very common in the intranet world. However, you may have some unique requirements that are not mentioned here. In that case, you may need to create your own filtering to find out who would be the best in-a-box-partner for you.
As mentioned earlier, SharePoint and Office365 are changing very rapidly, and I do not know a. how well all vendors can keep up, and b. if and how quickly SharePoint developments will catch up with the vendor’s unique features. (I heard “Corporate News” is on the Microsoft roadmap for 2017)
I expect new vendors to appear as well as consolidations.
So, I therefore hope and expect that there will be regular updates to this report…
Who should read this report?
Anyone who is starting on a new intranet should definitely read this.
This may help you to decide if SharePoint would be a good option for your organization. You may think SharePoint is too much and too big, but an out-of-the-box solution may just offer what you need without too much hassle.
If you already know you are going the SharePoint way, the report may help you to determine if a ready-made solution would be useful. Even if you think you know SharePoint well, you will learn a few things that may be relevant for you now or later.
You may decide not to go for a ready-made solution, or even not to go for SharePoint at all.
The report may also trigger you to refine or extend your requirements. For instance, we all have “Company News” on our radar, but have you thought about if and how SharePoint can be used for ideation? If Communications is your major stakeholder, they may not immediately think of the need for transactions. You may want to check with all stakeholders if they have thought about those things.
Anyone who has to decide on the need for custom development.
If none of these vendors mentions what you are setting out to do, you may indeed need to develop it yourself. But if they all provide this functionality, it is probably available as an app somewhere.
Anyone who is working on their intranet or digital workplace roadmap, to determine whether it makes sense to move to a ready-made platform in future.
Anyone who is curious what intranets-in-a-box have to offer.
But isn’t this a lot of money?
No, it is not.
That amount of money will buy you only a few hours of consultancy. If you want to set up your own requirements to test against, agree on it, find and talk to all the vendors, have demos and evaluate all the results in a consistent way you will need much more time than “just a few hours”.
Besides, the evaluators have not been biased by their own requirements.
I can offer you a 10% discount if you use the code “IIAB2CBOX10” on the product page .
You can probably get away with charging this (< 500 € / £ / $) on your credit card and submitting it as expenses 🙂 .
Good to know
I have reviewed this report for a number of reasons:
I was interested in the topic because I was curious if the intranet I am working on could have been done out-of-the-box, which might have saved us a ton of time and hassle.
(Answer after reading the report: I think we really needed the extra work we have done to meet the requirements.)
So far, I have been the only “practicioner” who has reviewed this report. I think it is important that someone, who is actually in the middle of a SharePoint project in a company, shares their view.
You will find more reviews on the Clearbox blog.
I have known Sam Marshall personally for a number of years. I also know most of the people who have worked with him on this report. I have great respect for all of them. Therefore I trust this report.
This has been a Christmas present so I have had the time to read and think. 🙂
So, everything came together very nicely this time.
“Andrew, it is not working” I shouted from my office.
“K”, came the reply from across the corridor, after 5 or 10 minutes followed by “Fixed it!”.
Andrew, our in-house SharePoint whizzkid, had built our intranet, knew everything about it, and liked a challenge. He loved finding out what was wrong and fixing it before I had time to tell any user that we were working on it. Sometimes he had to reboot a server, sometimes it was a piece of code behaving strangely, sometimes a local hitch, but he was 99,99% reliable to fix any issue within an hour. And he was not even an employee, but someone we hired long-term from a partner.
But then management decided to outsource all application development, service and support to one external company. Of course this would save the company lots of money. We could now use people depending on our needs, did not have to plan around holidays or be worried about illness. The service provider was supposed to be knowledgeable in all systems, including SharePoint, so that was convenient.
So we had to let go of Andrew and his colleagues. Andrew followed his long-time dream of moving to Australia and the last time I looked at his LinkedIn profile, he was still there.
But first we had to handover all info to the service provider.
We created a team site for all documentation, code, installation manuals and what not. Next to that we organized many Live Meetings to go over all details with the new support party. We recorded those and added them to the documentation site.
So, the good point of the situation was that we were finally forced to get all our documentation properly organized :-).
Unfortunately, there were also a couple of bad points…
First of all, there were lots of language and culture issues so it took quite a while before everyone understood each other properly. The fact that Dutch people are quite direct (if not downright blunt), and not very hierarchical, was not really helping the working situation with a partner from a more cautious culture where everything had to go through a manager.
Our service provider did not understand our environment due to the many customizations. They always wanted to change code to solve an issue, but since we no longer had anyone in our team who understood the implications, we were afraid to approve of that. In the end it meant that issues were not solved at all and we learned to live with them, anxiously waiting for the moment we could upgrade (which did not happen during my time at the company).
All issues had to be reported, reviewed, taken in, calculated, approved, planned, executed, tested, approved, implemented and communicated. And that was without any rework! OK, I also like some order in my household administration, but it was so much work and took so long. How I longed sometimes to shout “Andrew!” And sometimes I just did, for the sake of it :-).
And whenever we had finally created a good rapport with a team member, he or she hopped to the next job with hardly any handover and we could start all over again, instructing someone into the intricacies of our system and hoping (in vain) that over time, issues would be solved.
We were not the only team with issues. So management organized regular top-to-top meetings to discuss the issues and iron out all wrinkles. Nobody dared to question openly if, given the general inefficiencies, there were still any savings compared to having an in-house crew.
When asked about the turnover of project members, the support provider answered with a longer version of: “Our people want to have a varied career and we want to provide them that”. I read the statement at least 3 times, but I could not find any reference to the words “customer”, “service”, “commitment”, “continuity”, nor any synonyms.
Since then I have heard the same story from many others, so I really wonder if outsourcing is such a good idea. In theory it sounds good. With the opportunities of the digital workplace and all parties being used to remote working, we should be able to collaborate seamlessly and independent of location. Within our direct team we certainly could!
However, in practice it simply did not work well. Did we just resent the situation? Was it the cultural differences? I do not think so. I rather think it is because by outsourcing you introduce measurable formality, and take away things like responsibility, company loyalty, spontaneity and team feeling. And those last 4 things, which are not as easy to measure as “total cost of ownership”, “average resolution time” and “customer satisfaction score” may be more important than we think.
What do you think? I would really love to hear from someone who has a great working relationship with their outsourcing partner, or from someone who has reversed their decision to outsource. Please share your story and especially: share your lessons so we can all benefit!
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.
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.