We don’t believe that ECM teams are uncommon, but their value and input on the project is commonly not what it could be. Therefore, we are suggesting that not only do you build a team, but you build one that is tactically involved in the entire implementation.

In most organizations, we encounter one of three possible scenarios that motivate ECM. The catalyst for ECM comes from IT, business users, or content managers. In some rare instances, the need for ECM is driven from the top down. In these cases, you are in a great position to achieve success. All too often, an ECM project is just another IT wish-list item and doesn’t get the kind of early visibility and support it needs from the CXO suite. Leadership is key, and the Chief Officer positions can provide support and influence to help with budget and policy change and also make sure that the project is aligned with the organization’s high-level goals and objectives. The Chief Officer should create an ECM Committee made up of key stakeholders and decision makers from the departments that will be adopting the ECM Solution. During the project the committee can address any escalation issues and operational decisions that will be needed from time to time. This takes the pressure off the core ECM Team whenever differing opinions or significant decisions are required. Often these issues center around budgetary, scheduling conflicts or operational changes that need to be addressed.

If IT has initiated the ECM project, it’s usually driven by the concern that because content is not controlled, it poses a security risk to the organization, and because the vast majority of that content is digital, it is identified as an IT security issue. The good news about ECM projects starting this way is that it means IT is already involved. The bad news is that it’s driven by a need to mitigate risk rather than better organization of content. The concepts and desire to secure content do not generally take into consideration the operational efficiencies that the business managers want or the ease of use that ultimately drives high rates of user adoption. Therefore, in most cases when this scenario is unchecked, it results in a partially built system with few ECM methodologies introduced and users that fight the system the whole way because it provides no real benefit to them. IT has a tendency to throw technology and features at the problem without considering how they interact with the user. They also tend to solve a problem and ignore what comes after the initial issue is resolved.

If a business unit, usually Legal or Operations, mandates ECM, they do so from a need both of better content security and of process efficiency. The benefit of this is that there is greater emphasis given to how the system is used and the business needs that it should address. The problem is that, without IT, they are unable to align the theory of what they want with technology. Lack of IT buy-in makes it hard to get a project started and even more difficult to bridge the communication gap between the business needs and technology.

The last scenario, where the content managers drive the ECM project, can be the best from the implementation standpoint but almost as bad as IT when it comes to adoption. Content managers don’t exist in all organizations. They are neither technology focused like the IT group nor are they engaging in the day-to-day LOB activities like the business users. However, they do share IT’s strong need for content security, and they also have a strong desire to tie ECM to business operations. Content managers have a lot to lose with a system that does not work or is not used. And the ECM system certainly improves their ability to manage content. However, they do not always understand what motivates the end user to use the system.

Typically, when ECM projects come about it’s one of the above personae (IT, content manager, or business user) that drives the project. And it’s usually related to some event. For example, IT discovers that content has left the organization. Legal just dealt with a lawsuit where they did not have all the information until the very end. Or a business user is fed up because another lost document has caused lost efforts within their team or department.

It’s great to have a strong motivation for ECM that is framed in problem/solution terms. However, because it’s usually not incorporating disparate groups, things have already gone wrong, and this threatens the success of any enterprise or organization-wide project.

This is why we know it is so important to bring in other groups as soon as ECM is an idea being proposed for your organization. Not only does a team of individuals with different goals bring in ideas to improve the way the ECM system is deployed; it also lays out most if not all the problems up front.

A team of individuals with differing goals and needs builds the most successful ECM solutions, small or large. The decision of building a team is a hard one for organizations for two reasons: time and conflict.

Managers will indicate that time is a compelling reason not to allow individuals to participate in a team that distracts them from their daily responsibilities. There are many situations and ways to address this, and they are all tailored to fit the department or individual. It is important to be creative and key in on the psychology of the person or manager making the objection. For example, if a manager objects to committing resources to be involved in the project up front, you should ask them, “If you are not willing to put the time in to support the project now, are you willing to accept and use the system after it’s implemented?” The results of not putting the time in up front will likely lead to an escalation meeting that outlines a laundry list of reasons why they will not use the ECM system.

