Category Archives: General

The Problem of Engagement in Social Business

Constellation Research blogged earlier this month about the issues that folks are seeing with social media adoption. Of course, as constellation research says, “People” are at the heart of any technology adoption process. Let’s summarize the info that Constellation provides.

First, Constellation argues that there are five leading barriers to adoption, 1) Poorly defined incentives, 2) Increase in actual effort, 3) Lack of choice in user experience, 4) Indifference to change, and 5) Failure to communicate the urgency.  There is really nothing new here, as these barriers are not unique to social business applications, but are applicable to any software adoption cycle.

Next, Constellation argues that there are five ways to counter these barriers, 1) Adopt gamification strategies, 2) Apply design thinking to transform, 3) Deliver options based on use case, 4) Align to self –interest, and 5) Define the business model shift. There is a little more meat here, so let’s try to pull it off the bone.

First, #1 – adopting gamification strategies. This is certainly all the rage these days. However, is a gamification strategy always a good way to incentivize participation? Definitely not. If a gamification-based incentive strategy is not linked to the need to perform actual work, participation will be perceived by employees as an ‘increase in actual effort’ – one of the barriers that was mentioned above. So, gamification might have a place, but it will not stand alone.

Next, #2 – Applying design thinking to transform. This one is so full of jargon it’s hard to draw out what is meant. However, if the real argument is to recognize that the desired outcome cannot be identified without trial, error, and adjustment (the hallmark of a scenario when design thinking is necessary), then this is clearly true. But it’s also not unique to a social business application implementation.

#3 – Deliver options based on use case. This is theoretically an excellent idea. However, in practice, most software development efforts barely have the budget to create a single, well-performing, interface, let alone multiple well performing ones. However, it is a truism in the mobile age that applications can no longer be PC-centric in their delivery mode.

#4 – Align to self-interest. Now we’re getting somewhere. The best way to maximize adoption of anything, is to appeal to the “what’s in it for me” aspect of the person involved. Really, the five barriers that are mentioned above really all come out of the person’s inability to see what’s in it for them. We’ll come back to this.

Finally, #5 – define the business model shift. This is really just another way to say #4.

So, in reality, barriers to adoption ALL arise from the lack of communicating “what’s in it for me” to the users. And this is the key disconnect between adoption of social media outside the enterprise, and the adoption of social media inside the enterprise. When a person *chooses* to adopt a social media technology outside the context of work, it is just that, a choice, and it is voluntary. The person herself defines what is in it for them, and then chooses to adopt or not. She cannot be compelled, she cannot be forced. She is incentivized to participate by the value that participation brings to her.

In the business social context, the market dynamic is distorted by the fact that participation in enterprise apps can be made mandatory – without the value of the participation being real to the user. This is the source of the barriers identified above, and the force that is attempted to be mitigated by the actions that Constellation recommends. However, the five actions that constellation recommends will simply not work, if actual value is not provided for participation. For instance, gamification strategies do not provide real value for the person involved unless, as Constellation argues, you create tangible and intangible benefits for participating. But is the goal of a social business implementation simple participation? Or is the goal participation with the intention of getting business done more effectively and efficiently? Should I implement software for which I must create new incentives for participation, or should I implement software that is inherently congruent with existing incentives? Should I incentivize people for playing the “game”, or for getting things “done”?

The reality is that social business platform and application adoption strategies like those argued for by Constellation put the cart before the horse. If a technology helps people complete their actual jobs better, and is easy to understand and use, almost every person will see the value to participation and will choose to participate, rather than having to be forced to participate, or cajoled into participation with weak incentives like gift cards, etc.

Social business platforms and applications will no longer have an adoption problem if 1) they integrate real business processes into the platform, so that the platform is the way the process is done, and 2) the new “social” way to do the process is better than the old way of doing things.

How do companies work toward making this the case? First, they create a social platform, and integrate apps into it, so that islands of “social” software do not create impediments to easy enterprise collaboration. Second, they integrate social business applications into the platform to multiply the value of the platform. Finally, they apply social when necessary, and don’t just hit everything with the “social” hammer. Not all processes are best managed using social business applications.

When an organization provides a social business platform and ecosystem that provides value to their employees, participation will not be something that has to be enforced, but will be something that is natural and organic. The kinds of prescriptions in the blog listed above are indicative of organizations that still must “convince” their users that there is value for them in participation – which probably means that there is not.

Advertisements

Social Business Software and Business Performance

McKinsey has published a report that illustrates the relationship between social technology use and organizational performance, with some interesting results. McKinsey looks at organizations as achieving different levels of social networking: developing, internally networked, externally networked, and fully networked. The names are pretty self explanatory.

