I’ve been asked by my current project manager to write a list of tasks that I’m involved with as an Information Architect (IA). He’s concerned about time management and my outputs and deliverables, rather than outcomes, in much the same way that Anne Zelenka articulated busy versus burst work modes. Sure, there’s an acceptance that much of what I am involved with is about thinking on how the end release of a five phase system will work, rather than delivering widgets on a regular basis, but in light of some resourcing issues there’s some suggestion that my work might needs prioritising in order to meet some new demands (as opposed to bringing in more IA resources).
So, I wrote out my widget list, the list of things that I’m working on right now, and realised that it didn’t look like very much – I counted about a half-dozen or so documents as deliverables. Andrew Boyd, who is also working on the project with me as an IA, reminded me that part of what we’re doing is influencing outcomes across all the other streams of work, from change management and business process redesign, through to the data model, screens, and, of course, the human interaction factors.
Jesse James Garrett has put together a document titled What an information architect does. It’s a table of responsibilities, skills, technical expertise and experience that IAs need, that helped me to articulate to my project manager what exactly I was doing that wasn’t specifically about stamping widgets.
Jesse helped me to articulate that my role as an IA is just as much about ensuring that every stream of our project will deliver a system that is usable by people and fit-for-business, as it is about making interfaces.
Thanks Jesse.
M
19 June, 2007 at 10:05 pm |
Matt,
You make a good distinction between outputs and outcomes – they are often not the same. Management often thinks outputs are the end result of tasks but it really is all about outcomes. And you’re not alone in “the list department”. One manager I had made me write out a list of all the tasks I did at work (and there were quite a few) but hardly any of them matched his own personal KPI’s. That lack of congruence always struck me as something to be wary of and I was later proved to be correct. Yet my P2P network was strong. I remember at one of our early discussions on my role, he cocked his head to one side and said: “essentially, you’re just a head count here”. Not surprisingly, he showed little interest in my work and I was pleased to leave.
10 July, 2007 at 10:17 am |
Hi Matt,
Great points, and in fact a big one to make I felt.
Often I find that people don’t understand how I can handle burst working, as it looks to others as highly unstructured and undisciplined.
When in fact the exact opposite is the truth. Similar to how agile teams work, (when they are working correctly) they look unstructured, but in fact its because they are supported by a well regimented and disciplined approach in terms of how they address their work to deliver as Brad says outcomes rather than outputs.
In the programme management world, outcomes are the currency as those are what deliver the benefits of the programme. Outputs are static product, outcomes have persistence and resonance against the objectives of the higher goal.
Output management has it’s place, primarily in operationalised environments where such things are easily measured and the concept of KPI’s become useful. Benefit management / outcome management as an individual or as a team is the realm of change workers, and that’s where we typically sit as consultants (when we are operating as consultants rather than practitioners).
In a nutshell…. some people get it, and some people don’t. It takes all flavors to make a baskin robbins.
Thanks for your time writing the entry I enjoyed it.
ben