Two excellent ways of dealing with this situation are to first identify another individual who does have time and who shares the desired objectives and goals of the project. Have them be a sort of emissary to discuss the project with their peers. Often a common set of issues can be identified and the proper resources can be assigned. Second, you can also spin the time complaint and have handy examples of how they are already wasting time because of operational inefficiencies due to lack of content control. You can point to broken processes, lost documents, and so on. Show them that by committing the resources and the time now, the future results of improved efficiencies will give them more time by utilizing their content properly.

The other reason ECM teams are avoided is conflict. This is a reason that might not be explicitly called out as clearly as the time utilization will be. It is that nagging fear of conflict that might cause project sponsors to hold back on bringing anyone else into the loop. This can be deeply rooted in office politics and bad previous experiences of working on IT-related projects that span the organization. We assure you that this quiet avoidance is just minuscule early on, and you should deal with it head on. After the system is deployed, the conflict will be tenfold, although it might not be as obvious. Users of the new system will express their anger either by being vocal (you can only hope) or by building animosity toward you and your team, which you will never spot but which will reduce your ability to do your job. In the worst case scenario, they will just refuse to use the system. Early conflict is good. Identifying where the problem areas are will allow you to move past them much more quickly and possibly even adjust the system to accommodate.

Building a team will not be an easy task. There will be a time commitment, but the proper time spent will save loads of time for the entire organization after your ECM solution is in production. There will be conflict, and we encourage you to not only expect it but to embrace that conflict early on in the project. The results will be more ownership of the ECM solution by a broader audience, and it will mitigate the naysayers later on. Give everyone a chance to leave their mark, have their voices heard, and have their content management needs met. Now let’s talk about how to pick your ECM team.

You have, either on your own or with direction from someone else, identified a need for a new or improved ECM system. Perhaps you have a few peers who also see the dire need for improved content management, and you are excited to have them join forces with you. You have also identified that the need exists for a more established team. Here are the questions you need to answer:

The size of the team is not exactly proportional to the size of your organization and deployment. We have found that between 5 and 7 members is the average size. However, we have seen successful teams as large as 12. The biggest problem that larger teams face is scheduling and time to value. We define time to value as the total number of calendar days you invest to complete the project before you start realizing positive results. In many cases, when you have too many people involved in the project, it is hard to form consensus and make decisions. This results in analysis paralysis, and the project never gets finished. We find that if you have too few people, say 3 or fewer, the results are more of corroboration between peers and can actually result in animosity developing inside the group due to one strong personality who tends to drive everything. This can also occur outside the group, by creating a perception that people are being left out of the loop. Who is on your team is the next important consideration.

The team should consist of many disparate groups of individuals. A good rule of thumb is to have two individuals representing the implementing group and one individual from each function, organizational unit, or department. In many organizations, this can be an individual who represents similar functions, such as sales and marketing, if they are separate departments, or operations and product. It’s important to select team members who offer the path of least resistance and whom you already know will support the cause and project. We also encourage you to add some detractors at the very beginning. This can be a challenge, and most people avoid it, but it can greatly enhance the diversity of the team. Detractors tend to be pretty vocal, and they can undermine projects by spreading rumors and finding flaws. Put it this way: If you get at least one troublemaker to be a part of the ECM team, you can both resolve their concerns and get their trust. If you accomplish this, they can become a project’s greatest advocate and have a positive impact on everyone else.

The more meetings the team has early in the project’s life cycle the better. Most organizations have a standing weekly meeting on the ECM project. Some organizations set only monthly meetings, and this is not frequent enough. We generally find that these organizations are establishing a team just because they were told to, not because of the strength that frequent meetings can provide. We recommend biweekly or weekly meetings as the normal course of business, and as things progress, you can adjust for holidays and other organizational issues. The benefit of more meetings is that they tend to be easier to consume because they cover less content and therefore take less time. Be as consistent in your meeting schedules as possible, and send reminder emails with the previous week’s meeting notes, noting all team members assigned action items from the previous week and the upcoming agenda or topics. This helps everyone maintain accountability and stay on track, especially in large projects with people who have multiple responsibilities. Other things to consider when scheduling meetings and planning the project are any planned leaves of absence due to vacation, family commitments, training, and so on.