McKinsey found significant, positive correlations between the presence of social business technologies and business performance. Specifically, they found significantly better performance in companies that are increasing their level of integration of social technologies into day-to-day work year over year.

Even so, of the 3000+ companies surveyed, more than 2400 are still in what is called the “developing” category, and only 110 have reached the state of “fully networked”. Most likely many companies choose to focus on internal or external networking, rather than both, so the small number isn’t that surprising. What is more troubling is the finding that companies are not maintaining positive trajectories in their social business implementations.

McKinsey found that, of the companies that had previously reached some level of networking benefits, over half had lost the previously achieved gains and had slid back to the “developing” category.  While many of the statistics that are in the report are similar across categories, one that is extremely different is the level of integration of the social technology into the every day work of the company. In companies that have reached a level of networking value, at least 45% of the companies reported very high levels of integration into the daily work of the company. In developing companies, that number is only 18%.

This highlights and confirms a point we have made in the past. Social networking platform investments are only the first step. What multiplies the value and usefulness of a social platform is the integration of business processes into the social platform – via technologies like ProjExec.

So, while companies may begin to become networked using platforms, continued and consistent integration of the processes of the business into the social platform of the organization is needed to continue the trajectory of social adoption and value generation.

Social project management is an excellent entry point for social business, and ProjExec is that entry point if you’re on the the IBM Social Business platforms – IBM Connections and the IBM SmartCloud.

ProjExec. Projects. Made Social.

The NYT weighs in on Social Business Software

Well, now that the newspaper of record, the NY Times, has weighed in on social software, we can now say that social software inside the firewall is mainstream. The article, unfortunately, is very shallow, and only serves to reinforce stereotypes about social business.

First, the article focuses most of its attention on Salesforce Chatter, which, while it is a very nice social tool for CRM, is not one of the leaders in social business software (at least according to the Gartner Magic Quadrant, which is always right 🙂 ).

Second, the article focuses strongly on the need to control and filter what is said on social networks inside the firewall. While it is true as the article said that users should take the attitude that “if you don’t want your company president to see it, don’t post it,” realistically most social software users have become well sensitized to the fact that posting on social networks is visible, and most of the anecdotal evidence supports the fact that people behave as professionals on social business platforms – in other words people don’t behave in the same ways on work social networks that they do on Facebook.

Another paragraph of the article states: “For instance, some workers prefer to be “lurkers” who read posts rather than write them. Others are just not interested. At Symantec, the computer security company, a few employees initially disliked the idea of an internal social network, but nevertheless used it to air their complaints.”

This point illustrates our core contention (stated in a previous post) that it is not enough to simply install a social network inside the firewall. Doing so will not provide the incentive to the majority of users to actually adopt the software. What is required is the establishment of reasons to use social software. Please distinguish between reasons to use and rules to use. Reasons to use are things perceived as useful to a user, rules to use are perceived as commands to be obeyed. Which of these two do you believe is more likely to spur real adoption and social emergence in your company. As we have stated before, we believe that social project management is an  excellent reason to use social software, and that it is perceived that way by people naturally.

Giving people reasons to use social networking software means making it part of getting their jobs done. More importantly, it means making it a part of getting their jobs done better than they could otherwise. Any other driver of adoption, whether policy or making it a part of performance evaluation will be seen as compulsion, which is anything but social. Only when you give people reasons to use the software will people stop lurking and stop resisting.

While it is wonderful that the gray lady has recognized the phenomenon of social business software, the story is incomplete. Where are the stories of the benefits of social, the reports of 40, 50, 60% reduction in workflow, the reports of emergent networks of employees who have never met working together to solve business problems before they escalate, etc.? Perhaps the NYT needs to take some direction from Paul Harvey, and seek out the “rest of the story”? We can only help that they will do so in the future.

Social Software and Productivity

There is a lot of buzz about the potential productivity gains of social software. Luiz Benitez tweeted a link to an article on The Province, which described a variety of situations where social software like IBM Connections was leading to perceived productivity gains.

The examples cited in the article noted the increate in productivity that occurs when people are linked together in collaborative communities. But is this really what is new about social software? Online, collaborative communities have been around for a long time.

However, those communities were usually closed, meaning that you had to be a recognized “member” of the community to get a login credential, and these collaborative communities generally failed. Why? We propose that some component of that failure has to do with the centralized control indicative of most enterprise implementations.  Interestingly, this central control paradigm is hinted at in the article referenced above:

Dr. Anne Bourhis “cautioned that social networking isn’t a cure-all. She said businesses need to plan in advance how the tools will be used before they implement a new network, since there are a multitude of tools that serve very different purposes.

