DoMoreWithSharePoint – Promote your services

It has been some time since my last post about the process we used to “DoMoreWithSharePoint” so let me do a short recap:
All businesses have a strong need to streamline processes, use workflows, manage requests and collect complaints. Not everything is in scope, or in scope yet, for the company’s ERP system. There is always a need for facilitating those simple processes that will never make it into your ERP system. Yet SharePoint is there, but most people do not know how it can help them, except for sharing documents and using the odd Calender or Announcement list.

So there is a big opportunity for everyone who can bridge the gap between the business needs and the SharePoint offerings. We have done that with a solid process for custom Team Site configuration. In earlier posts I have discussed people, process, project and priorities, and now it is time to talk about promotion. Because you will have to do some evangelisation work and communicate your happy message to your employees!

How do I get my message across?
We found that examples work very well. Try to find a few people who want to pioneer, or who have actually asked you how to use SharePoint for their purpose. Those first projects will provide the first materials.
I have used a presentation with screenshots and a few bullet points of the problem, the solution and the benefits (as I do in my examples on this Blog).

Who are my main target persons?
People who may be interested in this are generally various business heads and IT, but also managers of specific projects your organization is involved with at the moment. And there will always be other employees looking for ways to work more effectively.

1. IT Service Managers
Your local IT service managers can be your biggest fans and customers. (They can also be rather hesitant, because they are not always fully aware of the capabilities of SharePoint, or are used to look for solutions elsewhere) They will generally receive the questions from the business for “new functionality”. Employees may have seen something, or they just want to do something in a better way, without knowing exactly what they want.  They often “have a friend who has just started up and works cheaply”. Your IT service manager would do better by running all these requests by you, so you can pick out all projects where SharePoint can do the trick. Advantages? Plenty! Think about

  • no investment in new functionality
  • consistent navigation and look-and-feel if you use a Team Site
  • integrated support
  • updates and migration incorporated in your intranet/SharePoint plans.

2. Business Heads
We conducted a yearly “roadshow” and targeted a different audience each year. One year we focused on general managers of the different business, another year we went to logistics managers, the next to sales managers, etc. We created a new deck of examples every year, selecting those solutions that we thought would appeal to that group. In a face-to-face meeting we asked them

  • what their business targets and priorities were for the coming year
  • if they were happy with the way they were sharing information with their teams and peers
  • if there were any processes that could do with some streamlining

Generally, these questions combined with our presentation led to a couple of opportunities, which we would then prioritize. Sometimes they would forward us to someone in their team for the exact information, but that was OK since it meant they were sponsoring that project.
And even if this round did not bring opportunities, at least they were aware that our services existed.

3. “Special Project” Managers
Whenever there was a new cost reduction program, an acquisition or divestiture coming up,  an environmental awareness campaign started; whether this was global, regional or local, we always tried to find the program or project manager. We offered him or her to set up a Team Site where they could manage the information and/or the progress. (See my earlier example of a PMO Team Site.) After a few of our “PMO solutions” the business started to ask for a PMO-site before the official kick-off of the project!

4. All employees
To ensure that other employees were also aware of our configuration  services, we  used all our channels to get our message across

  • Publishing examples in our intranet blog
  • Presenting at get-togethers
  • Asking Communications to publish articles when we had delivered a particularly interesting solution (such as the Incident Log)
  • Suggesting SharePoint alternatives for every “mistake” we saw people make, such as sending commercials via email to a large audience, using internet survey tools rather than a SharePoint survey, collecting data in Excel files, etc.
    I must have irritated a couple of people over the years by always giving them unsolicited feedback about their working methods  🙂
  • Whenever they asked for help or requested a Team Site, we gave them the option to configure the site for them, especially if we thought it would be beneficial (and they were prepared to make that small business case we needed)

Despite all our efforts there were always people who did not know, or did not want to know, what SharePoint could do for them. But we never tired of trying to get our message across.

