Because I am an analyst, and because, unlike many people in this industry, I actually was an end-user sitting on the other side of the ‘UAT divide’ at one point early in my career (forcing every IT professional to do a period in non-IT roles where you actually have to use the systems being built is something I would strongly recommend:  you will certainly learn more from this than from many training courses),  the things that interest me more and more these days is how knowledge of the processes describing how the organisation operates is recorded and managed.  By that I don’t mean how you conduct the analysis itself (though that can be challenge enough):  What interests me is almost more important: what you do with it afterwards. It always makes me smile slightly when a person in IT says they are going to visit people in ‘the business’ (a horrendous term – although ‘customer’ isn’t much better) to find out the detail of how something is operating:  They talk about it as if they are on a pilgrimage to request elightenment from the Deli Lama.

The reality is, of course, that the users may not know anything.  Trust me, I was one of them. In IT, we’re conditioned to view the users as mystical deities with the definitive answers. Few people seem to realise that often the users may just be in a role by accident and they have to make the best of the systems they have been given – horrendous as they might be.

There is an important point behind all of this.  Recently I met some users to go through possible future enhancements to their system.  Although the meeting was productive, at the end of it I asked them out of curiosity how they learnt how to use the system in the first place.  The answer was that it was a combination of word of mouth, gleaning nuggets of information from other people in the office and ‘just picking it up’. Basically they are just muddling through – though It’s not their fault of course.

Not very impressive, is it, given that we expect these people to be the fonts of all knowledge; and if the system in question had been more  complex than it was, and their enhancements more demanding, it would have raised serious alarm bells with me.

Personally, i’ve never been a great one for ‘just picking it up’.  Picking what up exactly?  Bad habits and erroneous procedures that the organisation spends years later undoing?  The fact that many IT initiatives and indeed entire projects can be blighted by a lack of knowledge is in my view one of the most inportant issues the enterprise has to deal with.  In my job, I see developers struggling almost every day with issues not to do with code quality or the deployment, but with the basic understanding of the fundamentals of the system they are supposed to be working on.  As I said previously here, one of the things that concerns me about automated testing is that it doesn’t contribute anything to one’s understanding and knowledge of the system. If the team are struggling with the basics, no amount of coding or automation is going to help you.  It can on the contrary, give people a sense of ‘false success’ where they appear to be making greater progress than they are:  But how exactly were the stories and and tests arrived at?  Are they right?  Are they complete?  (Oh, and I should add that it takes a long time to do).

Go on a pilgrimage to ‘the business’ and you often find the same basic thing – people struggling with the understanding and trying to aquire ‘the knowledge’.  

Another very interesting issue that sometimes comes to light when talking to the business users is that often they expect the IT department to already know the answer to the questions they are asking: they are implying – albeit subtly – that they expect the IT department to already have the knowledge. In addition, and perhaps more importantly, they think this is the way it should be.   

There are important issues for agile in this.  When people ask me about what I think about agile, my view is always the same:  I agree with most of it.  The percentage tends to hover around the 70-80 percent mark. The remaining 20 to 30 percent consists of miscellaneous concerns chief of which is around the area of knowledge management and ensuring that people (in the business and in IT) have the fundamental knowledge and understanding to even contemplate starting on the piece of work in the first place (or even having an informed chat about it).  Also, will the knowledge that has been gained during the piece of work be propagated into the future, so that when a follow-up piece of work takes place in a years time, we are not continually asking the same questions?   This kind of thing doesn’t seem very important to many agile proponents.  To me, though, it is critical:   There must be importance attached to managing knowledge of the ‘as is’ state of our systems and processes. This benefits all the projects and initialtive going on.    I hear and read little in agile about this, and worse still, sometime such things even seem to be discouraged.  Crazy.

Going back to the user (or ‘customer’ as we are now forced to refer to them):  Many users are under the impression that this is already done. They are obviously surprised (or perhaps annoyed) that we are continually asking them questions about things we ‘already know’. After all, we built the system in the first place, didn’t we?  They view IT (rightly) as guardians of this kind of knowledge and as custodians of the systems themselves. And I agree:  I think that is exactly how an IT operation should be, and this is why I have a bit of an issue with the ‘customer’ definition – I guess it’s fine if you know the specific context but it never seems to convey the partnership or collaborative nature of development and as such it sits a little uncomfortably with me.

So what are my conclusions?  Well quite succinctly, I think ensuring ‘the knowledge’ is available within the team (and outside in the wider IT and business community), and that this is maintained properly irrespective of what projects happen to be going on at that point, is a critical objective for the enterprise. It’s not just an IT issue, far from it, But for IT Is at least as important as acceptance test driven development, auto-deployment, and even issues around code quality and refactoring. In alot of instances it is more important. How can it not be?    But it also requires the same level of time and investment. I am not sure it is getting the attention it deserves, though.  A shame, or perhaps an irony, since it is so obvious.

« »