It could be that my brain just thinks this way, but I’m baffled that people don’t intuitively create information architecture. For me this takes many forms like mind maps, application architectures, swim lanes, flow charts, whiteboard drawings, paper sketches, among other things. What could be more basic then drawing a bunch of boxes, connecting the lines, dot in the servers, show the user flow, and end up with a diagram for what you need to build. Or showing the step-by-step of a process and connecting the relationships between these steps.
For applications I create detailed architecture drawings that document the connections and information flow, but even if you are diagramming the relationships between non-technical parts of your business you are creating information architecture. The act of drawing this forces you to think hard about how your business, application, process, or whatever works. The resulting document becomes a valuable tool to communicate this thinking to others within your organization – technical or not.
For example, I recently did an assessment of a development effort that had lots of moving parts. But to document in a spreadsheet or deck that there was a lot of variability didn’t do it justice. It was hard to visualize. So I created a flow chart of the process, connecting applications to products, to development teams, to hosting environments, to downstream processes, to revenue, etc., etc… This gave a visual high-level view of all the parts, and graphically defined the variability in the system in a way that a PowerPoint bullet list couldn’t do. And as a result, discussion and decisions begin from a whole new level.
Base Assumption 1: Mind the Power Center
I’m a fan of iterative development. There are schools of thought that say “all you need are user stories”, or in extreme programming a desire to have as little documentation as possible and ideally none. But think about what this does. If your engineers are not collecting requirements from the business, then they have the control, and your power center is off balance. And to be fair, this is an overreaction from business who stifled development with the bureaucracy of over documenting and over analyzing.
Base Assumption 2: The Need for Product Management
This is why I believe Product Management needs to reside as its own department, in-between the others. It needs to have the discomfort of accountability to all departments, combined with the authority to enforce a disciplined documentation process. It needs the strategic capacity to identify ways of achieving the organizational goals with an insight for designing appropriate tactical solutions.
Base Assumption 3: Information Architecture is a Required Competency
A big part of effective Product Management is information architecture. Even if you are in a non-technical industry, diagramming process flows is an example of how IA can be an invaluable tool. I’m not saying you don’t need the PowerPoint decks, CBAs, business cases, and all the other tools. BUT information architecture seems to be left out, or mitigated to something done by technologists or ‘technical product managers.’ If you are not developing this skill within your product management team, you are missing a huge opportunity.
Assuming you buy into the resulting value of information architecture, here are areas where I think people miss:
Discipline 1: Make the Time
In my estimation people are in a rush to deliver something, anything. Make the time to do it right. Delivering something mediocre is just that. Every hour you invest creating good information architecture saves you days of time fixing what you built wrong.
Discipline 2: Quality
Make it kick butt. When I work on an application I want to dominate the world. I want it to be so great that the competition will just give up from witness to its fantastic awesomeness. But you don’t get this without doing a quality job, with quality discovery, and quality information architecture.
Discipline 3: Understanding
You don’t build a rocket without a rocket scientist, and you don’t build whatever you’re going to build without subject matter experts (SMEs). I don’t care how much you know about application development, YOU WILL FAIL if your process doesn’t incorporate the non-technical experts, the business savvy leaders, and the everyone else your business depends on. THEY know the day to day, not you. So take the time to sit down and understand what they do. Along the way, develop the working relationships you will undoubtedly need as new questions come up. And of course, put all you learn into your information architecture.
Discipline 4: Patience
Go through as many revs of your document as it takes. I’m losing my hair and there is a reason why – I won’t give up until it is right. Every turn of your diagram is one less time you have to correct your code. I guarantee this is a cheaper way to discover your mistakes, so do the work.
Discipline 5: Replicate Yourself
It is impossible for you to see everything across your project. And depending on the size of your project, you may need ‘specialists’ who focus on pieces and parts as you look to the whole. But either way, get others involved, and have co-ownership of the information architecture. Regardless of who is drawing the IA, make sure you both talk through the details before you build anything.
Discipline 6: Review, Review, Review
Once you have your document, go back to the SMEs and ensure that it makes sense to them. This will likely require some revisions, but that is a good thing – see Discipline 4.
Discipline 7: Focus on Core Objectives
You have to have a clear definition of your organization’s objectives, how your project supports that, and be disciplined enough to keep the focus. If you don’t have this, none of the rest matters.
Discipline 8: The Big One – Eliminate Yourself
Assume you will be fired tomorrow, so today is your last day of work. But, sort of like saying goodbye to a friend, you want to give it the best journey possible. Similarly, work your butt off today, and give your project what it needs to succeed. Document what you know, make sure others do, so if you get sucked into a black hole the project has what it needs to move forward on a swift successful trajectory. And how do you do this? By creating phenomenal information architecture!
Posted by
Jeff Metcalf
Wednesday, February 1, 2012 at 10:43 PM
0
comments
Labels :
Subscribe to:
Posts (Atom)
