Archive for August, 2010
August 27, 2010
Continuing in my series on professional development – see the previous article on documentation here (ok so there has been a bit of a pause and I am stretching things to call this a series – I had intended to post this some time ago!). This post concentrates on the benefits of using an Issue / Task / Bug Tracking Tool…
Keeping track of development tasks and issues in a centralised system helps enormously. Living without task tracking for your issues is a lot like not having having source control for your code. A good task tracking system – such as Fogbugz or Countersoft Gemini helps keep track of what the team needs to do, allows issues to be delegated / reallocated to more appropriate team members and enables multiple lines of support (eg 1st line, 2nd line etc). It also allows transparency on tasks (allowing Jane who requested a new developer to check the issue tracker for progress rather than interupting the technical team) and (particularly for those of us that need to follow ISO9001 type standards) provides an Audit trail if used properly.
Of course its not just about standing up an issue tracking tool – you need to agree on things like
– what defines an High Severity issue over a medium severity one? What Service Level agreements do we have and how does the issue track tie to those (eg does selecting medium mean response within a day as opposed to high which requires a response within 1 hour for arguments sake).
– What is the process from issue inception through to resolution (does a new change request issue go to Bob -or better Bob’s role “Change Manager” – who allocates it to someone to estimate and changes the status to pending estimation).
– What level of documentation are you looking for in the comments associated with a case – is just referencing a source control commit enough (which is ok if your source control commits are verbose) or do you want a short explaination of what was done?
Clearly if done right this can allow your team to scale and stop your developers getting bogged down with admin (make sure there is someone overseeing the issue tracker). It can also make it easier to seperate support work from new big development work (the former you can give to junior colleagues to help them get up to speed with support from more senior ones – preventing senior guys/girls from getting bored with smaller stuff).
One other observation on this is that whilst you do need to be strict in order to implement these tools (eg ensuring that folks always use the tracker rather than continuing to email you all the time) you need to make sure they don’t become a barrier to communication between the technical team and its customers. One thing I like to do when involved in an operational issue is to cc the issue tracker in on an more detailed email explaining an issue – the customer gets a personalised response and the issue tracker captures the commentary (preventing time wasted by copying and pasting).
Would love to hear others thoughts on their use of issue tracking systems and the pros / cons.
August 26, 2010
Those of us in the IT profession (or Information Management as one colleage recently suggested as an alternative*) don’t do ourselves many favours when it comes to using complex terminology and also expecting business people to understand and embrace IT best practises…
Whilst adopting concepts/practises such as Enterprise Architecture (EA), Data Governance, Information Management (IM), Knowledge Management (KM) are all well and good, the sheer number of buzz phrases and concepts must be bewildering for most non techies. I will admit that sometimes I struggle with the difference for example with Master Data Management vs Master Reference Data without resorting to Google or Wikipedia.
Of course some will argue that is what the Architect or Analyst roles are all about – to match business requirements to IT solutions. But if we ever want colleagues or clients or stakeholders to truely embrace the concepts of Knowledge Management or Data Management / Governance we need to break down these barriers.
Its all too easy to get DM/IM/KM confused if its not the way you think. Generally / at a high level its accepted that Data can be converted into useful Information and that humans (eg employees) walk around with a lot of Knowledge that often needs to be managed (and shared) more effectively. But often we don’t take the time to even explain these concepts – we just jump into enterprise IT lingo and expect others to know what we are on about (or why it makes business sense). Sometimes colleagues can get confused by products such as Sharepoint and what they do – as they can think they are the solution to Knowledge Management – when actually they are just the product or underlying tool that can enable Knowledge Management – its embracing the core concepts of KM that is key.
If we are not careful we will go start to regress back to the bad old days of IT where the IT guy was locked in the cupboard as no one understood him…. Ok maybe thats going too far but you know what I mean!
Or maybe I am being unfair? After all every different business area I have worked in seems to have its own Acronyms (finance is a nightmare with IPOs, CFA, Swaps, Deratives etc etc etc) – is it now accepted practise to just Google terms you don’t understand and be proactive about learning these things? Unfortunately in my experience some people aren’t prepared to do that (unless its in their area of expertise) – and you just switch them off or loose them before you can sell them the juicy or beneficial part of the story.
* Information Management was selected as to not confuse people with “plain old Information Technology” – the physical desktop PCs, laptops etc and kit that every business needs. Information Management it was argued is different as it is the leveraging of IT capability (where IM people are part of the core business team) to improve the way Information is managed (or processes are operated) and used as an Asset rather than something just delegated to IT to “sort out”.