What do you do?
Have you been doing this in your organization? Until now I have never come across an organization where custom-configuration is done in a consistent manner, so I would like to hear from you!

Advertisements

The Business is the Bottleneck

Bottleneck“Ellen, could you have this site up and running in about 2 weeks?” my clients often asked. “Yes, I could, but can you?” I always answered, “my experience is that the business, and that is YOU, is usually the bottleneck.”
The client always looked a bit annoyed when I said that :-). And that was a good starting point for a conversation about roles and responsibilities.

Why was it sometimes not ready in 2 weeks?

Of course it is understandable that someone wants to use his or her new site quickly. They have a problem or a good idea, and they want to take advantage or solve the problem as quickly as possible. And when you are the business owner of a problem or an idea, and you brief someone else to do the configuration of a site that will address the idea or problem, you will want to know when it will be ready. We have all done Project Management, haven’t we?

But the business owner has his or her regular work, and that always has priority. Products must be developed, manufactured, promoted and sold, customers or suppliers must be visited, and reports created.
In addition, the business owner does not always know what is expected of them when they ask for support. “I give a briefing, you understand exactly what they need and want, so it should be ready for use in 2 weeks” is the prevailing thought.

Unfortunately, that is not always the case.

  • I may have misunderstood something
  • Functional requirements may need to be translated in a different way than expected, which may have unexpected consequences which have to be dealt with
  • It may turn out that in real life the process is a little different than briefed.

In short, you will need regular alignment with the business owner.  And he or she needs to test whether the site meets their requirements and fits their actual process.

How have we managed expected timing issues?

1. We told our business owners in advance what their responsibilities were, such as:

  • Providing us with the information  that we needed to determine the business case and priority of the project
  • Testing
  • Introducing the site to their target audience.

2. We created as many alternative solutions as possible up front, so they could test and compare multiple solutions simultaneously

3. We told them what and how they were expected to test

4. We agreed when they had to schedule time for testing

5. We told them that, after a missed deadline on their part, we could give no guarantees on the timing of final delivery

Especially the last 2 points usually moved the deadline to a later date :-).

How much time did a site configuration actually take?

Of course this varied with priority, complexity and the responsiveness of the business owner. We have delivered a site in 2 days (it was a very important, very urgent project and not too complicated) and CRM-in-a-TeamSite took about 6 months, almost fulltime. That was a very complex configuration, a very important process with a huge business case, and with a business owner and target audience in Australia.
And of course there were projects which took a year or more but those were generally the ones with an “Unwilling” business owner. These sites were often deleted after a year or so, never having been used.

In general, the time we spent “clicking” was a couple of hours, but the total turnaround time about 8 weeks.

What are your experiences?

How have you worked with the business to manage expectations about timing? Your tips are welcome!

The Perils of InfoPath

PerilsInfoPathOur Business Solutions team has not used InfoPath very often. It is really a very cool tool, and I love its transparency, but people often experienced an access denied or other annoying error message that prevented them from working with it. It may have had to do with our customization.
Next to that, some forms can be very complex, especially when you need different views for different people, of  if they take data from other lists or even from other systems.

We have had to refuse support when a customer support form broke down. It had tons of clever functionality built in: conditional notifications, different views and it imported the customer’s name from SAP when the SAP number was entered. The person who had created the form had left the company without any documentation on the setup, so it would have taken a specialist (which we did not have at that time) many hours to figure out how the form worked.

Identical icons.
But there is another danger in InfoPath forms, or rather in the libraries they live in, and especially in SP2003 and SP2007.  Those libraries have  identical icons…and I guess you can tell how this story will unfold. It’s tagged with “Bloopers”…but also with “Lessons”. 🙂

