Author Archives: Keith De La Rue

So now we come to the final phase.  This is the stage with the most detailed responses to this question (N=7), and with a number of regrets!  People, support and features are the keywords here.

Again, we have seen the need for better training emerge, along with a recognition of the need to “spend more time on templates and end-user guidance” and to “focus on [the] user base rather than technology”.

From the other side of the coin, there was a recognition of the need to get more support from key management in the earlier stages of the program. One respondent reported that a decision was made by one department in the organisation to ignore the product choice of another department, and select a different, unproven (and inappropriate) product.  This respondent did not have the power to influence the decision.  If both departments had agreed on a selection, the organisation could have saved “several million dollars”.

So far as support in the technological sense was concerned, one respondent stated the need for a new system to be installed in a stable environment, and another reported that a lack of funding had led to low priority hosting support for the project, resulting in poor service levels and prolonged outages (caused by issues unrelated to the chosen collaborative software).  Funding for self-hosting is the desired solution to this.

A couple of respondents saw a need for better choice of features in the systems selected – the full suite of software should have been purchased, not a limited sub-set. For instance, web-cam conferencing should have been included in one case, and blogging and RSS should have been implemented along with the content management software in another.

Finally, a recognition of the need to “place more emphasis on advertising the benefits” was reported.

So our take-outs from this final stage can once more repeat:

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

To which we can add:

• The introduction of collaborative systems needs senior-level support, and recognition of the benefits of appropriate investment.
• Be very clear on the needs of the people who will use the system, and ensure that the appropriate functionality is provided to meet these needs.

And on that note, we draw to a close our analysis of the Australian Collaboration Software Report!  Thanks again to all our respondents.

So what happens now? Watch this space…

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.

At this point in the survey, we branched out into four streams – looking separately at the processes of Identifying, Selecting, Implementing and Operating collaboration software.  In each of these, we asked the question: “What was your satisfaction with the process?”

Given the spread of stages of this evolution that our respondents were engaged in, our backroom statisticians started to swoon at this point of the analysis!  However, even with low numbers in each stage (N=7, 6, 8 and 9 respectively), some patterns did emerge:

It appears that those engaged in the initial stage of identification – with the exception of two extreme outliers – were fairly ambivalent.  Experience was much more evenly spread in the selection stage, but it could be said that in general, the experience during implementation and operation was generally more positive.  However, while there is no complete dissatisfaction after identification, there is also no complete satisfaction after selection.  We will look further into some of the specific experiences in following posts. 

Some general observations of important things to think about at each stage can be summarised as follows:

• Identification – Be clear on what your needs are first.
• Selection – Be clear on what your needs are first.
• Implementation – Make sure everyone is clear on what they are supposed to be doing with it now that you’ve got it.
• Operation – Realise the importance of getting all of the three key things above right the first time.