What can team managers in big companies learn from small businesses? Quite a bit actually. I recently wrote a guest post for Wayne Turmel’s bnet column. Here’s an excerpt:

Phil, what’s the difference between how small businesses approach technology (especially collaboration tools) and the traditional enterprise approach?

In a nutshell, small businesses (SBs) tend to experiment more. They’ll try out a tool like Yammer, for example, on an individual basis. If it catches on, it will be adopted throughout the company. It’s less “top-down” than the traditional enterprise approach. What’s more, if something else comes along that offers superior functionality, SBs will experiment with that tool as well, utilizing what’s best from each. There’s no corporate edict that “all people must use X” even though X doesn’t have key functionality.

To read the rest of the post, click here.

I recently read Jacob Morgan’s excellent post, Does Collaboration Impact Business Performance? Morgan reviews an updated Frost and Sullivan report that assesses impact of collaboration on overall business performance. (To read the entire report, click here.) In a nutshell, collaboration is catching on. Big time.

Reactions

The report has its limitations. As Morgan writes, “keep in mind that this (report) only speaks to tool deployment and says nothing about strategy, results, adoption, or effectiveness.”

Very true. Go back 15 years and think about the number of companies doing ERP, BI, or CRM. That didn’t mean that they were implementing and utilizing these technologies well. In fact, many of these projects were suboptimal, at best. Also, it’s interesting how The Great Recession has spurred adoption of some emerging technologies. Often, organizations and people only do things when essentially forced. This has always been the case.

Note the introduction (at least to me) of the term ROC: Return on Collaboration. This could be both very important and very amorphous, rife with unrealistic or undocumented discussions. It will be interesting to see if ROC catches on.

Perhaps the most shocking revelation from the report is the breakdown of collaborators by function. It is here that I’ll go off on a Dennis Miller-type rant. (He’s always been one of my favorite comedians.)

See Figure 5 from the report:

Simon Says

Now, one report certainly does not reflect every HR function at every organization at every industry. Without debating the methodology, data collection, and analysis of the Frost & Sullivan report, HR’s position relative to other functions appears to be appalling. HR should be at the forefront of collaborative technologies, not trailing the pack. To the extent that HR is still intimately involved in the hiring process for many key positions most organizations, how can HR successfully weed out “posers” if it barely uses such important tools? Look at the other functions in the graph. It’s extremely clear that R&D, Sales, etc. all value collaborative tools. HR just doesn’t get it.

Beyond that, I’d also argue that largely ignoring collaborative tools does a number of other inimical things:

• Increases the chances that a new hire is unfamiliar with both specific collaboration tools and, more important, a related mindset.
• Decreases the trust that line management has in HR as a function (as well as individual employees).
• Reinforces HR’s traditional role as the Personnel department and not a truly important partner.

It’s high time that you get on board the Enterprise 2.0 train, HR.

To quote Mr. Miller, “Of course, that’s just my opinion. I could be wrong.”

Am I?

Check out the bottom of the site that you are reading. The WordPress plug-in from Wibya allows for easy collaboration and a whole host of other features. It’s very simple to add chat, translation, and social networking functionality (and a bunch of other incredibly cool stuff) to your site.

I was amazed at the translation with one click, make possible via Google.

This is just sick.

Photo by frischmilch

Social networking is one hot topic these days. Many people at least partially understand how to use social networking tools on a personal level. However, fewer are sure about what–if anything–these tools can do at work. Many people wonder if they should even be on Facebook, Twitter, or LinkedIn while on company time.

I spent a decent amount of time discussing this topic with interviewees for my third book, The New Small. After extensive conversions a whole host of interesting folks, I have reached one less-than-revolutionary conclusion:

Many largely unanswered questions remain about social networking in the workplace. But we are starting to answer them.

So, in this post, I’d like to ask share with you what I have learned.

What’s the value proposition of social networking in the workplace?

At a high level, social networking tools allow organizations to improve communication and productivity among employees. Possible soon-to-be buzzword alert: Collaboration is one word that we’re hearing quite a bit. More efficient platforms allow for information to be disseminated among disparate groups of employees. Communication with vendors and suppliers is also enhanced.

Is there a formula for successfully implementing social networking tools?

No. Let’s be clear here: One size does not fit all. In other words, the benefits of these social networking apps and tools vary on the the following:

• the type of app deployed
• specific features
• end-users’ familiarity with Web 2.0 tools
• the organization itself
• a host of other “people-related” factors

