Skeptology

Project management is about managing interests, not simply timelines and resources.

So my former employer is now a year behind schedule on their shared services project, and a cool $250 million overbudget.  Obviously they were right, they didn't need my help. Not that it would have made any difference, but I did try to explain to them that managing projects - at the highest level - was a matter of managing interests, not schedules or resources.  Of course it turned out that it was in the interests of just about everyone who had executive level control over the project to make it go on for as long as, and cost as much as, possible.  My prediction is that they'll give up trying to centralise all Government processing within the next twelve months, hand out the software (in whatever state it happens to be at the time) to the Agencies who have watched another 'fond hope' rise and fall, and call it a rip-roaring success.  After a year or so the Agencies will ditch the software when they find the cost of having it modified is 'too high' compared to other 'off the shelf ' products and we will have gone full circle.  Was there, is there another way?  Of course, but nobody is paying me for opinions these days so they can go - and I think this is the expression - 'whistle Dixie'.  Am I being just a little bitter?  Heck yes, but I feel better now.   Well enough in any case to make this observation:

The answer now lies in language, not 'product', and certainly not performance.  So where the Government proposed to 'roll in' agencies into this central processing unit, they should now start talking about 'rolling out' the technology (and the 'capability') to the agencies.  A slight change in nuance, and if you look at the post in this blog about 'anticipating organisational death', you'll see it's really just a matter of 'bringing the schedule forward'.  It's not too late to 'take control' of the train wreck, by steering it 'home' (back to the Agencies where Agency IT staff at least have a chance of knocking it into shape) rather than allowing it to run out of steam somewhere in the wilderness. In fact there's a certain poetic beauty in the concept of giving the unwanted child back to the Agencies and saying, 'you look after it now'.  And of course if it fails it's then due to Agency neglect, not failure of 'concept'.

The beauty of having an 'Organisational Death Plan' (in this case to centralise the systems and the 'best practice', then refine it, then hand it back to the Agencies as a fully automated system that line and production managers could use directly (with fewer HR and Finance people needed to 'translate' and act as intermediaries)) is that it would have made it possible to make the current situation (and my 'rolling-out' concept) 'look' like it was anticipated, and that we were in fact 'on track' (indeed ahead of schedule!) - and that we had some notion of what that track was and where it was heading.  And of course it then becomes more than 'just' language, but in fact a 'workable plan', because the consumers of the language are not just the anxious public and politicians, but the people who have to implement and use the systems.

A little additional nicety is that the 'rolling out' will of course be accompanied by the return of some funding to the Agencies (that was taken from them in order to fund the Central Agency).  But of course the money 'handed back' will be less than the money taken away, because the system returned to the Agency will now incorporate 'improvements and streamlining' that didn't exist in their 'old' separate Agency systems.  A saving!  For the first time in the history of the project.  And of course the Agencies will be charged with making 'further refinements' to the system, but no additional resource will be provided for that.  And if the Government wants to be particularly cunning, it would make each Agency responsible for some particular aspect of the refinement, so that all of the other Agencies (waiting for that particular refinement) would provide the pressure on the sponsoring Agency 'to get the job done'.  Heck, real  motivation - and that might again be a 'first' again for the project.

Ah, but no mention of roll-back, that would be too unfortunate.

Issues in Technology Management - Influence (Part 1)

I was over on the Tech Republic website where 'Local Support' made a good point - it's not just the subordinate staff in a Manager's section that have a chance to educate him or her 'from below'.  The IT support people have unique access to just about everyone in an organisation. In fact the only people who don't have respect for a really good IT support person would be the propeller heads in the IT specialist areas.

So what does a good IT support person 'do' with this access. Obviously you're there to help solve problems. But the access, the respect that you have allows you to 'influence' things here and there, connect people together, make a suggestion, give an opinion. All done very carefully, the more precise or 'strong' you are in your views the more likely that you'll bump into resistance (and be wrong!). And being 'wrong' means you lose the respect and the ability to influence.

Let's use an example, say a system that the staff are having a lot of trouble using (because it was badly designed). The manager is blissfully unaware of course (none of his own staff will tell him bad news), and the senior ranks of IT know but won't admit they've got a 'dog' on their hands (and after all, the support guys will 'fix it up') and if anyone has the guts to tell the Executive they won't want to know that they've just wasted a large sum of money. So who can tell the manager - well obviously the IT support guy. How? Well you could say, next time the Manager needs some support,"I can't come down now because I'm busy fixing the problems with that XXX system". Ok, but this is better: "I'll come down straight away, I have a heap of work to do with problems with that XXX system and this will be a chance to deal with them all at once.

IT support people might be the 'lowest rung' in the IT ladder, and looked down upon by folk who ought to know better .  But it's not altogether a bad thing.  It's not just the technology or the fact that you 'service everyone'  that gives you access within the organisation but also your 'low status'.  Managers and staff will confide in you because you 'don't matter' (well not in the sense of competing with them for promotion).  But a cat - as they say - may look at a King, and tell him a tale or two about 'what's really going on'. And the manager (and this was the point of the post originally) might learn that it's possible to manage a section and have no idea of what's going on until he/she's told by a 'most unlikely source'.

Issues in Technology Management - Learning from your staff

Otherwise known as 'your people', or 'your team', or sometimes simply as 'our team' depending upon how heirarchical your approach is.   Setting aside the issue of how technology teams and heirarchies arrange themselves (another post another day) the thing that interests me is to what degree managers, circumstances or staff conspire to 'educate' managers to be better managers.  Or to what degree they don't.  And whether it is possible to improve the chance of that education happening, and the quality of the outcome.

