19:
At InsureMyTrip we’re finishing a four-month project adding filters to our product search results (cool project, long overdue). I’m project owner, manager, and design lead. We’ve finished formal QA and are in pre-release acceptance testing. And we’re on schedule.
That’s good, but what’s great is the fun we had during the design cycle. I picked the team and got good people from Customer Care, Dev, QA, and User Experience. And the project team was the design team. And the design team rocked. Arena style.
Debra, Wayne, MikeD, Andy, Hristo, and I had lots to talk about, with our different backgrounds, and we all respected each other. Which meant we iterated designs quickly. Tested. Redesigned. Talked through problems. Made better designs.
In today’s launch plan meeting, I was a bit distracted, figuring out how I’m going to get these people on my next project.
creative commons-licensed photo by Flickr user aresauburn™
26:
At my current employer, I’m learning a lot discussing both business strategy and project management with my manager, a VP on the senior management team. We’re contributing to the conversation from opposite directions.
A recent discussion led me to create the following diagram:
- The mission
- defines ↓
- business objectives
- which inform ↓
- programs
- that define ↓
- products
- updated in ↓
- releases
- that are built in ↓
- iterations
- composed of ↓
- features
- divided into ↓
- tasks
- assigned by ↓
- tickets.
Big caveat: This diagram represents an ideal state. We don’t develop products using Agile (yet). Some of the levels are not so smoothly connected. And we don’t even all agree on the language used in the diagram.
The “task to ticket” step might be not be necessary, but in our environment we have people who are focused on the ticket system as the thing needing changing. So we’re doing as the Romans.
All the same, this diagram can help us be more efficient:
The most interesting concept in the diagram is traceability. The traceability is both ways; there should be a second set of arrows pointing up. Because there are established relationships, tasks must meet objectives. If you can’t connect a task to a requirement to a feature to an objective, don’t do it. Less waste, better productivity.
22:
Just got home from a Providence Geeks meeting where the folks from Treanor Brothers Animation, a 3-D animation studio in Providence, talked about how they got started and how they work. On the way home I kept thinking about their footage of actors in black with marker dots all over the body enacting scenes for video game sequences. The phrase “faking it” popped into my head, not in the negative sense. I was thinking more about how faking it can be an art.
I’m the product owner for a six-week project that we’re having to pull off without much availability from Development, because they’re tied up tight in a massive redo-our-entire-backend-system project. The scope for our six-week project isn’t that large, but one of my direct reports, Hristo, and I are having to take on some development tasks. And we’re most definitely faking it.
While he’s a talented graphic designer, Hristo is in over his head with some of the JavaScript programming (but he’s swimming just fine). The two of us have had to architect some logic that we would normally get from Dev. On top of that, because we’re taking some new approaches with managing the project and I insisted we take on more than the original scope (so we could make a better user experience), we have the eyes from above upon us. It’s a little bit of pressure. Like putting on a skintight, polka-dotted suit and pretending to be a superhero with 50 cameras rolling. It’s also a little bit of fun.
28:
Okay, right: I didn’t really solve that problem. But I did lead a project a few years ago at Dynamic Diagrams, defining the information architecture for a new website for the Forum for Global Health Protection (now Emerging Health Threats).
The analysis phase included user interviews with doctors, researchers, and other stakeholders. One thing most interviews had in common was how they thought about the knowledge: by named threat, by health field, or by global region. We made sure to incorporate a tagging system in the CMS and highlighted those facets in search, including combined searches.
To explain the site’s architecture, we created a diagram. The big yellow-orange cube in the diagram represents the knowledge facets and how users can access knowledge by single or combined facets, in 3D: by layers, rows, or single cubes.
BIG NOTE OF CREDIT: Kim Looney of Dynamic Diagrams did the stunning visual design. My role was to define the requirements, define the architecture, and manage the project. Second note: It’s a large PNG file and may take a few seconds to load.
Click to see the detailed view. It may take a few seconds to load.
The purpose of the site is to share information about emerging health threats from pathogens, chemicals, and the environments (natural and human). That’s what the site’s architecture is doing.
rss feed