Fine. I get it. You’re clearly not in sales. What potential benefits can social networking tools provide?

With that disclaimer out of the way, social networking tools can help organizations and their end users by doing the following:

• Preventing overloaded email inboxes
• Allowing more open communication filtered by relevance. This leads to enhanced information discovery and, ultimately, knowledge.
• Allowing employees to answer previously answered questions–and search those answers.
• Allow employees to discuss ideas, post news, ask questions, and easily share links with one another.
• Organizations can tap into knowledgeable resources throughout the company.

Are these tools being rolled out in a manner similar to previous IT projects?

Not always. Most organizations have traditionally rolled out software from using a top-down approach. This is particularly big corporations. In the past, the IT department purchased enterprise software, often with some input from the lines of business (LOBs).  Many organizations purchased software as follows:

• key internal players and departments looked at feature lists for different vendors’ products
• IT ensured that these products were safe and secure
• Often with the help of consultants, IT rolled them out only to find that nobody used them–or at least not optimally

Social networking is different because many products are based on a freemium model. Free trials enable employees to decide what product they want to use before organizations write large checks to software vendors. Rather than the top-down approach, new products can spread organically within organizations for one simple reason: employees already enjoy using them. This approach makes the purchasing decision much easier for IT. Basically, IT merely has to ensure that the product is safe and secure. IT knows that the employees already want the product, as evinced by their levels of adoption and engagement. In short, the purchasing challenge is not as significant now. Adoption of the new tool is less uncertain.

What are some of the most common mistakes that organizations make implementing social networking tools?

I actually addressed this a while back in a previous post. To recap, I’d cite three main mistakes. First, organizations often fail to implement usage policies that establish a clear set of guidelines. Second, without encouragement, training, and guidelines, employees are sometimes scared to use new apps and tools. Other times, employees are confused about how these new tools work. Third, old habits die hard. Many people will continue to rely on what they know: email and voice mail. Organizations need to wean themselves from long, drawn-out email chains and encourage people to embrace new ways of doing things.

Ding ding….

A “blog-bout” is a good-natured debate between two bloggers.  This blog-bout is between Jim Harris and Phil Simon, where they debate which board game is the better metaphor for an Information Technology (IT) project: “Risk” or “Monopoly.”

Why “Monopoly” is a better metaphor for an IT Project

By Phil Simon

IT projects and Monopoly have a great deal in common.  I thought long and hard about this at the gym, the source of all of my great thinking.  I came up with six really smashing reasons.

1. Both things take much longer than originally expected.

IT projects typically take much longer than expected for a wide variety of reasons.  Rare is the project that finishes on time (with expected functionality delivered).

The same holds true for Monopoly.  Remember when you were a kid and you wanted to play a quick game?  Now, I consider the term “a quick game of Monopoly” to be the very definition of an oxymoron.  You’d better block off about four to six hours for a proper game.  Unforeseen complexities will doubtlessly delay even the best intentions.

2. During both endeavors, screaming matches typically erupt.

Many projects become tense.  I remember one in which two participants nearly came to blows.  Most projects have key players engage in very heated debates over strategic vision and execution.

With Monopoly, especially after the properties are divvied up, players scream and yell over what constitutes a “fair” deal.  “What do you mean Boardwalk for Ventnor Avenue and Pennsylvania Railroad isn’t reasonable?  IT’S COMPLETELY FAIR!”  Debates like this are the rule, not the exception.

3. While the basic rules may be the same, different people play by different rules.

The vast majority of projects on which I have worked have had the usual suspects: steering committees, executive sponsors, PMOs, different stages of testing, and ultimately system activation.  However, different organizations often try to do things in vastly different ways.  For example, on two similar projects in different organizations, you are likely to find differences with respect to:

• the number of internal and external folks assigned to a project
• the project’s timeline and budget
• project objectives

By the same token, people play Monopoly in somewhat different ways.  Many don’t know about the auction rule.  Others replenish Free Parking with a new $500 bill after someone lands on it.  Also, many people disregard altogether the property assessment card while sticklers like me assess penalties when that vaunted red card appears.

4. Personal relationships can largely determine the outcome in both.

Negotiation is key on IT projects.  Clients negotiate rates, prices, and responsibilities with consulting vendors and/or software vendors.

In Monopoly, personal rivalries play a big part in who makes a deal with whom.  Often players chime in (uninvited, of course) with their opinions on potential deals, without a doubt to affect the outcome.

5. Little things really matter, especially at the end.

