Chapter 16: The Four C's

IT staff, skills and style - using this part

This part covers the 'softer' aspects of applying IT to the not-for-profit sector, such as human resources.  It is a mixture of reflective advice and pragmatic tips. Most applies to not-for-profit organisations of all shapes and sizes. The initial chapter, 'The Four Cs', sets out principles which we believe to be extremely important in achieving results when applying IT in any environment.  Similarly, 'Sensible use of consultants' and 'Training and skill transfer' should be useful to all.

People interested in larger not-for-profit organisations should benefit from reading all the chapters in this part.  Chapter 19, 'Outsourcing', is likely to be useful only in organisations large enough to justify dedicated IT staff, although the principles set out in the chapter might apply to outsourcing aspects of your undertakings other than IT.

People interested in smaller and medium-sized not-for-profit organisations might be especially concerned with chapter 20, 'Technophobia and technoscepticism'.  These issues can be crucial, especially if one or two key individuals in a smaller organisation show these characteristics.  However, we believe the message in that chapter to be useful and applicable to all manner of organisations. 

Chapter objectives

In this chapter we shall:

  • Recognise that successful IT in charities is at least as much down to people as it is to technology.
  • Explain the four C's that we believe help people to succeed in their planning, implementation and evaluation of IT: communication, contribution, consensus and commitment.
  • Emphasise the need to document your C's.
  • Provide some tips and techniques to help you use those four C's.

The human touch

We have described earlier the benefits of communicating and gathering contributions from your people when planning IT and when procuring systems.  Despite the increasing importance of information technology, not-for-profit organisations are (and will continue to be) essentially people businesses.  In fact, all organisations, especially service-based organisations are people businesses. 

Further, however good your IT systems and structure might be, it is unlikely to deliver the benefits you hoped for unless your people have both the skills and the motivation to deliver the benefits.  Or put another way, if there is an absence of motivation it is extremely unlikely that an IT project will succeed.

We believe that the motivation to deliver benefits, i.e. commitment to any IT project or initiative, stems from:

  • communication with people about the project or initiative;
  • gathering contributions from those people at the planning, implementation and evaluation stages;
  • trying to build consensus on the appropriate course of action.

This is not a naive view that not-for-profit organisations can please all the people all the time with IT projects, but an application of wide experience that says that a sensible level of engagement with people who will be affected by IT projects significantly increases the prospects of success.

Document as you go

Personnel changes often have adverse effects on IT projects, both from the skills and motivation point of view.  Your project will have a skills gap just at the vital time.  Further, new people coming in, having not been involved in the initial communications and contributions, can take a negative attitude to the project.  "Not invented here" manifests itself in phrases such as "well I wouldn't have done it this way".  One way to minimise these risks is to make sure you document your work as you go.  It is harder (though not impossible) for the "newbie" to be ultra critical of the decisions made if there is evidence that they have been clearly thought through and agreed by consensus.  Although such documentation is not quite the same thing as having been involved in the process, it does help people to buy in part way through.  Further, such documentation should help the newbie to get up to speed that much quicker.  It is worth investing time in face-to-face briefing and discussion with new people who will have key roles in projects, to let them air any concerns and to ensure understanding through dialog.

On any project or venture, especially if it is IT related, you should periodically ask yourself the question "if [so and so] fell under a bus tomorrow, would anyone be able to see this project through?"  If the answer is no, you probably need "so and so" to document what they are doing more thoroughly and possibly ought to ensure that someone else works with "so and so" sufficiently to be able to provide some cover if the worst happens. 

Where do I start to be a good four C's player?

The table below sets out a checklist of communication, contribution and consensus activities which you should think about for each project. 

Table 19.1 Communication Contribution and Consensus Checklist
Project Stage Communication Contribution Consensus
Plan ("Think and Tell") have you alerted all relevant people to the IT project idea?
have you formulated a communication plan for the ensuing project?
have you consulted with people who will be directly affected by the IT project idea?
have you consulted with a sample of those who will be indirectly affected?
have you documented that consultation?
have you allowed a proper airing for alternative proposals?
have you ensured that a suitable proportion of people agree with the proposal?
have you documented those debates, including options you have considered but rejected?
Implement ("Act") are you communicating regularly about this IT project (e.g. newsletters, global e-mails, briefings)?
are you taking steps to gauge the effectiveness of your communication?
are you getting contributions from people for the project as planned?
are new people being included in the contribution plan?
is there a mechanism for wider contributions (e.g. feedback questionnaires)?
is there a mechanism for error logging, complaints and suggestions?
have you set up mechanisms for shared learning (e.g. meetings, bulletin boards)?
Evaluate ("Improve and Share") are you "publishing" (internally) the results of and comments on the project?
Have you considered wider publication (beyond your organisation)?
has “customer satisfaction” been assessed (e.g. through questionnaire, evaluation meeting or call)?
have you conducted a post implementation review?
have you publicised the results of these evaluations
are shared learning mechanisms being used by users?
have you set up channels for “where do we go from here” dialog?
are you sure people have been told how to share their knowledge?


  • IT projects are far more likely to succeed with committed people;
  • communication, contribution and consensus usually lead to commitment;
  • document your activities as you go to maximise your chances of success even if key people on the project change part way through.