Why do we need Information Management

    I am guessing most of the readers of this blog are in the University of Washington’s Masters of Science in Information Management (MSIM) program.  For those that aren’t, the MSIM program focuses on connecting Technology, People and Information.  I am sure you have heard the statistics about how much information is out there.  With the advancement of the internet, we have caused the amount of information in the world to explode.  All of this is well and good but the problem arises when you try to make sense of the information.  I was watching a TED talk recently that was basically an overview of what the MSIM program is without meaning to.  The talk is given by Thomas Goetz and it focuses on two things, first the use of fear to accomplish things and secondly the idea that more medical problems could be solved not by better medicine but by better information presentation. 

     As a security professional the  idea that fear wasn’t the best way to relay information was something that I hadn’t considered before.  If you have heard any sort of talk in regards to Computer Security you have heard that a hacker can steal you identity, your bank account and with a little effort your first-born.  Okay so I am exaggerating a little but every talk I have given or heard about Computer Security has been about the negative effects of not securing your network.  Then after giving presentations about how there is never a secure system they wonder why executives haven’t approved their expanded budgets.  I believe we, as security  professionals, are going about this all wrong.  Instead of focusing on how impossible security is, we need to start focusing on how we can make the network better overall with the enhancements that security brings.  In this realm I have found that UX people do a good job for the most part.  When they make a presentation about a new website design they don’t sit there and say how little traffic and how confusing the current User Interface (UI) is and then sit down. They quickly go over part of the problems the current UI and then go on to show how well their UI will work and what it can bring to the table.  Now this might just be an issue for Security professionals but I have a feeling it isn’t.  Overall, as professionals, we need to focus on the idea that has been thrown around this blog, and that is the Value Added principle.  Focus on what value you are going to add to the company and how much it will help in the short and long-term. 

     Now as a final statement, this doesn’t only apply to people working.  If you are looking for a job focus on what you can do for the company.  If you can get the other person even a little bit excited about what you could do for them or the potential you have to help their company you will stay in their mind.  And believe me the more good things you give the interviewer to remember you by the better. 

     Now I realize that this may not be new to most  of you but I found the talk incredibly interesting.  I have a link to it below in case anyone is interested.  What are you thoughts?  Is it better to go all positive?  Are there any drawbacks of only focusing on the Positive? Or is it better to talk about a combination of fear and potential?

Putting the Organization in Info Management

Cheeky screenshot of text exchange with a big, uncaring bank
You know this is a dramatization of the event because Big Bank doesn't answer texts after 5pm

Information management can be described using a couple of different but fairly similar models. The University of Washington’s iSchool depicts a triangle-shaped model of Information, People, and Technology. However, our readers might notice this blog examines the intersection of People, Information, Technology and Organizations (this model is explained in greater detail by Ping Zhang and Robert I. Benjamin in a paper titled “Understanding information related fields: a conceptual framework”).

We’re square rather than triangular, if you will.

Why do we add organizations? Because gathering and acting on information changes fundamentally in an organizational context. And sometimes, information behavior within an organization can be downright bizarre or frustrating.

Here’s an example: I went out to dinner a few weeks ago with friends, and my debit card was declined (happily, the waiter did his best to not treat me like a deadbeat). Since the card was declined for no obvious reason, I had a mystery on my hands. Unfortunately, customer service representatives (CSRs) at the national bank where I have my checking account were stumped as well.

Eventually, two weeks later – after three calls to the 1-800 customer service line, two trips to the local branch, and a dozen fact-finding missions through the online banking portal – my debit card was still not operational and I had been told it might be because the number had been stolen.

Think about all the failures in my interaction with the bank: I had several types of contact with different outlets of the organization, and none of them were satisfactory.  At least three CSRs were unable to access my account because I had opened my account in a different state (each of the representatives did sheepishly suggest I could open another account at the branch and then they could help me; I declined those offers).

I can do without naming the bank because this isn’t meant to be a Consumerist-type rant. But I think the episode does bring to light the irrational and haphazard information strategies organizations seem to employ. As a person and a consumer, I scratch my head when representatives of the bank cannot answer my questions or help me understand what is happening with my account access. But the madness of the situation also affects the bank employees: imagine the exasperation of working a front-line CSR job and having one’s hands tied routinely in a significant number of common issues.