Towards the end of an IT project, snakes in the woodwork often come out to bite people when they least expect it.  A tightly staffed or planned project may not be able to withstand a relatively minor problem, especially if the go-live date is non-negotiable.

In Monopoly, the same holds true.  Laugh all you want when your opponent builds hotels on Mediterranean Avenue and Baltic Avenue, but at the end of the game those $250 and $450 charges can really hurt, especially when you’re low on cash.

6. Many times, each does not end; it is merely abandoned.

A good percentage of projects have their plugs pulled prior to completion.  A CIO may become tired with an interminable project and decide to simply end it before costs skyrocket even further.

I’d say that about half of the Monopoly games that I’ve played in the last fifteen years have also been called by “executive decision.”  The writing is on the board, as 1 a.m. rolls around and only two players remain.  Often player X simply cedes the game to player Y.

Why “Risk” is a better metaphor for an IT Project

By Jim Harris

IT projects and Risk have a great deal in common.  I thought long and hard about this while screaming obscenities and watching professional sports on television, the source of all of my great thinking.  I came up with five world dominating reasons.

1. Both things start with the players marking their territory.

In Risk, the game begins with the players placing their “armies” on the territories they will initially occupy.  On IT projects, the different groups within the organization will initially claim their turf.

Please note that the term “Information Technology” is being used in a general sense to describe a project (e.g. Data Quality, Master Data Management, etc.) and should not be confused with the IT group within an organization.  At a very high level, the Business and IT are the internal groups representing the business and technical stakeholders on a project.

The Business usually owns the data and understands its meaning and use in the day-to-day operation of the enterprise.  IT usually owns the hardware and software infrastructure of the enterprise’s technical architecture.

Both groups can claim they are only responsible for what they own, resist collaborating with the “other side” and therefore create organizational barriers as fiercely defended as the continental borders of Europe and Asia in Risk.

2. In both, there are many competing strategies.

In Risk, the official rules of the game include some basic strategies and over the years many players have developed their own fool-proof plans to guarantee victory.  Some strategies advocate focusing on controlling entire continents, while others advise fortifying your borders by invading and occupying neighboring territories.  And my blog-bout competitor Phil Simon half-jokingly claims that the key to winning Risk is securing the island nation of Madagascar.

On IT projects, you often hear a lot of buzzwords and strategies bandied about, such as Lean, Agile, Six Sigma, and Kaizen, to name but a few.  Please understand – I am an advocate for methodology and best practices, and there are certainly many excellent frameworks out there, including the paradigms I just mentioned.

However, a general problem that I have with most frameworks is their tendency to adopt a one-size-fits-all strategy, which I believe is an approach that is doomed to fail.  Any implemented framework must be customized to adapt to an organization’s unique culture.

In part, this is necessary because implementing changes of any kind will be met with initial resistance, but an attempt at forcing a one-size-fits-all approach almost sends a message to the organization that everything they are currently doing is wrong, which will of course only increase the resistance to change.

Starting with a framework simply provides a reference of best practices and recommended options of what has worked on successful IT projects.  The framework should be reviewed in order to determine what can be learned from it and to select what will work in the current environment and what simply won’t.

3. Pyrrhic victories are common during both endeavors.

In Risk, sacrificing everything to win a single battle or to defend your favorite territory can ultimately lead you to lose the war.  Political fiefdoms can undermine what could otherwise have been a successful IT project.  Do not underestimate the unique challenges of your corporate culture.

Obviously, business, technical and data issues will all come up from time to time, and there will likely be disagreements regarding how these issues should be prioritized.  Some issues will likely affect certain stakeholders more than others.

Keeping data and technology aligned with business processes requires getting people aligned and free to communicate their concerns.  Coordinating discussions with all of the stakeholders and maintaining open communication can prevent a Pyrrhic victory for one stakeholder causing the overall project to fail.

4. Alliances are the key to true victory.

In Risk, it is common for players to form alliances by combining their resources and coordinating their efforts in order to defend their shared borders or to eliminate a common enemy.

On IT projects, knowledge about data, business processes and supporting technology are spread throughout the organization.  Neither the Business nor IT alone has all of the necessary information required to achieve success.

Successful projects are driven by an executive management mandate for the Business and IT to forge an alliance of ongoing and iterative collaboration throughout the entire project.

5. The outcomes of both are too often left to chance.

IT projects are complex, time-consuming, and expensive enterprise initiatives.  Success requires people taking on the challenge united by collaboration, guided by an effective methodology, and implementing a solution using powerful technology.