I think we can start from the premise that while many managers are 'born to lead' most of us have had to learn 'along the way'.  We learn (those 'qualities of a good manager' ) from our peers and through formal training.  What interests me (and its usually only the non-obvious that interests me) is to what extent we (managers) learn from the people we are supposed to 'lead' or 'manage' and (as a slight detour) to what degree we use referential experience (that's to say 'borrow' from our experience outside our work life) and how well that works. 

Talking about learning from your own people also makes wonder about the ways that might occur, whether its through people 'telling us directly' or 'leading by example' or though 'telling stories' that illuminate things for us even though the connection is 'not immediately obvious', or simply by things that they do (or refuse to do).  It seems, as you consider the channels by which this learning might occur that you could increase the likelihood of it occurring (which is something I wasn't convinced of when I started this train of thought).  Of course any of this requires that you are already 'sensitive' enough as a manager to notice when your staff defy you or shout at you, and humble enough to take it as a 'enlightenment opportunity' rather than a declaration of war. 

I think I'll let this concept sit for a while and see what grows out of it, and thank my colleague for the perfect enlightenment moment out of which this concept grew.   

Concepts in Security Management: Invisible Organisations

If setting up firewalls, and undertaking hugely expensive and complicated processes for managing security in an organisation are considered acceptable and inevitable parts of operating in the world today, to what degree should organisations consider simply making themselves invisible?

Of course its a nonsense to suggest that a business could operate commercially without having a visible entry point for comms, both electronic and old-mail.  But I'm not talking about making yourself invisible in that world.   I'm talking about the building you operate from, and considering physical threats against it, the facilities contained within, the public utilities that service it, and not least your staff.  If you don't have walk-up customers, don't offer facilities to the public, and have relatively few in or out-bound freight events, then why would you advertise where you are located?  If you make yourself harder to find you make yourself harder to target by folk who are into old fashioned terrorism (bombs, guns and hazardous substances).

What you are left with is an argument between using your building as a 'monumental' advertisement on one hand, or increasing security (marginally because a dedicated terrorist will still find you) on the other.  The advertisement argument virtually disappears if you happen to be a back end processing organisation servicing a 'captured' or limited market.  But would it make a significant difference to security?  Well perhaps 'a little', particularly if the terrorist isn't so much someone planning to cripple your business, but one who is looking for an 'easy' target, or for one which resonates with the public.

So if you are a back end office that doesn't need to advertise, the answer might be not to make it too easy to find you, and don't resonate with the public consciousness.  Put a mailing address rather than a street address in the phone book and on your correspondence, don't put a picture of your building on your website and don't put a big sign out the front.   And certainly don't try and create a powerful public image that includes concepts of  extreme size, singularity, or extreme aggregation For example:

• World's (or UK's or whatever) biggest xyz
• World's only xyz, or
• XYZ service provider to all of Government/Industry.

And if you're not a back end processing office, you might still consider some of these methods of just taking your visibility down a notch or two.  Oh, and you might check out who lives next door.  We live in interesting times, and a little paranoia doesn't go astray. 

Component Security Certification: System User Certification

Whenever we control system users access by assigning (or holding back) permissions, we are effectively 'certifying' their IT security status.  If we don't have a single document (literally a certificate) that describes the sum of all of a particular persons 'permissions', we have the equivalent recorded in various systems.   System User Access Control could then be otherwise described as System User Certification.  As system users are as much components of the IT environment as applications or hardware, it would be fair to say that System User Certification could be called a type of Component Security Certification.

So far then we've tentatively accepted that we can use a new name to describe a thing that we are already familiar with; does this improve our System User Certification process?    I have to admit that the 'benefit' mostly flows the other way.  I am hoping to give some 'respectability to the concept of 'Component Security Certification' and to suggest that certifying Computer Applications and Computer Hardware as 'security compliant' is as important as certifying System Users.

Call Centres: Understanding Relationship Flows

In a previous post I suggested that the key to understanding what went on in call centres was understanding the relationships between all of the various parties involved in the call centre.  I explained that I was using the term relationship in the widest possible context, such that we attempted to understand the interests and motives of all of the parties, as well as understanding how they characteristically interacted.  I noted that traditionally we tend to focus on the interaction between the caller and the call centre operator and the systems that facilitate and record the details of that call.  I suggested an interest in this aspect of the relationship was important, but we'd be doing ourselves a disservice if we didn't include the 'bigger picture'.

To save boring you with a long discussion about the evolution of call centres and how they are shaped as much by the 'players' as they are by their designers and managers, let me start with an example.  This situation is typical of a call centres servicing external clients that has reached what I'd call 'mid life'.  It is reasonably successful, but usually seems to to be 'stuck', with no ability to further improve services.  An analysis of the workflows shows that 80% of calls received from clients are resolved 'on-the-spot' by the call centre.  The clients have quite a high regard for the call centre, but this high regard isn't particularly visible to the managers of the client organisation, or to the managers of the organisation that hosts the call centre.  Another workflow, the 20% of calls that can not be resolved 'on-the-spot', proceeds from the call centre to 'other' areas within the call centre host organisation.  These are generally the more complex and difficult (even awkward) jobs.  The recipients of this work generally do not hold the call centre in high regard.   This diagram illustrates some of these flows (click on the diagram for a 'readable' version):

What does an understanding of this relationship; Client-Call Centre-Call Centre Host Organisation suggest?  That on a day to day basis, and at the level of the call centre operator, the call centre is more highly regarded by the client organisation than they are by the organisation hosting the call centre.  The implication of that is that staff who's job satisfaction depends upon the good regard of their host organisation's management, and who have an expectation of career advancement in the host organisation, may be uncomfortable in the call centre role.  Conversely, a call centre operator who has no career ambitions within the host organisation, but who derives satisfaction from the high regard of the client organisation will be relatively happy (and productive) working in the call centre.

Does this mean that you should look for staff with no career ambition when filling positions within call centres.  Well, yes - and no.  What it says is that you might maintain (or build) a core of staff within the call centre that match this description, and use that core to give you stability while you develop strategies to address the other issues that you are now aware of, and those are:

• the lack of visibility of the high regard that workers in the Client Organisation have for the call centre
• the lack of regard that staff in the call centre host organisation have for the call centre

Of course the first one looks easy and the second one looks much harder, but the second one is the key to opening up opportunities to 'unstick' the call centre and improve the service that the whole of the call centre host organisation provides to the client organisation.  The good news is that while the solution to the first promlem involves getting lots of different parties together and changing their attiudes (and frankly you have nothing to offer them in return), the solution to the second problem can actually involve you offering a great deal to both the call centre host organisation and the client organisation at very little cost to the call centre.  Furthermore, the solution to the second problem can be initiated and largely developed within the call centre without the need for additional resources.  More later..

Modelling Call Centres.

This paper suggests that we generally underestimate the complexity of the call centre role within organisations. Superficially call centres are about people taking phone calls and answering questions. The simplicity of that activity, and our familiarity with it as one of the generally less complex (but often irritating) tasks we undertake in our day's work has the unfortunate effect of obscuring the real issues and complexities in the operation of call centres.

 

Every manager who has ever answered a phone or a question believes that they are qualified to have a view about what it would be like to 'do that all day long', and the view is invariably that it will be an 'unpleasant task'.  That prejudice is evident in the emphasis these managers put on COUNTER-balancing the unpleasantness by creating a pleasant environment for call centre staff, or a promise of rotation 'out', or (even) built in morale and psychological management.

 

This emphasis on these interventions to support call centre staff does no harm in itself, a pleasant working environment is always pleasant, and rotation 'out' can be simply read as 'career encouragement'. The danger is in this. After providing the most efficient technology, the assumption is that any shortfall in performance is due problems with staff morale. And morale (and technology) can be 'tinkered with' endlessly (and at considerable expense). What is missed in all of this is that call centres are not just about technology and people, but also about relationships and knowledge. 

 

I am talking about relationships and knowledge in the broadest sense, that is the relationships between organisations and elements within organisations, and in the knowledge of the 'interests' and 'prejudices' of those organisations and elements, and in the knowledge of the forces that work on them. This is not - as you can see - just a matter of the single over-the-phone relationship, or the knowledge required to resolve a particular question - although these are also part (a small but significant part) of that 'broad' sense.

 

I would argue that an understanding of these relationships and knowledge issues is fundamental to an understanding of call centres, and in fact points the way forward for transforming an underperforming call centre. To illustrate the 'power' of these factors consider a scenario where your knowledge of the group that was calling into the call centre was such that you could anticipate what they would be calling about next week and do something to prevent them needing to call. Which also illustrates how a call centre's performance should be measured on the basis of how 'few' calls they handle, rather than how 'many'. 

 

Let me add one other consideration before moving on (an upcoming post) to a discussion on how to use an understanding of relationships and knowledge issues to better design and manage call centres. And that is that call centres evolve - that's to say they are subject to influences both internal and external that can drive them in directions that you did not intend. Which is to say that even managers of successful call centres need to keep a watchful eye on more than just their staff.

Issues in Technology Management - IT Security working for the organisation

This essay explores the motivators for excellence in Security Management.  Specifically it looks at the factors that work against positive motivation, and the limitations of negative motivation when it is applied to Security Managers and Managers with security responsibilities.  The second section takes a look at the practical issues in security management in just one (anonymous) organisation, and while some of the issues may be very specific to that environment, they illustrate how the 'ideal' and the 'actual' can differ.

A Possible Model for IS Security Management

It is important that Managers with responsibility for IS security are motivated by a desire to create an effective IS Security Environment, rather than simply by a concern to adhere to standards so as to avoid opprobrium for security failures.  While the former approach is essentially open-ended and able to accommodate changes in organisational arrangements and in technology, the latter approach is frozen in time at the moment of publication of the standards, and is limited to the horizon set within those standards.  A standards-only approach discourages any initiative or questioning of those standards, even in the face of evident shortcomings.  The further removed we are from the place or the point in time where those standards were developed, the less likely they are to meet, or continue to meet, our requirements to secure our IS environment.

My suggested model involves the creation of a Security Team whose primary role is to be implementers and auditors, rather than processors.  Their performance should not be measured by the degree to which staff comply with the standards that the Team develop (and constantly evolve), but in fact measured by the degree to which those standards comply with the requirements of the organisation. We create a point in the organisation where IS Security is the sole focus of activity, and where security staff can be motivated by positive achievement, rather than by compliance (only) with a negative template.  The continuing positive focus of the Team, would however, very much depend upon the attitude of the organisation Executive.

Issues in Technology Management - Maintaining commitment to Disaster Recovery Plans

Disaster Recovery Plans (DRP) are predicated on systems and procedures working successfully together.  If you're fortunate enough to have a plan, how do you keep it alive - because they seem to 'die' from a range of causes.  In fact you could call them  the 'fragile flower' of the computing environment.  Which is kind of paradoxical,  given that they are supposed to be your 'robust response to the most dire and unexpected events'.  Actually that's the answer.  Disaster Recovery Plans are (primarilly and often exclusively) designed to deal with disasters, and not designed (usually) to maintain themselves 'in-between' times.

It's not so much a disease that 'knocks over' DRP's but 'predation'.  If the DRP includes hardware resources the sight of those idle 'ready to go' machines is an fatal temptation to the hard pressed organisation .  But of course the 'fatal' consequences don't become apparent until you need the DRP to respond to some unpleasantness.  But's that's not to discount the effect of 'drift' where your DRP isn't kept up to date with your changing business, or simply loss of knowledge about how to run it when the time comes.  Sure you've documented the procedures, but where did you put that document - and has it been burnt/turned to pulp by floodwater/or sitting under several tons of highly compressed reinforced concrete?  In fact, for that matter, where are you, and what particular condition are you in to co-ordinate things?

Is there an answer to the problem of keeping the DPR 'alive' and ready in your organisation?  Perhaps, but the solution is not what you'd expect.  If you turn over part of your DPR site to production activity (which is heresy in traditional DPR-land) you make it part of the 'active' landscape.  In a Disaster you simply stop that aspect of production and switch the resources (and potentially the people) over to the 'Disaster Role'.  I might add that of course we're talking about a physically remote site.   I'd argue that it would be good to have the people using that part of the system there as well (and have them trained in running the switch-over), but it's not essential.  So how do you stop that capacity from being turned from 'discretionary production' to 'essential production'.  Well it's the same issue as the poaching of equipment in the first scenario - it has to be managed.  But there are advantages in putting the DRP in the 'active landscape', and that's what I'll expand on shortly.  And yes there will still need to be 'duplicate' embargoed equipment and systems within the DRP site, which means that we are talking about a complex solution.

Logon Warnings

The significance of the 'warning' message at an organisations logon screen extends beyond the 'immediate effect' that it is intended to achieve - which is to alert the system user that they are 'at' a private logon screen, that they should not proceed unless they have been authorised to do so, and that authorised persons who do access the systems will need to abide by certain conditions and standards of behaviour. The 'extended' significance lies in it's ability to affect the likely success of any attempt by the organisation to prosecute (or otherwise proscribe) anyone who logs on, or attempts to log on, where they are not authorised to do so. Effectively the message is intended both for the person who encounters it 'on the system', and for a courtroom full of lawyers.

Creating the Creative Technology Organisation

How do you create a creative organisation out of a (primarilly) processing organisation?  You can't, not by your own efforts alone.  But you can (help) grow one.

Are we talking about making 'everyone' creative?  No, the bulk of your people have already self-selected into their jobs and are happy doing what they're doing, and hopefully they're doing it fairly well, and who don't particularly want to do anything more..  The people we are targetting are the ones who are looking for 'a little bit more', who are good workers, but frustrated that they have no outlet for what they might call the 'creative' streak, the urge to 'do things differently' (or different things).  These people if encouraged have the potential to create benefits to the organisation that far outweigh their numbers.  And they have the potential (because they are placed to do this) to encourage the creative streak in some of their 'less discontented' peers.

Are we talking about turning a processing organisation into an advertising agency?  No, effectively we're talking about a 1 or 2 per cent effect.  And I'd argue that we're talking about converting 'lost' time into creative time by diverting people from 'goofing off'.  Productivity in this model should lift, because we don't have to demonstrate offsets against 'lost' processing time.

So is the creative organisation about making some people feel better in the workplace? No, it is primarilly  about harnessing the potential of some of your staff to make a greater contribution to the success of the organisation, because - as I'll argue - technology and processing organisations 'die from the inside out' if they don't have a healthy  creative or regenerative process at their core.   We used to think this was the role of the Executive, or something we pay consultants for, but my argument is that if you marry the creativity to the workers at the 'coalface' you ensure that creative/regenerative process is linked to the most powerful (and numerous) force in your organisation - your staff.   If it means that you get better staff morale and staff retention then that's a bonus.  And I think you will.

It is easy? Very easy to start, because you are encouraging those people who have an 'urge' to go in this direction to simply 'go in that direction'.  All the organisation has to do is is lay out the general direction, and loosen off the 'restraints'.  It gets interesting when they start 'heading in their own direction', but that's where you earn your salary as a manager.  More later..

Liability for Security Breaches in an Outsourced Arrangement

While we talk about the possibility of 'insiders' being involved in security breaches (well in fact the 'probability' if you believe the surveys), what are the consequences for a outsourced service provider (who is providing security) if a member of the contracting organisations staff is responsible for a security breach.  I guess in the case of there being financial penalties against the outsourcer in the event of a security breach, sharper legal minds than mine would have already sat down and mapped out 'contingencies and exceptions'.

You'd presume there'd be some sliding scale of liability, whereby if the security 'breach' involved the organisation's employee using their 'legitimate' access to use the system in 'legitimate (but illegal) ways then the outsourcer would have no liability.  But if the employee managed to 'break' into the system to any degree then the outsourcer would be liable.  You'd assume 'any degree' is important, because even though the employee is accountable to the employer for their actions, the outsourcer has undertaken to the organisation that the system is proof against break-in by anyone (to any degree).  Well you'd hope so - check your contract!

Actually that seems fairly clear cut, but what constitutes a 'break-in'?  Obviously anything that has the effect of breaching an implemented security rule.  But consider some 'odd' scenarios.  Someone in Finance 'achieves some mischief' through the system using a legitimate account and legitimate access.  Obviously the outsourcer says "sorry, but it's down to your employee, we accept no liability".  But what if the outsourcer has been asked to create a new security rule to 'fix' what had become evident to the organisation was a security 'problem'.  In that case the outsourcer is (again) liable if it can be shown that they haven't fixed the problem within a 'reasonable' period.  But what is a reasonable period - especially if the funding arrangements for these 'amendments' hasn't been agreed to before-hand.

And what happens if the outsourcer who is responsible for security notices that there is a hole in the system that would allow employees to 'do mischief' with their legitimate accounts.  Should they inform the organisation?  Or not bother, knowing that they will not be  formally liable until after they are 'requested to fix the problem" by the organisation.  I guess the thought of the income that would accompany the request by the organisation to 'fix the problem' would be a positive motivater for the outsourcer.  Which suggests that the existence of an agreed funding arrangement in VERY important in getting the outstourcer to be interested in finding security 'holes'.

And if you don't have financial penalties in your outsourcing arrangement, and haven't considered the question of liability response don't imagine it won't become an issue - whether you're an organisation or an outsourced security provider.  Firstly there is the matter of reputation.  In the event of a breach becoming public knowledge the attribution of blame can have significant financial (or career) implications for the party on the 'receiving end'.  Secondly, if the security breach involves 'damage' to some third party (say an unsuccesful bidder for a contract), then who that third party chooses to sue may depend upon their perception of where the blame lies.  In the absence of a 'responsibility agreement' between the outsourcer and the organisation,  the aggrieved third party is likely to sue both and let the judge sort out the mess.  The existence of a responsibility agreement might just give one party the equivalent of a note excusing Johnny from some unpleasantness at school. 

Which is why outsourcing agreements that talk about 'partnering' and 'best endevours' leave me cold.

Effective security in a dispirited organisation

I am wrestling with an interesting concept.  To what extent does the 'effective' technology security in an organisation depend upon the degree of motivation and morale of the workforce.  A traditional view would have it that Security has an independent existence' and that it is founded in 'absolutes' - so that there are no shades of grey and no capacity for individuals to make it work better or less well.

Of course this is nonsense.  At the very least a resentful or unhappy workforce is likely to take less care which will - if the security system is 'robust' generate more exceptions and lock-outs.  While the Security Manager is dealing with this workload he or she has less time to look for 'real' mischief.  If the security system is not as robust as you'd hope it was, the 'pressure' on it will eventually reveal holes, which the workforce is more likely to ignore than exploit, but certainly won't bring to your attention.   We are not talking about 'actively' malicious activity, simply the consequences of the organisation failing to build a 'productive open-ended alliance' with their workforce (as opposed to the very un-open-ended relationship defined simply by "I work - you pay me").

If we factor in the possibility of malicious activity by disgruntled employees the significance of employee 'attitude' starts to move to centre stage.  And it doesn't have to be employee initiated mischief, but simply collusive behavior where someone on the inside helps someone on the outside.  We tend to discount the possibility that internal staff will be able to really do any damage on the basis that they (generally) aren't computer experts.  In fact this attitude can lead us seriously astray - while we concentrate our suspicions on the guy in cubicle E13 who is displaying uncharacteristic aptitude with the equipment, we fail to notice the 'computer illiterate' guy at G11 is walking out the door with printouts.

Which gets back to the Security Manager saying, well I can't do anything about 'attitude' but I can make sure that my controls are the best they can be and we'll just have to rely on that (and furthermore even in the 'happiest' workplace there are a few bad apples, so I'll always have to design the systems to take account of the 'worst possible scenario'.)  Which is perfectly correct, but the implication for Security Managers is this:  If you have the opportunity to make observations about how the design or operation of the organisation is contributing to, or detracting from, morale which in turn is effecting compliance with the technology security protocols, should you speak up?

Using customers to drive innovation in service provider organisations

I have tried (and failed) over the last 5 years to sell the concept of the Client Knowledge Base (CKB) to both commercial and government organisations (in both cases 'from the inside'). Obviously part of the failure is down to me, and to the fact that in both cases my position in the organisation (an ex-Executive who had downshifted into a call-centre role) worked against anyone taking me seriously.  But the experience also highlighted some 'factors' at the corporate level which work against the (easy) adoption of a Client Knowledge Base philosophy.

Firstly let me say that I still believe that Client Knowledge is the key to obtaining a competitive edge when most other factors are 'levelled out' (I'm sure that there's a technical term for that..).  That's to say, if I can simply make a better product, or offer it cheaper (without subsidising it), or if I have a captive market then I'm unlikely to be focussed on how 'intimate' my relationship with my customers is.  I might realize (hopefully before its too late) that I can't do this 'ad infinitum'.  But (in the usual ironic way), if I'm fairly successful at what I'm doing 'at the moment' (with the level of Client Knowledge that I have) then I'm unlikely to make the effort to further build that Client Knowledge.  If - on the other hand - my business is on the skids I will be more inclined to try and cut costs by - as has been pointed out by Chris Lawer - trying to reduce customer interaction to the bare minimum because it is 'human' expensive.

This seems to a 'universal truth' and perhaps requires some specific strategies (which I might canvas outside this comment rather than have it sink under its own weight) - but one thought that comes to mind is that it might be easier to introduce these approaches in a new business, rather than an established one.

Users

I was just over at Chris Lawers blog  and picked up a discussion (started by Richard Anderson) about the use of the term 'user' to describe people 'on the receiving end of technology services'.  There was some suggestion that 'customer' was more respectful (user had 'connotations'), but it was pointed out by Mark Kawano that the customer (the purchaser) was very often not the person who ended up 'using' whatever it was that was purchased.

I  have to agree with Mark, ‘users’ don’t always see themselves as customers (and in fact reject the term as ‘window dressing’) But it depends on the context. The sort of ‘users’ I deal with are people in organisations who have been required to use technology as part of their jobs. They relate to the concept ‘user’ in the sense ‘the poor sucker who is using this defective system..”, whereas ‘customer’ doesn’t do much for them (except to provoke in some the question “you mean I have to pay for this support” ).

But it is also right that ‘user’ is a generally perjorative term. I used to do computer support for the police, and they DID NOT like to have have the term applied to them at all. We tried all sort of alternatives, the closest we got was ‘Client’ , but we always ended up with confusion between the ‘contract Client’ (eg the company) and the individuals we were supporting.

The answer in the end was to use the word properly (to go back to basics), and talk about ’system users’ . I liked that because it hooked into the concept that these people were using the system (or the facility or whatever) we had provided, and I could focus my people (on the service delivery side) on getting things right with the system AS WELL AS with the users of the system.

Interesting how we ‘contract’ (as in shrink) language, then find it unsatisfactory, then look for some substitute word that is ‘more appropriate’ , ‘less offensive’, or (in this case) ‘less tainted”. But I’ve never been a fan of contracting language, why say in one word (unclearly) what you can say in ten (clearly).

Issues in Technology Management - Retaining Call Centre Staff

Technology Call Centre managers bemoan the high turnover rate of staff, and yet have very few effective strategies for reducing that rate.  Mostly they talk about methods of managing the impact of that rate of turnover - as if it was a force of nature that they can only (at best) respond to rather than control.

Yet call centre staff turnover can be reduced from the industry average of 40-60% per year to a much more acceptable 10-20% per year.  The pay-off is not just in recruitment and training costs, but in being able to bring to bear stability and experience in your dealings with your clients. 

There is no magic formula, but you might consider (in addition to the 'standard' advice):

• Employing older staff, particularly those who have 'old technology' experience
• Valuing these older staff (your core group) as mentors of younger staff who are 'passing through'
• Offering flexible hours and working arrangements for technology staff who's need for flexibility (eg parenthood issues) means that they have to 'give up' their regular IT career for a while
• Giving staff the opportunity to become Client Researchers (my Client Knowledge Base paper elsewhere in this Blog), or Mentors, or to train themselves, or simply 'goof-off' between calls (because you are paying them to answer calls and if they are really good at that then they earn their 'keep' just doing that - and you'll find that most people would prefer to have some worthwhile 'secondary' task, just give them the space to find it)
• Don't rotate people in and out.  'Outsiders' generally don't look forward to joining the Call Centre, and often destroy morale there by breaking up the the 'The Worlds against us but we're ok' defense mechanism that keeps Call Centres stabilised, and by simply having a bad attitude and complaining (as filling in at the Call Centre is often seen as 'punishment').  If Call Centres had high status this might not be an issue (people would clamour to get in there), but lets be realistic...  If you make the call centre staff responsible for their own (collective) roster you'll find that their committment to their colleagues means that you have far fewer instances of absence, or situations where the on-deck staff aren't willing to put in an extra effort to make up for any short term absences.  It's a touch-and-go decision, but generally an 'off-the-street' replacement is often less trouble than someone brought in from somewhere else in the organisation 'against their will'.  Encouraging 'volunteers' (and methods for doing this) is a big enough discussion to take somewhere else in this blog (when I have a moment..)
• Break down the separate partitions as far as possible.  While managing noise is an issue, it shouldn't be necessary to put Call Centre staff in 'boxes' where they can't even see each other.  And - oddly enough - IT Call Centre staff RELY on overhearing other calls in order to detect 'what's going on' much of the time.

The Ex-Ex, running your career in reverse

I have to admit that if I was someone else applying  my own skeptical standards to these posts I'd have to ask 'interesting analysis, but what's this based on and why don't I find these views expressed elsewhere?"  Well I don't fully know the answer to the second question, but it might lie partly in the answer to the first one.  And that is that the second half of my 20 year career in IT has effectively been 'in reverse' - from IT management back to desktop support. 

Many IT managers 'started at the bottom'  (myself included), but by the time they have an 'Executive' perspective their front line experience is just a 'distant recollection'.  For me, however, front line experience is an immediate experience.  It might be said that my management experience is the fading memory, but frankly cunning once aquired stays with you, and some of the other aspects (such as being an utter bastard at times) are best let 'slip away'.\

So am I driven to report my insights in order to fight for the status of (and better working conditions for) the frontline IS staff, or for the poorly served IT consumers?  Not really.  Partly its amends for being that bastard-IT manager for too many years, and partly its recognition of the value that the advice of others has been to me over the years - and a small repayment of that debt.  But the real value of it is in this:  if you doubt what I say, or argue against what I say, we might be able to progress the debate on the real issue in IT, and that is how to get it to 'serve' us, rather than have us serve it.

Incidentally,  with the tendency to people staying in the workforce longer, but at the same time wishing to spend more time 'living a life outside work'  we might find more managers ready (after several years at the top) to 'down-shift' and take up less demanding (well that's a point of view !) positions on the front line.  It will be an interesting challenge for organisations to encourage that (because otherwise career paths become blocked for anyone under the age of 70) - both in the sense of offering sufficiently attractive 'down-shifted' careers, and in still leveraging the 'value' of older employees corporate knowledge and wisdom.  The subtle power plays and manouvering  (and the gross prejudices) that arise need to be managed by the employee, and the organisation, but it can be done (who better equiped to find a way than an ex-Executive (it has a ring to it...))  All this is worth a much bigger post - and I'll get around to writing it.

Issues in Technology Management - "Children, play nicely"

This post started life on the 'Never Work Alone' Blog,   A question arose there about how to get IT folk and 'other' folk in organisations to understand each other and talk and work together.  I think the key to understanding the problem lies in this perceptive observation by Dwayne Melancon:

"there is something strange about how non-technical people view IT problems: they often blame themselves. If you use a non-IT product and it doesn’t work effectively, you blame the product. On numerous occasions, however, I’ve heard people having trouble with software say things like, “I must be stupid - I can’t get it to do what I want it to do.” Bizarre phenomenon"

Mini Concept - the 'faith' aspect of scientific belief

The preamble makes the claim that 'faith' underlies much of what we regard as scientific fact.  I'll suggest how that is the case, but in doing so point out the difference between a 'faith approach' and a scientific approach'.  And somewhere come to the point of how 'skepticism' is not something sitting on the sidelines chucking bricks at mainstream progress, but in fact something that is central to that progress.

A very normal  fellow who'd attended theological college, and eventually moved to Nepal (with his family) to work on education programs there, had an argument one day with me about the nature of 'truth' and 'faith'.  I can't remember how it started, but I remember being surprised that he won that argument, and that I'd learned something from an unexpected quarter about something that seemed fairly obscure at the time.

The argument goes like this.  A person with faith simply 'believes'.  They have made a decision 'to believe' of their own free will.  On the other hand, a person who takes 'scientific approach to getting at the truth' goes out and 'checks the facts'.  They might check the references, they might go further and 'observe' the evidence, they might go further and devise experiments to check the evidence in new ways.  But at a certain point they decide to 'stop' checking, and reach a conclusion on the basis of all that checking and evidence.

Now the question is, at what point does the person know (for certain) that they can stop checking?  No matter how you twist it, the point at which they stop checking is arbitrary.   The decision to stop is based on a belief, what they might call a 'reasonable' belief, that there's no further evidence out there which will fundamentally change their view about the 'factuality' of that fact.  And so, underlying every 'accepted scientific fact' is an act of belief' which is of course nothing more than an act of faith.  And have 'accepted scientific facts' ever subsequently been proven wrong?   Of course, try this example (which was good enough to win the Nobel Prize): http://nobelprize.org/medicine/laureates/2005/press.html

The difference between science and faith approaches is, however, that the scientific approach should (but admittedly often doesn't) encourage every person who encounters a 'scientific fact' to question it, to see if the checking and questioning that had gone before had been rigorous enough.  When science is presented without this proviso it differs very little from 'blind faith'.  Skepticism, a philosophy which suggests we should constantly re-check the basis of our beliefs, and look behind 'accepted facts and wisdom' is then, essentially, a 'scientific approach' that benefits science, as much as it does technology, or organisation management or public administration.

So what does this say about the faith approach?  Nothing.  This story is about the faith aspect of the scientific approach, because this Blog is about skepticism and technology.   But am I saying the faith approach is truer because it underlies everything , or the scientific approach because it has the capacity to move our understanding of everything forward?  Well I'd only observe that to proclaim one over the other would be a bit like saying that one of my (two healthy) legs is more useful for walking than the other.  The question of where we are heading, and whether we should 'simply sit' rather than 'simply walk (to borrow a Zen concept) is a question (or in Zen not a question but simply a noise) that I'll leave others to ponder.

Mini Concept - Punitive and Supportive Approaches to Technology Security

The traditional 'do something wrong and you will be punished' approach to achieving security compliance means that we alienate a large group within the organisation who should - in fact - be willing allies of the technology security manager.   Staff who are 'on-side' are more likely to tell you about breaches or weaknesses in systems and about 'strange' behaviours in the workplace, and are more likely to comply 'to the full extent' with the organisations security approach.  How do you get staff on-side?  Easy, tell them that Security is all about protecting their interests as much as it is about protecting the companies or even (as they probably suspect) your own.

(1) Tell them that security exists to protect staff from identity theft, and from having bad things done in their name.  You can explain that those 'bad things' could involve automatic involvement by the police, and though (you'd hope) their name would be cleared, it can be a very unpleasant experience.

(2) Tell them that Security exists to ensure that staff are not harassed in the workplace, either through the receipt of broadcast pornography, or via targeted attacks from folks outside the organisation, or by their colleagues.

(3) Tell them that Security exists to protect staff member's personal information within the organisation, so that the strange dude in the computer department can't stalk them, or that the estranged spouse can't get information about them from one of their colleagues.

(4) Tell them that Security exists to protect the interests of their customers, who might otherwise sue your company, or possibly them, out of existence for some breach.

(5) Tell them that Security exists to prevent the bad guys from bankrupting the organisation and throwing them (and you) out of work.

Let's talk about the punitive approach for a moment, and how we can do better.  Firstly, consider working through the management chain, instead of going directly to the 'system abuser'.  Managers need to know what is going on in their areas.  Doesn't this make it worse for the 'system abuser' though ?  Well yes and no.  If the manager doesn't think things through he or she is likely to believe you without question.  If they are really doing their job they'll ask you to show them the evidence.  They might then do you a favour by pointing out something that you don't know about the way they do business in that area, that might involve 'bending' the badly designed system in order to 'just get things done', or they might remind you that you gave folks a system but never trained them how to use it, or they might tell you that you've 'got the wrong man' (because something they know tells them that this is a case of identity theft).  So the manager can save you from looking stupid, and you might learn something if you keep your ears open.

And if you encounter a manager that doesn't think things through (or have the confidence to question your competence in these matters), consider all of those issues yourself. 

Most of the errors we see arise from bad design, poor implementation, poor maintenance and poor training.  Even where someone 'wanders' from the straight and true path, it is more productive to let them know that you know, and to 'assist' (through training or whatever) them to get back on the straight path.  It costs a lot to recruit someone, and it usually takes a while for someone to 'go bad'.  Punishing either means they walk out the door with your investment in them, or they harbour a grudge that is just waiting for another opportunity to get revenge.  Most folks 'stumble' across security weaknesses first time round, and don't deserved to be punished for that - if anything the system designers and maintainers should be slapped down for leaving a weakness in the system.  Which means that there is an onus on you to do something (if you can) to 'fix' the system.  That's far more work than just punishing someone, but are you working in this organisation to make it a better organisation, or just to have an easy life?

If everyone answered 'easy life', then consider that the staff member who is 'on side' will make your life easier by being interested in 'doing the right thing', and helping you 'evolve' the system to a state of as near as possible security perfection.  Now that should make your job a breeze, you wander around doing the 'how's it going thing' while all of the workers in your organisation become your security 'deputies', and that warm glow from below might just have a real payoff in management's regard for you.

Concepts in Technology Management - Client Knowledge Base

A Client Knowledge Base is essentially a discipline that involves capturing and building information about the client organisation, and then employing that knowledge to more effectively react to, and anticipate, the client organisation’s technology issues and needs.  The focus is on service, and on anticipating requirements and building opportunities.  The aim is to have such a profound – and carefully targeted - picture of the client and their technology environment, and use it in supporting the client, that we reach the point where the client becomes apprehensive about any loss of service that might be involved in switching to a lower priced offering from a competitor.

It is the degree to which we build this picture and who we use to build it that sets this proposal apart from the existing offerings in the Customer Relationship Management area, from traditional fault-resolution databases and from ITIL’s Configuration Management Database, Service Catalogue, or Known Error Resources.

Concepts in Technology Management - Death and Re-creation in the Technology Business Environment

Five years isn't a bad life cycle for an organisation these days, particularly one built around a technology capability. An organisation that commences with a reputation for being 'innovative' and 'imaginative' often ends up being seen as 'resistant' and 'unresponsive', standing in the way of change or innovation. My concept involves building a capability into the organisation such that - even at the end of its lifecycle, it still had sufficient innovative skills and attitude that it could dictate the terms of its demise (to some degree) and its 're-incarnation' (to a very large degree). And this, if anything, is a thing I do care about, because it reflects on the quality of the workers experience, and their capacity (particularly their reputation) to extract themselves from the train wreck at the end of the line.

Issues in Technology Management - Impediments to Getting it Right First Time

I was moved to comment yesterday by a programmer who sadly observed that nobody (much) these days cared about building in quality and robustness.  I think some  programmers should sit down and have a few drinks with architects and get some perspective on things.  Architects might claim they have a worse deal - being descended from great artisans of the past etc.  But it's generally the same issues - problems getting a decent specification from the client, client changing their mind, client running over budget expecting savings that don't compromise performance, most jobs are routine and boring, integration problems and dependency on sometimes 'unreliable' components (builders and materials), unrealistic expectations on timeframes, client unwillingness to try new things, regulations restricting use of new designs or innovative materials, and the failure of the client to recognise how specialised the skill is and how much it is worth.   Oddly enough, although we in the IT industry talk about  software or systems 'architects', we tend to think of ourselves as engineers.  And yet, by and large we don't make any attempt to understand either profession.    Borrowing the titles should impose some obligation on the IT industry to 'achieve' the same standards,  and to do that we might need to understand how those professions evolved those standards, and the 'problematical' environment they have learnt to cope with.  But returning to the sad programmer, I gave him a list of a dozen reasons 'why it is so', and - of course - not all of them are obvious.    Could you build a checklist from them to assist you in 'avoiding the errors of the past' ?  Probably not. (another discussion..)   Here goes..

Concepts in Technology Management - The appropriate use of technology systems to monitor work performance in the context of Performance Management

A concern arises as a result of the degree to which activity (essentially staff work performance) can be monitored in our technology systems. Technology staff managing the technology systems have the capacity to observe staff member's work and 'non work' activity (and even infer - rather dangerously - inactivity) within the systems.

 

Staff are quite rightly, concerned about the implications of this, and it is an area which Government and Courts are taking a considerable interest in. Technology staff are generally not concerned - but should be - as their ability to access this information places responsibilities on them to act properly in handling it, and may incorporate some significant sanctions for mishandling it. All staff (general and technology) operate in a rapidly changing technical environment where there is little guidance or understanding of the legal implications of monitoring for those who are monitored, and for those who are doing the monitoring.

Concepts in Technology Management - Acceptable Use of Technology Agreements in the context of an overall Performance Management Policy

Computer systems include capabilities that enable detailed monitoring of performance and activity within the systems.  The requirement to manage the systems and maintain a very high degree of security over them will require that technology staff utilise those capabilities.

Systems managers will need to respond to situations where inappropriate, or illegal activity is detected.  Teams working to develop technology are cognizant of the need to publish standards for the proper use of the technology, and to have people who use those systems signify their acceptance of the standards (and of the consequences of breaching those standards), in personal agreements commonly referred to as 'Acceptable Use of Technology' agreements.

Concepts in Technology Management - Delivering an IS Environment

The mistake that Organisations frequently make, when looking at the effectiveness of their technology Service Desks, is to focus on how effective the Service Desk is at dealing with the Client, and not at how effective the Organisation is at dealing with the Client.

The effectiveness of the relationship between the Service Desk and the Client - how quickly the call for assistance is responded to, how well each problem is resolved - is not the TOTAL measure of how well the Organisation is looking after the Client’s technology needs. Despite the fact that this is something we constantly strive to do better, and in fact often do quite well, it is ultimately futile. It does not ensure that attention is paid to fundamental issues, such as problems with the quality of the infrastructure, or training, or systems, which are causing the calls for assistance in the first place.

Concepts in Technology Management - Service Desk Audit

Information Technology Service Desks (indeed IS Departments) that do no more than resolve problems and requests for assistance in a timely manner are guaranteed a future doing the same thing ad infinitum. A purely reactive Service Desk, is a Service Desk that does not assist Information Systems (IS) Client areas in making progress in addressing fundamental problems, or in planning how to employ technology to drive their future business. Whatever work that does get done in those areas is often due to Client areas’ initiative, driven by extreme frustration (with problems) or dire necessity (forced migration to new systems).

Concepts in Technology Management - Remote Support Models

While it is true to say that “Service Desk Systems don’t solve problem, people do” the quality of the systems have a considerable bearing on the quality of service, and the quality of the experience for both support staff and the users of our systems and facilities. While my earlier paper “Self-Managed Sites” suggests that there could be a 80% to 90% reduction in Service Desk calls if we adopted a new model for managing remote sites, my expectation would be that we will baulk at the up-front costs involved in that model, and implement it only partially (if at all) across all sites, or very selectively at first across a limited number of sites. This then, still leaves considerable scope for discussion about savings in the area of the provision of remote support through the use of improved systems. And of course, even if the volumes of incoming requests were considerably reduced, wouldn’t it be nice to do those, much fewer calls, more effectively?

Concepts in Technology Management - Self Managed Sites

I have spent quite a few years looking after computer and telecoms systems in a patch covering 2.5 million sqare kilometres (mostly desert) and all of that work was done remotely. It was possible to observe that there were factors that made it significantly easier to work with some sites rather than others. Many of these were fortuitous, for instance co-operative staff, or cases where we were supporting two agencies within the one remote community and they were happy to loan each other equipment to “get by” with until we could courier replacement equipment out to them.

In considering how to improve services to these sites, and achieve higher standards of service across all sites, I started to look at how we could make the “fortuitous” the norm, by intervening more actively in the set up and configuration of those sites, building into both the equipment and the configuration of the site the ability to support the site remotely. It became apparent that many of the ideas that I thought might make support of these remote sites easier, also had application in many of the metropolitan sites that we were attempting to support with onsite and roaming engineers.

Concepts in Security Management - Continuous Due Diligence

There is a case to argue that the practical implementation of Systems Security in organisations has been too strongly focussed on specific threats and requirements around specific components, at the expense of an overall balanced approach.¹ 

It can be argued that this is simply a result of the organisation's risk management working through to the component level. The correct approach, in a world of rapidly changing technologies and threats and limited resources is to prioritise the most immediate threats and deal with them in the identified 'at risk' components. 

The view I want to put forward here is that the day to day allocation of resources to maintaining the security of different systems components is a not - primarily - a result of a co-ordinated risk management strategy. I will suggest it is a far more 'subjective' process where particular experts in different fields of expertise are making decisions about what they think is important or what they are familiar with.  The degree to which this creates a security risk for organisations, and what can be done to mitigate against that risk is discussed further in this paper.

Concepts in Security Management - Component Security Certification

Overview. What is It

Component security certification is an approach that works to ensure a comprehensive security coverage of an organisation, by identifying all of the components of an organisation, and ensuring that the security implications of each component are considered and addressed. By component, I mean staff, equipment, policies, contracts and agreements, services, the physical and technical environments, and internal and external communications links.

Skeptology

To be sceptical about the capacity of computer technology to meet the needs of individuals and communities, and to be sceptical about the capability of individuals and communities to take up the benefits (and responsibilities) of technology kinda takes the shine off one's view of this (technology) world.

Every bright young man or woman who ever sat down in front of a computer for the first time and imagined that they could change the world, and then goes on to administer some ramshackle network in the service of some rudderless organisation gets here sooner or later.  Some live down in the 'bitter and hateful' corner, quite a few other's spend most of their time here gazing out the window, and others just walk out the door (ah, there is always a door you see..).  Others of course just pop their heads in from time to time, on a bad day when threads strip and code just don't want to crunch the way we want it to.

Years ago I arrived here, spent my time in the bitter corner, and then found the door and walked out into a considerably happier wider greener life.  But maybe I missed the crowds, the stories, and maybe I had (have) some fool-notion of coming back to 'have another shot at it' - that 'improving the world through technology' thing.  So I sit on the bench here, tell some stories, listen to others, and watch, and wait, to see if some of those ripples we set up here might find their way out into the technology world that nurtured us, and - if we can forgive it enough to recognize it - made us what we are.  And maybe I'm trying to recapture that first moment of finding something useful to do with a computer..

Currently there are no other blogs referencing skeptology, but you're welcome to browse..skeptology.