As we said earlier, the team is not just a high-level strategy group; they should also be part of the technical implementation of the system. Implementers are the ones who do the configuration following the design of the system and IA to produce the final system from SharePoint. We know from this book that SharePoint is not an ECM system until its features are formed into one. It’s these individuals who do the work. Implementers join practitioners, who are the heavy users of the system. This will definitely include your content management team, but it should also include heavy users in each individual function.

The reason that two to three of the team members should be a part of the implementation and practitioner groups is so that they can influence and guide practical applications in the team. Teams that discuss high-level concepts are good for getting theory down, but the team needs to quickly dive into both principle and technology details. The teams should be prepared to cover all the details outlined in the ECM stack found in Chapter 2, and Chapter 3, of this book. This means building the IA and designing taxonomies, but not the implementation cases in Chapter 4. Give team members homework, and ask them to engage a subteam or key individuals in their department. Get tangible written results from your team members, and no matter how little feedback you receive, continue to encourage them to participate. We encourage you to offer rewards to encourage the right behavior and celebrate milestones, always giving credit where credit is due. We will cover this in more detail in the next chapter. This enables the team members to take ownership of a piece of the solution. For example, have each team member get a screen shot of his or her functional department’s shared folder structure. Or ask the members to evangelize the concepts of why the system is being built in their department. The bottom line is this: We recommend that you use your team members for the important tactical work of gathering information, selling the benefits of the project, and showing the results of their efforts.

Every organization will have its own meeting style and structure. We strongly encourage organizations to embrace an adaptation to the scrum meeting methodologies. Because ECM teams are less tactical and task oriented than true development scrum, the approach does not work entirely. However, what scrum teaches us is focus and consistency. ECM meetings will be longer, they won’t be held every day, and they will cover more vague and ambiguous topics than a typical scrum meeting. The adaptation we recommend is as follows:

You might elect to present these items as individual team members or have the project manager collect them and moderate each agenda item for the entire team. It’s really a team decision as to how this is accomplished, but we do recommend allowing each team member to take some ownership of sharing his or her own agenda items.

The early meetings will take a different, more flexible, format as the team figures out how to work together and establishes early goals and timelines. But the meetings should quickly take a routine and standard format. Remember that you want to follow standard meeting protocol by setting defined time schedules and keeping the meeting focused, but you also want to balance the meeting with a standard of open and honest communication. Each member of the team has a responsibility to share issues without the fear of being ignored or penalized. Also, be careful not to let one person take over the meetings because people will become disinterested and the project will suffer.

For each member of the ECM team, it is important to clearly define each person’s roles and responsibilities. We start by using a traditional organizational chart to illustrate a reporting and communication structure, as shown in Figure 5-1. Your existing organizational structure might be different, and we show only one department, Accounting, as the end user. You will include the appropriate number of end user resources as you begin your ECM solution design and planning. This will be true of every distinct operational unit in the organization, just substitute Accounting for the appropriate department.

Figure 5-1. Project team org chart.

The most important point to get across here is that the Accounting business unit and the IT Department have equal influence and access to Executive Management. It is important that the project team has both business and technical stakeholders developing the final ECM solution design and IA. Equally important is personal chemistry between these leadership roles, and in the end, they will accomplish more if they have a good dose of mutual respect for one another.

Your initial project scope is most likely focused on the operational pain points in the business. These could be driven by a need to increase revenue or to cut costs around transactional inefficiencies. When evaluating the primary project roles, you should also consider who the people are that are best suited to adopt change and have a positive influence on the project team. SharePoint is usually a high-profile technology, so it’s important to get a good track record for the platform in your organization. Consider other IT projects that have produced good results through strong teamwork. This might not be the greatest operational pain point but might be a great place to start your SharePoint ECM track record. If you can create a quick win and follow best practices for creating your IA and solution design, it will make it more attractive to other parts of the business that want to experience the same results.

The ECM team can use the information in this chapter to establish a strong culture that will help them prepare for the difficult task of managing change and user adoption of the ECM solution. In the next chapter, we will discuss best practices for preparing your organization for the changes that will come with the implementation of your SharePoint ECM solution.