But the complexity of an IT project can sometimes work against your best intentions.  It is easy to get pulled into the mechanics of documenting the business requirements and functional specifications, drafting the project plan and then charging ahead on the common mantra: “We planned the work, now we work the plan.”

Once an IT project achieves some momentum, it can take on a life of its own and the focus becomes more and more about making progress against the tasks in the project plan, and less and less on the project’s actual business goals.  Typically, this leads to another all too common mantra: “Code it, test it, implement it into production, and then declare victory.”

In Risk, the outcomes are literally determined by a roll of the dice.  If you allow your IT project to lose sight of its business goals, then you treat it like a game of chance.  And to paraphrase Albert Einstein:

“Do not play dice with IT Projects.”

You are the Referee

All bouts require a referee.  Blog-bouts are refereed by the readers.  Therefore, please cast your vote in the poll and also weigh in on this debate by sharing your thoughts by posting a comment below.  Since a blog-bout is co-posted, your comments will be copied (with full attribution) into the comments section of both of the blogs co-hosting this blog-bout.

About Jim Harris

Jim Harris is the Blogger-in-Chief at Obsessive-Compulsive Data Quality (OCDQ), which is an independent blog offering a vendor-neutral perspective on data quality.  Jim is also an independent consultant, speaker, writer and blogger with over 15 years of professional services and application development experience in data quality (DQ), data integration, data warehousing (DW), business intelligence (BI), customer data integration (CDI), and master data management (MDM).  Jim is also a contributing writer to Data Quality Pro, the leading online magazine and community resource dedicated to data quality professionals.

• Connect with Jim Harris on LinkedIn
• Follow Jim Harris on Twitter
• Friend Jim Harris on Facebook

About Phil Simon

Phil Simon is the author of the acclaimed book Why New Systems Fail: Theory and Practice Collide and the highly anticipated upcoming book The Next Wave of Technologies: Opportunities from Chaos.  Phil is also an independent systems consultant and a dynamic public speaker for hire focusing on how organizations use technology.  Phil also writes for a number of technology media outlets, and blogs on his Virtual Soap Box.

• Connect with Phil Simon on LinkedIn
• Follow Phil Simon on Twitter
• Friend Phil Simon on Facebook

• facilitate document sharing and updating
• improve intra-team communication
• rid the organization of its dependency on email

Collectively, these collaborative tools can improve project management. Through their successful and consistent usage, the organization can improve its chances of achieving its goal: a smoothly run project.

Sounds good in theory, right? Unfortunately, many times the promise of these tools is far greater than their actual benefits. (This is also true of Enterprise 2.0 in general.)

But why is this the case?  I’d offer two simple and related reasons:

• Collaborative tools are only as good as the people who use them
• Old habits (read: email) die hard

Email may be the Internet’s first killer app, as project-related messages convey important information about tasks, dates, and news. From a collaborative standpoint, there are a few major problems with email:

• Emails can easily make the content on a wiki dated or even irrelevant
• Emails tend to be much less easier to find and search than content posted on wikis
• People constantly forget to copy others on email
• Most emails are downloaded to individual PCs, making them suboptimal for future reference

To be certain, wikis will never obviate the need for emails. What’s more, not every piece of information on a project should be posted on a wiki. “Hey Vince, didn’t you think that Nikki sounded like an idiot during the meeting today?” However, emails should constantly reference collaborative sites to reinforce the notion that the wiki governs the project, not 100 disparate emails.

Solutions

Organizations should take the following steps to ensure the optimal use of collaborative tools:

Start at the top

The PM or project leader sets the tone for the entire group. It’s hard to expect individual end-users to move from emails to wikis when the PM doesn’t lead by example. This type of leadership also includes making gentle suggestions to those who rely on email or—perish the thought—don’t update their documents anywhere.

Hold team members accountable for updates on wikis

Individual end-users must use collaborative tools consistently throughout the project. This goes beyond updating their own availability or progress. If the organization uses SharePoint, for example, then it needs to be the epicenter of the project. Unless the material is confidential or politically sensitive, all project plans, test scripts, requirements, and training materials need to go on the wiki. Period.

Cross-reference wikis in emails

Today, many people now routinely read email via BlackBerrys, iPhones, and other mobile devices. This isn’t changing anytime soon. To that extent, expecting everyone to abandon email simply is folly. However, emails should contain URLs to the same content on wikis. Doing so will help minimize conflicting or missing information.