But for the organization, this information strategy is working on some level. I imagine – the finance industry being particularly yoked by multiple layers of regulation – this national bank has designed its policies and procedures to serve up a savory dish of compliant operational spaghetti. Somewhere, a satisfied auditor completes an X on a checklist when a CSR in Washington cannot access my account, what with its Massachusetts provenance.

This is operational reality in the modern banking industry, and I mostly understand why my encounter with the bank was so dissatisfactory. However, I think such encounters are at the very least opportunities for learning in organizations. Holistic customer experience (a process of design that includes all touch points in dealing with customers, or even vendors, of organizations) should focus on tasks vital to customers at all service delivery points.

Here at infoscussion, we believe information management model has four facets – and that an organization’s needs can be separate from, but equal to, those of the people involved with the organization.

Lessons Learned on Design, Analysis, and Agile

Sticky notes clustered together for an agile planning meeting

When I was at InfoCamp a couple weeks ago, Erin Hawk and Samantha Starmer both spoke about how they’re working to integrate design into the Agile Software Development process.  This got me thinking about some of the successes and failures I’ve seen in Agile projects and how those related back to the integration of the analyst role into those projects.

Since Agile was a methodology created by developers for developers, it tends to be fairly development centric, and a lot of Agile implementations neglect both design and requirements processes.  As someone who has been in the development, analysis, and design roles of systems implementations, I have seen Agile applied with a variety of results.  Overall, the projects that successfully integrated designers and analysts into the Agile process tended to have much better results.

Many projects are unsuitable for developers to be the primary group interacting with stakeholders (that’s another post altogether).  Integrating designers and analysts into an Agile project helps ensure that the end product meets both business and user needs the first time (ie; on time & on spec). Not to mention, it makes the developer’s job easier by cutting through a lot of the ambiguity around a project and reducing the number of times developers will have to change what they’ve made.  Unfortunately, since Agile stresses speed and iteration over carefully planned designs, it’s not necessarily easy to integrate that into the process.

Here are four of the lessons I’ve learned on how to succeed in Agile development from an analyst’s point of view.

1 – Be an agile waterfall

Agile development focuses on rapidly developing, testing, and releasing a product, which has a tendency to squeeze out designers and analysts . However, many projects and products are so complex, and have so many stakeholders, they require specialists (aka designers & analysts) to handle that complexity.

The best Agile projects I’ve worked on keep all of the phases of the Systems Development Life Cycle, but compressed them down into small and fast chunks.   By reducing the project into a cluster of discrete but related deliverables, ie; user stories, you can keep all the phases of the SDLC but still move at a rapid, iterative pace.

2 – Use staggered phases to keep designers & analysts ahead of developers

One of main reasons that Agile has gained so much popularity is that developers and organizations became fed up with lengthy requirements gathering and design processes.  Such processes tend to lead to specs that are out of date by the time the developers get around to them.

By having designers and analysts work one phase (or two phases at most) ahead of the developers, organizations can deliver just-in-time specifications.  Ideally, the development team can put together a rough set of initial stories and prioritize work accordingly at the beginning of the project.  After that, an initial sprint (called sprint zero by some) can give the designers and analysts time to get ahead of the developers while they set up dev environments and take care of any other start up items they have.  Sprint length will vary from organization to organization, but in my experience two weeks is a good length of time for each group to do a thorough job with their current tasks.

3 – Coordination & communication is key

I can’t stress enough that everybody needs to be in constant communication throughout the process.  As analysts are working on requirements, they should be giving developers a heads up on what’s coming down the pipe.  This keeps the developers abreast of changes, and there will always be changes.  While developers are programming a current set of tasks, analysts can provide feedback and integrate any changes the developers want back into the requirements documents.  A good project manager is often key to this process, as project managers are skilled at keeping up communications and preventing the geeks from siloing up.

4 – You’re either all-in or you’re all-out

Either everybody is working on the project, or nobody should be working on the project.  One of the biggest wastes of time  is when development resources get pulled from a project, but the analysts and designers keep going.  In the best of cases it takes 6 months for the developers to come back, and keeping the rest of the team on the project will lead to a waterfall style mountain of  obsolete design documents.  In the worst case, the project gets cancelled, resulting in wasted effort by the design and analysis teams. If one team gets pulled from the project, management should sideline the project until everyone can get back to it.

Those are my 2 cents on the matter, and I’d love to hear about your experiences in integrating design and analysis into Agile projects.