My colleague-who-wanted-to-investigate-the-boundaries-of-Sharepoint (I mentioned him earlier) had a challenging project: creating a quiz in InfoPath format. We could not think of another way to do this 60-question quiz, which had an extensive score calculation built-in that resulted in your preferred Learning Style. The whole Quiz was a manual exercise, and our Learning & Development team could no longer calculate the score by hand because of resource restrictions  They did not want to leave the scoring to the user, so we wanted to see if we could automate it.
All completed forms would be collected in the library, but everyone could only see their own form.
My colleague spent about 10 full days on this form, and after enthusiastic and extensive testing by both parties we could finally mark the project as completed.

A few weeks after sign-off we received an anguished call from the owner. Her intern, who was on a cleaning spree, had deleted the library because it contained no documents. Could we restore it?

Unfortunately we could not, since my colleague had not kept a copy. So he could do it all over again…

What have we learned?
These are the preventive measures we took from that day onwards:

  • We added the text “System List-Do not delete!” or similar text to the description field of every custom-configured or otherwise important list or library we created from that time on.
  • We saved a template of every library or list with complex configuration in the List Template Gallery of the site, and also in our own Team Site
  • At the moment of handover, we created a backup of every site that we  configured (and sometimes also saved the template in our Team Site).

In SharePoint 2010 Microsoft has finally addressed this library icon issue. But if you are working with an older version, be careful!

Form and Document Library with identical icons – SP2007
Forms and Document Library with different icons – SP2010

DoMoreWithSharePoint – Managing your projects

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 Details
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 Details
Priority Information

Technical and maintenance details, for example the way we had built the solution or if any long-term maintenance was expected

Long-term-maintenance information
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.

DoMoreWithSharePoint – Development Process overview

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.

DoMoreWithSharePoint – How to set Priorities

If you are going to leverage your SharePoint-implementation in a systematic way, your team may become very popular :-).
It is therefore be a good idea to define a way to determine the priority for every project upfront. Let me share our approach with you, so you do not have to invent this yourself. (And be aware this is a long post!)

Step 1: Select Dimensions
How to determine priority will be different for every organization, but here are some examples:

* Financial benefits, such as:
-Time saved
-Reduction of IT costs (e.g. legacy applications, licenses or data storage)
-Reduction in paper documents and dvd’s mailed by couriers
-Avoidance of travel

* Size of target audience
* Seniority of Project Owner
* Facilitating company-wide projects like Sustainability, One Company etc.
* Facilitating a certain functional area, such as R&D or Sales
* Time investment of development team
* Etc.

Stick to a few topics which are relevant for your organization and are easy to measure. This whole exercise should be aligned with your business priorities for maximum benefit.

Step 2: Discuss Definitions.
For each dimension you have selected,  check if you have enough information to be able to measure or estimate it quickly. Discuss this with relevant other functions where necessary. You may need to talk to your Finance team and ask them what the average costs per hour per employee are, the average dvd-by-courier or the average costs of 1 GB storage. Use conservative numbers, and one number per dimension, so you can apply these data in a consistent way.
Store these numbers and their source, so they are easily accessible for your team. We have used an InfoPath form to calculate financial benefits with built-in costs per hour/trip/GB etc. which we obtained from our Finance team.

For non-financial data, agree on how you are going to measure or estimate. In hours (time investments), numbers (audience size) or points (seniority), anything goes, as long as it is measurable and applied consistently.

Step 3. Set Scales.
For every dimension you have chosen, you determine the scale. For instance, for  target audience you can use the following 4 point scale. ( 3: highest priority, 0: lowest priority)
3:  Global audience, all employees
2: Audience per part of the world, e.g. North-America, South America,  Europe
1: Country or global functional group
0: Department or other group within one country

But you can also user numbers, e.g.

3: > 10.000 users
2: 1000-10.000 users
1: 100-1000 users
0: < 100 users

Keep the scales consistent for each dimension, e.g. a 3, 4 or 5 point scale, where 0  is lowest and 3,4 or 5 the highest priority.