“You can’t use it because it’s in fashion,” she said. “You really have to understand what the need is. If it doesn’t meet the need of employees, they won’t use it.”

While we agree with the second paragraph without reservation, the first paragraph is indicative of a non-social, centralized planning approach. What businesses really need to do is to understand how to provide general purpose platforms (like an IBM Connections), along with tailored, initial business contexts through which to introduce the platform. If those tailored entry points are well thought out, the network of users will identify the next wave of uses of the platform, without any input from IT or management.

What is impossible,  once an open, social system is introduced within a business context, is for a centralized planner to predict and manage where the social network will take the software. Business can plan how to introduce the platform, but cannot plan how the tools will be used. If they do so, and restrict the ways the tools “should” be used, the value of the emergent online network will be impaired.

If businesses create an open, social network, where everyone in the organization has access, and where access restrictions are kept to a minimum, the kinds of linkages that are described in the article can take place naturally. This is what is really different about social networking, in comparison to other online collaboration spaces. Rather than “pre-identifying” communities, in social networking contexts, communities emerge in practice, based upon the needs and desires of the users, not a central plan.

This is part of the true value of social networking software in the enterprise – allowing the connections of people in the business to emerge as business requirements dictate, in real time, without IT intervention or management declaration.
This does not mean that it is unimportant for there to be a plan for the introduction of the platform. But that plan should be just that…an introduction, rather than an arranged marriage. That well thought out introduction can blossom in ways no one can anticipate.

Developing Peer-to-Project Communication with Social Project Management

Communications planning on projects takes up a major part of the PMBOK. Because traditional project management is based upon a philosophy of control, project managers are advised to develop and maintain a detailed project communications plan, with important formal communications defined and agreed to by project stakeholders.

Having been involved in scores of projects as a project manager, we have prepared literally thousands of informal and formal communications for stakeholders. However, how many times when we were writing those communications did we think that the stakeholders really valued that information, and that they would really take (have) the time to understand the communications. Rather, we knew that when something was really important (an exception), we would have to call it out with a special communication, that probably was not defined on the project communications plan.

The theory driving the establishment of formal communications planning is network complexity. Who has not seen the image of what happens to communication paths when people are added to projects? Everyone has seen it, but I’ll still link to an image here:

Communication Paths Increase as Staff Number increases

The concept of communications path complexity (peer-to-peer communication)

Basically, as Fred Brooks pointed out in The Mythical Man Month, adding people to a project creates more theoretical communications paths, and therefore more potential communications complexity. Because teams are large and, because the communications challenges within distributed and cross-cultural teams are real, communications control led to the partitioning of communications, with the project manager or several project managers becoming communications hubs, responsible for the filtering and distribution of information in order to limit the complexity of communications across the team, and to attempt to reduce information overload see this article.

However, with the emergence of social project management, and the application of the activity streams paradigm, a new possibility for the management of communications emerges. With the project activity stream, or “project wall”, comes the concept that the project itself is a “member of the project”, with whom other project members can communicate, and who can communicate with other project members. This leads to a new paradigm of project communications, shown in this diagram:

Peer to Project Communication

Communication Paths in Social Project Management (peer-to-project)

Rather than viewing the project as a set of communications paths between individuals (“peer-to-peer” communications), social project management creates the concept of communicating between individuals and the project (we call this “peer-to-project” communication). While project team members will, of course, communicate one on one as necessary, applying the “Facebook” or “Tweet” paradigm to a project, creates a steady stream of information to the project, and from the project to the individuals.

In the diagram above note two specific things. First, ties to projects can be any strength. If a person is dedicated to one project, their ties to that project will be strong. If a person is assigned to multiple projects, their ties may be stronger to some and weaker to others.  (An executive’s ties to projects will generally be weaker than the average project member on any project.)

Rather than having to maintain one communications path with every member of a project team, each member only has to maintain one communications path with each project, and then specific communications paths as necessary. However, if the peer-to-peer communications paths happen outside the project, the rest of the project team is unaware of the communications. Whereas in a collocated team environment, much of this informal human-to-human interaction is processed by individuals as part of the environment, in distributed teams this communication must be made visible through the collaboration system. As much as possible, social project management encourages the use of the system for peer-to-peer AND peer-to-project communications, creating the maximum ambient awareness for the team.

Conceptualizing the addition of a new project member as a new set of communications paths between each member of the project, we can conceptualize the addition of a new project manager as a simply a new peer-to-project path. This new path does not change the other peer-to-project communications, it simply adds another potential source to the communications paths.

Additionally, notice from the diagram that social project management, because it is embedded into the collaboration network of the organization, enables the seamless integration of external network contacts via the social networks of project members.

