Using RT to expose, measure, and improve our performance
I keep on talking about “tool support” as being a vital part of any approach that attempts to address the problems of the department and I think it’s worthwhile spelling out what I’m going on about. I’m going to try to offer a concrete illustration of how we might use a software tool to help us with a number of the things I keep on bashing on about.
I use RT as the concrete example of a ticketing system, but if you are (rationally or irrationally) turned off it for some reason, replace it wih ANY lightweight ticketing tool that supports a rich set of inter-ticket relationships.
I’ll start by listing some of the problems the department has (if we didn’t have problems, there would be no need for an organisational rethink), then describe how one might utilise a ticketing system to help, and finally outline the benefits.
Problems (as outlined to Tim yesterday)
Ok, so I’ve general complaints as follows (collected from talking to various people and summarising some of our issues):
- PRINCE 2 gives us large, monolithic projects. Those projects have deliverables, some of which are concrete software objects (although policies might be another output, and documentation, and so on: the important thing is to consider a deliverable as a concrete object).
There is no simple way of really telling what a project’s up to, and in particular, if Project A deliverable X depends critically on something that might be coming out of Project C, that’s not made formally visible.
- There are also lighter-weight things: stuff individuals or teams are trying to achieve, development work, long-range planning, and so on. Again, we can’t really tell at all what’s going on. We talk about the SPR being an opportunity to remove the duplication of effort going on out in departments, but (for a number of reasons that will derail this post if I go into them, that’s for another rant) we have a – let’s say, a nonzero degree – of wheel reinvention within our department.
- Management meetings are opaque and not particularly collegiate in their organisation. It’s not clear, perhaps, what the purpose of those meetings is and I’ve certainly had people (attendees) snort in derision when I suggested that it was an appropriate avenue to raise things: for passing upstream recommendations and stuff that needed expediting – that needed attention and some general “yes, this is good” go-aheads.
If the attendees of the management meetings themselves don’t know why they’re there, there’s something wrong! Note, I don’t think that cutting down on the number of people in attendance is what’s needed. What’s needed are focussed, collegiate (minuted!) meetings where problems can be raised and short-, mid- and long-term planning done effectively.
- Inter-team working happens, but typically it’s by direct collaboration (pestering) of useful technical folk by each other. Individual schedules are hard to work out and it’s never actually clear when anyone will be available to get work done, or to figure out what dates are likely to be for constituent dependencies of a piece of work.
- Our communication, both internally and externally, could stand a great deal of improvement. We should work in the open. This would have positive effects on morale as much as anything else.
And so on. Right, that’s the “motivating” preamble; doom and gloom over.
Using RT (or similar) to effect a measurable approach
Let’s say we adopt a tool like RT. (Not necessarily that one, I name it because it can pretty directly be used to do this and we’ve one in place if you want me to show you what I’m talking about.)
For this to work, all projects, PRINCE 2 or otherwise, need turning into (or registering as) a series of RT tickets (not just one ticket). RT has some complex notions of ticket interrelationships: child of, dependency, blocking on, etc.
In the case of a large prince 2 project, or a JISC project (assuming JISC is still here in 3 months’ time) the project itself might turn into a ticket; the project strands into child tickets; the milestones and deliverables into individual tickets. Each subordinate ticket would become a child of its parent (milestones and deliverables, strands, projects).
Example: we know that any sane IdM project is going to produce some kind of group management facility. That turns into a ticket, the closure of which would represent the delivery of that object.
Why is this useful?
Well, for a start, when someone is working on something, it might not be completely planned out in advance. That’s actually pretty typical. But they may discover (or realise in advance) that they need, say, a group management facility. Some namespace mapping tools. A directory service. A schema in a directory service. And so on.
If they are planning on producing those items themselves, they can register them within RT. Turning them into tickets, effectively is making a series of statements that these things need doing or will be done. They can mark dependencies between those items.
More importantly, some of those items might later pick up ownership, and be turned into projects. Or be specific deliverables of a current, long-running project, that are still 18 months out at least. And so on.
It doesn’t even matter if someone looks for, but fails to find, a ticket that already stands as the promise of a particular object, because RT permits the post-hoc merging of tickets into one, and dependency links are updated appropriately. So if I’m doing something that needs an X, and I can’t find any information about that, I might create a ticket describing X briefly and what I need it to do. When someone else comes along and reviews that ticket, they might realise it’s part of project A they’re involved in. They can merge those tickets. The resulting merged ticket will still contain my comments, so a bit of useful requirements gathering for the detail of X is available to project A.
How this helps
Critically, RT offers a single, unified space where these deliverables can be organised and the relationships between them spelled out. It’s not the only tool that does this; it’s just one you can look at now to see how this might be made to work.
Furthermore, whilst particular projects can retain their groupings and allocated staff, project queues etc, dependencies between strands of work can also be highlighted. Tickets don’t have to be on the same queue to be related.
Most importantly: this is a machine-processable representation. RT can already draw you a dependency graph. It’s possible to cleanly extract this information and say:
“you want some NFS space? Sure. It depends on the NFS service, which depends on posix namespace mappings, which depend on group management, which depends on the IdM toolkit. We can do that for you in 18 months’ time, give-or-take; or if it’s important, we can escalate that strand of the IdM project”
(Again, I use a concrete example to indicate how this would work. Workarounds and cheap hacks are also representable within this system, just as easily as formal deliverables, and their existence is also formally recorded.)
What this gives you
- A dependency graph that encapsulates everything you’re trying to do. (For this to work the tool needs to be lightweight in operation and capable of handling that number of tickets.)
- Critical paths. A way of taking that information and actually having a sound engineering (I was gonna say “scientific” but it’s not) basis for deciding what our priorities are, in terms of impact, average delays, etc, rather than which project owner shouts the loudest. This will inform management decisions, although I’d hesitate to say their function can be completely replaced by some simple discrete mathematics :-)
- Something concrete to base management meetings around.
It’s machine-readable. It’s processable. You can actually SEE when things were asked for, when they were delivered, why they took that long to deliver, and so on. It’s measurable. You have things that you can look at that tell you how often the cross-team work is stalling.
It’s not perfect; it needs people to work. But it’s the kind of thing I’m talking about when I say “we need tool support”. Hopefully this makes some kind of sense!
(Note: you don’t automatically get this from ITIL, although it’s related. What ITIL will provide are some processes and tools; how you profile those processes, how you use those tools, determines whether you’re an effective organisation or not. ITIL can help structure some of those decisions, but it’s definitely not a panacea.)
As a footnote, please understand that when I talk about getting measurability out of a ticketing system, I’m talking about this kind of dependency tracking, recording start and due dates, etc. There is no mention above about reporting on time taken by an individual staff member, number of tickets closed, etc, and with good reason: the notion is inhumane, it ignores that fact that tickets represent both short- and long-term deliverables of vastly varying size, and nobody around here is foolish enough to think it’s a good idea, fortunately! The goal is to support our staff, not produce a stick to beat them with.