Step 4. Apply Weighing.
If you think that financial benefits are important, but alignment with company projects is as well, you may want to include a weighing scale. Determine the relative weight of each dimension.

Step 5: Determine Prioritization.
At last, we can determine the priority for each project!

Each project is scored against the agreed dimensions, in the agreed scale, and with the agreed weighing. Add up the scores for each dimension. This will produce a number, which we have called the Benefits Score. Projects with a low Benefits Score will have a lower priority than those with a high Benefits Score.

We sometimes encountered a project that we all felt we had to do, but the Benefits Score did not reflect that. Some examples were a new screensaver (to align with a new internal branding), or a Blog setup for the CEO (which would give our Blog functionality a lot of exposure). In those cases, we had the option to add an “Intangibles Score” to add to the Benefits Score. It may sound like cheating, but we needed it to make sure our team was working on the right projects. We have used it in less than 1% of projects, though.

We have used a SharePoint list to score each project. We used calculated fields to automate the scoring.

Lost? Here’s what we used to calculate the Benefits Score for every project:
4 * Financial Benefits score (=Time saved + Travel costs avoided + documents/dvd’s saved + IT costs avoided)
3 * Target Audience score (the more customer-facing, the higher the priority)
2 * Required time investment score (less time needed > higher priority)
1 * Re-usability score (solutions which would be applicable for all businesses, received the highest score)
1 * Intangibles score (optional)
—————————— +
Benefits Score (between 0 and 33)

Some tips:
• Create a model that fits your organization’s needs and expectations.
• Develop common assumptions that can be consistently measured and applied. This increases credibility, and also makes it easier to prioritize a project.
• Be as objective as possible, focusing on benefits that you can prove by talking to the business.
• Get Business and Finance buy-off on your assumptions and calculations.
• Make it credible – focus on benefits people can relate to and easily understand.

If you are interested, but want some more information or advice for your particular situation, please let me know!

DoMoreWithSharePoint – You need People

In an earlier post I referred to a team to work with the business. Of course you can start out small with a team of 1 and see how demand grows.

It is important to realize that your team members need a special profile. Basically they will need the following – the order in which I present this is by design!

  • A good business sense: you do this to help the business meet their goals, or ease their pain. But your customers may be hesitant, they ask you for a software rather than tell you what they want to achieve or solve, and they have other priorities throughout the year, so knowing much of Team Sites, testing and maintenance is not their primary interest.
  • Process orientation: generally you will be streamlining a process, so it helps to think in process flows, decisions, approvals, information, start and end.
  • Technologically savvy: of course you must know the tools that you have at your disposal. But being an “passionate and accomplished super-user” is usually sufficient.

It is good to keep in mind that these solutions could in theory be made by any Site Owner. But Site Owners are, understandably,  not really interested in learning how to configure a complex site, they are not usability or long-term maintenance experts. So it is more important that your team can think quickly in solutions, than that they know how to create code.

Our full “Job Description”  is available on request.

You will be working with different personalities, which makes it fun! I have worked with someone who only wanted to work with the business, collecting functional requirements and dumping these on his colleague’s desk to configure the site. He brought in many projects, and the business was really happy with him. However, he over-promised on functionality and did not think properly on long-term maintenance, because he did not know the technology well enough. His colleague was swamped with configuration work, had no time to learn how to work with the business himself, and had to find a lot of unpleasant workarounds to meet the given promises.

I have also worked with someone who wanted to know the technology inside out, so every solution was on the very edge of the system’s capabilities. He shared his findings nicely in our Team Site and we learned a great deal from him, even years after he left. His solutions were very popular with the more “techy” Site Owners, but when the Site Owner changed jobs, the successor was not always happy.  And because re-using a solution for another purpose was not a challenge, he was working less efficiently than he could have been.

And myself? I am not an IT-person, so I like to keep things as easy as possible. I also love re-using my own or someone else’s solutions for another purpose. Am I lazy? Perhaps, but I’d rather call it efficient 😉