In a sense, peer-to-project communication with social project management is a publish-subscribe model for project communications. While this concept is somewhat silly when describing collocated teams, it is very applicable to technology-enabled teams. This publish-subscribe + tweet paradigm, where the external social network can be seamlessly integrated into the management of exceptions makes project management social.

Obviously, we believe that the social project phenomenon is significant in its impact on project teams. Whereas Web2.0 enabled the easy establishment of online collaboration spaces,

Social Project Management is Different from Project Management 2.0

Many people use the terms Social Project Management(SPM) and Project Management 2.0 (PM2.0) interchangeably.  Heck, even wikipedia thinks they’re the same thing, but it’s wrong.  While PM 2.0 focused primarily on enabling online collaboration within the team, and to a lesser extent with providing dashboards for reporting, and other basic project management automation, SPM’s focus is fundamentally different.  SPM is focused on connecting the project to the wider social network of an organization or web of organizations to both manage the project and to manage exceptions.  PM2.0 platforms rarely are connected to a wider social network and generally are closed to non-team members.

Because Deloitte stresses the need for social software to manage exceptions, let’s compare SPM and PM2.0 using Deloitte’s framework:

First, social business software helps identify expertise, either via directly querying the social network or by identifying the creators of valuable content.

  • PM2.0 – Most PM2.0 platforms are hosted externally, not integrated with the enterprise systems of a company, and access is supplied only to team members.
  • SPM – Social project management embeds project management into the social platform of the organization.  It allows for project issues to be “broadcast” to the entire social network of the team, rather than being confined within the project team boundaries.  Because of this, important expertise from outside the team can be brought to bear on the team’s issues and opportunities.

Second, social business software breaks down traditional barriers  within companies and across value chains.  Because communication and conversation more seamlessly and extensively crosses organizational boundaries with the aid of social business software, both the communication and awareness of exceptions are more widely disseminated – in sharp contrast to traditional, team-oriented, direct communication paradigms.

  • PM2.0 – Again, because of the fragmented and siloed nature of most PM2.0 platforms, PM2.0 systems reinforce and create boundaries.
  • SPM – Social project management enables communication via the microblogging and re-posting paradigms common to today’s social software platforms.  By disseminating issues widely, SPM provides a true communication advantage over PM2.0

Third, social business software preserves institutional memory, and because the various institutional memory contexts are now integrated into the social platforms, data is now available that allows organizations to analyze and discover issues and opportunities that were previously hidden..

  • PM2.0 – Because PM2.0 systems are many times adopted for projects one at a time, and because even in the same organization multiple PM2.0 platforms may be adopted, institutional memory is replaced by individual memory.
  • SPM – Social project management is all about integration into the social platform of the company.  SPM stores documents and other project information into the social platform, making it part of the larger institutional memory.

PM 2.0 was a great first step into the realm of web project management systems.  However, it was focused on within-team communication and collaboration, and because of this reinforced the team boundary.  Social business software is all about breaking down boundaries and managing exceptions. If your project management system cannot help you to manage exceptions, it’s not a social project management system.  If you’re not managing exceptions, you’re falling behind on your projects.

The Need to Make Work Observable

As work processes and products become more and more heavily focused on knowledge work and knowledge production, work has become less “observable”. Whereas in a physical production environment, the visible work product is the final work product itself, in information and knowledge work, the visible work product is often descriptions of the final work product, namely requirements documentation, specifications, and project plans.

In knowledge teams, a key issue that affects both team performance and the perception of the team by its stakeholders is the observability of “what’s going on” with the project. Too often, status communications are infrequent, untimely, and incomplete, and even within the team, there is uncertainty and confusion as to what is the current status of the project.

Observable work is a term that has been used for several years[1] and which generally defines the ability for an observer to understand the process, progress, and status of a project. Jim McGee and others have noted that as the dominant production paradigm has shifted from craft to industrial to knowledge work, the ability for an external observer to identify the process being used to create, the progress toward completion, and the overall status, including risks, has become difficult[2].

When a person desired to enter a pre-industrial, craft-oriented profession (for example, blacksmith, glazier, or watchmaker), a young apprentice would observe how the master worked, painstakingly learning by mimicking the master, failing to some extent, and then mimicking again. By receiving many small pieces of information the apprentice learned and, over time, became the master. This intense informal feedback allowed learning to occur, and this kind of feedback is what observable work is all about.

In any kind of work, the ability to communicate the what, why and how of what is being done is crucial.  In an observable work stream, this feedback is constant, but in a typical large team or distributed team environment it is missing.  Social Business Applications help to create this stream of constant feedback…more on how they do that in our next post.