Monthly Archives: February 2010

Moving on to the implementation phase, some very clear patterns emerged.  From the participants in this stage (N=8), the keywords were training, people and structure.

The strongest theme (from five of the participants) was a need to focus more on the related areas of training, end user adoption, change management and participant involvement.  There was also a specific mention of a desire for more video instruction.

In a contrary to some findings in an earlier stage, one of these respondents also reported that they should have “concentrated more on IT Department involvement.”

Two respondents reported on a need for better structure and processes.  One discovered a need for better processes, “particularly in requirements gathering, development and configuration management.”  One of our inferences at an earlier stage was the benefit of starting with small projects, but the flip side to this approach was discovered by one participant – after purchasing a wiki to address a particular need, they:

 “… then branched out with a few pilot uses, to see what would happen. We intended these to be small experiments, but they have grown a lot more than we expected and really need a bit more structure around them… a support plan would have been a very good idea!”

 Our final participant reported that they should have done:

“Far more research on the product itself, and not be left with some nasty surprises once we got down to detailed planning, especially around a) Information Architecture constraints, and b) mapping business governance to the complex demands of the software.”

There seems to be some paradoxes in adopting collaborative software: more IT involvement or less IT involvement; more structure or less structure. However, there is certainly no paradox in the need to get people involved!  Thus, our common take-out theme also applies to this stage:

• The introduction of collaborative systems takes time, and needs a strong focus on the needs of people.

To this, we can add:

• Ensure that everyone receives training, and is fully engaged in change.
• Be clear on your structure and processes and ensure that what you are doing will meet your needs.

For those at the selection stage (N=6), experiences seemed to be similar to those at the identification stage. Five respondents reported some learnings here – one response was “nil”. The keywords here appear to be: scope, engagement and benefits.

Echoing the previous findings, one respondent commented on the importance of having a clear “scope of requirements… at the beginning of the project”.  In a similar vein, another highlighted the importance of improved “user requirement definition and user engagement”.

Getting into a little more detail, another finding was the need to put some effort into separating the “selection of social software from selection of the document management system”. This may open a number of questions in this field – is it better to get a range of compatible tools from one vendor, or is it better to get the most suitable of each type of tool regardless of vendor, and then attempt to make them work together? A potential question for another survey, perhaps!

In another reflection on the maturity of the market, another respondent found that delaying the project would have been better – the “product space still seems crowded and immature”.

Our final respondent found that there should have been more focus on business benefits during the business case development, showing “how the solution will improve current processes”.

And so our key take-outs at this stage? It appears that we can repeat one from the last stage:

• The introduction of collaborative systems takes time, and needs a strong focus on the needs of people.

… and we can add:

• Be very clear on each part of what you need, and how the parts will work together.
• Be clear on what you expect to happen when you put a new collaborative system into place.

For each stage we asked the question: “What one specific thing would you do differently if you had to do this again?” As the answers were descriptive text, there’s not a lot we can do in the way of pretty graphs here. 

First, we’ll look at the identification stage. All respondents who were engaged in this stage responded (N=7), and six indicated that they had learned something. (For one, it was too early to have gained any learnings.)

Some learning keywords were: people, change, and time.

IT organisations did not fare well at this point, with one respondent baldly stating their learning as: “Don’t get IT involved.” 

There was only one totally positive response, with the respondent happy that the system “did not need IT support”.

An unidentified decision-maker in another organisation also came in for some criticism, where the solution was “selected before the business requirements were determined.”

There was a common thread to the three remaining responses.  One respondent underestimated how time-consuming the project would be, and highlighted that “this is more about organisation, people and change management than it is about technology” (emphasis mine). Another highlighted the need to “specify the criteria for success”.

Our final respondent reported the unenviable need to redo the whole project, due to changes in organisational needs and the “maturity of the market”. This learning was accompanied by a recognition of a need for “more resources to consult and do the analysis”. (Which may be good news for consultants!)

The key takeouts appear to be:

• Collaborative systems require a different approach from IT departments and business decisions makers.
• The introduction of collaborative systems takes time, and needs a strong focus on the needs of people.
• Don’t be afraid to ask for help.

One additional take-out may also be inferred from this – don’t introduce collaborative systems as a “big-bang” project – take small steps, and allow for changes along the way!

The next question addressed the help that the respondents received at each of the four process stages.  The results at this point were rather mixed.  The question allowed multiple selections, so the numbers here indicate that our respondents received help from multiple sources.  (N=7, 6, 8 and 9 respectively again.)

There seems to be a strong indication that most respondents sought help of some type. In general, more help was sought during the earlier stages; but more than half of the respondents have had help at some stage.

The sources of help indicated as “other” in the table included other parts of the respondents’ organisations and vendor-tied consultants at each stage.  Independent consultants were only used during the Implementation stage. (Which may be bad news for independent consultants!)  Some further “other” sources were also used during Selection, Implementation and Operation stages.

The amount of help required here may be an indication that none of this is easy, even for professionals.