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?
One of the things that every student worries about is what skills will help you become successful in the workforce. Communication, writing, and presenting are some of the most emphasized skills in universities today. Now that I’ve entered the workforce, I’m beginning to realize just how important they are From my experience, two important skills in professional environments are, how to run a meeting and how to organize your own information. When I started doing this post I was going to keep this to one post but I soon realized that because of the length and depth of this post I am going to break it up into at least two.
Meetings are something that can make or break a project and a career. The people who succeed know the importance of having as well as not having a meeting. This skill is one of the few that can’t be taught in a classroom but must be gained overtime. As I have participated in good and bad meetings in the workforce, I have come to believe that success in meetings boils down to three things: knowing when to call a meeting, how to organize a meeting and how to manage a meeting.
When to call a meeting:
Meetings can eat up a lot of time that could be spent on more important tasks. Try considering alternative methods of communication. I would venture to say that if you are calling a meeting for 15 min or less you could probably say the same thing in either an email, phone call or by going by their desk. Don’t fall into the trap of calling a meeting because you need to talk to a group of people.
Now having said that, I have also been in meetings that were 15 min that were more productive than those that were scheduled for an hour. If the timing is right and the content is prepared then a meeting of 15 minutes can be very productive. The rule of thumb I use is if there is a decision that needs to be made or discussed by more than 3 people and if they currently have differing opinions, or if the material needs to presented to 3 or more people urgently, then call a meeting. Basically what I am saying is don’t be afraid to call a meeting or to not call a meeting, decide what is best for you and the business.
How to Manage a Meeting:
Before the meeting.
I have already talked about knowing when to call a meeting, but this is more about what to include in a the meeting invite and the pre-meeting work. Most of the meetings I’ve seen either don’t have an agenda or have a loose agenda that isn’t followed. This leads to things getting unnecessarily sidetracked and wasting time and can often result in another meeting to complete what should have been finished in the first one. At least 24 hours before the meeting, and preferably when the meeting invite is sent, include the agenda so that people can decide how much of the meeting they need to be there for.
Presenting alternative points of view.
When you are in a meeting don’t be afraid to bring up an alternative view IF IT IS APPROPRIATE. This is probably the hardest thing to do well. If you argue or present different plans too often, you risk being ignored or making enemies. Learn to phrase things in a way that doesn’t degrade other people’s points of view but rather raises your thought as a viable alternative without outright saying another persons option won’t work.
This is really one of my biggest pet peeves. I want a discussion to happen in meetings but a relevant one. When you make your point be short and quick, otherwise people won’t listen and will dismiss your point even if it is ground breaking.
After the meeting.
If you called the meeting send the notes for the meeting soon after and include anything people are specifically supposed to do. This is for two reasons 1) because people forget and 2) you have a record of every ones action items. The notes are also important to verify that what you thought was agreed upon in a meeting was what everyone else thought as well. Nothing kills a project worse than getting to a major junction and having a disagreement about the way something was supposed to be done. Remember, better to have it and not need it then need it and not have it.
Now I realize that I am just out of college so feel free to disagree with me. This is, after all, a type of virtual meeting. What have you found useful in calling/organizing meetings? Is there something you have seen people do that you think is better than others?
As a business systems analyst, one of things I struggle with is finding the right balance of documentation. Often times documentation feels like a chore and as Modern Analyst points out, it can seem downright counter-productive in an Agile environment. Yet, in many situations documentation is necessary for other project stakeholders to do their jobs and to ensure that someone can learn how the system works once you’re gone. The tricky part is finding out how much and what type of documentation is required.
Probably the most important consideration when determining documentation efforts is to consider your stakeholders. Who will read this documentation, and how will they use it? Here are a couple thoughts on how different stakeholders use documentation and descriptions of their unique needs.
Software Developers: If the main users of your documentation are going to be software developers, you might as well not write it. I kid, but seriously developers do not really need detailed specification documentation, and generally won’t read it anyway. In my experience the best types of documentation for conveying business requirements and rules to developers are simple artifacts like wireframes and flow charts. Those, along with a handful of conversations and some white board time, are generally all you need to get developers building to spec.
Testers: The underpaid, understaffed, and underappreciated grunts of the software world ensure that our software works in all those edge cases and produces predictable results. It’s been my experience that these guys and gals often need highly detailed documentation to get the job done. Detailed documentation gives them specific details they need to write test cases with predictable outcomes. Furthermore, testers are often located offshore, complicating direct communication and making detailed documentation all the more necessary.
Business Users: When process owners change, aside from wanting to scrap the entire process, the new owners will generally want some documentation that explains both the purpose of the business processes and how the software work. Ideally, process owners and business stakeholders can provide much of their own documentation. To meet these needs, a business case can explain the purpose and goals of the process/system, and some operating procedures or guidelines will provide an overview of the business process. Finally, the analyst might want to provide a flow chart and some notes explaining how the process and system fit together, along with appropriate references to the more detailed documentation if it exists.
Future Analysts: Often times, I have found myself cursing the people who left behind no documentation on the workings of the system I am expected to modify. Don’t be that guy. When reading historical documentation, analysts mostly need to be able to glean business rules, the project justification, and some idea of system processes from documentation. These can generally be derived from some combination of the other types of documentation listed above. As long as the other documents can cover those subjects, there probably is not a need for documentation specifically intended for future analysts.
Unfortunately, each set of stakeholders requires a different type of documentation. Sometimes this means that we analysts need to write multiple sets of documentation for the same project. In the end, analysts should aim for just enough documentation get projects accurately built and tested, and enough documentation to ensure future stakeholders can understand what was done.
If you’re interested in more on this subject, Modern Analyst has a great article on requirements specification in an Agile environment that touches on this, as well as recommendations for methods to communicate requirements.
Information management is a relatively new field. What is it like to get a job with a degree in Info Management? First we gave tips about learning new software for a job, and now we’re helping you think about networking.
My first rejection letter came via email. Over three months of job searching, I placed 50 applications, received about 13 rejection letters, and didn’t get any interviews. The lesson I learned: even if your resume is professionally made, when you apply online, you’re only one more resume in a company’s growing pile of resumes. You are not a person to the recruiter or the hiring manager.
I played what I called “the numbers game” online. With the numbers game, I was applying to seven or eight jobs a day, on my more motivated days. I pored over job listing sites and searched company websites, seeking direct-hire positions. What I thought I knew: if I played the numbers game, I would eventually get an interview somewhere.
Two months ago – almost serendipitously – I landed a position as a Data Analyst with an international non-profit organization. Getting hired couldn’t have come at a better time; in December, I have to start paying back student loans. The numbers game may have panned out eventually, but getting hired, as it turned out, resulted from talking to someone in person.
What I know now: as useful and necessary as online applications are, nothing compares to meeting someone face-to-face. A hiring manger needs to know you’ll be a great fit for the team and the company. And really, as a job candidate, you need to know if the company and position is a great fit for you. This is why recruiters and hiring managers prefer to meet you in person instead of skimming your online resume. And why you should, too.
This recent lesson is in contrast to my behavior in graduate school; the entire two years I spent at the University of Washington, I had been advised over and over to get out and network. My professors and program alumni all said the same thing: networking will get you further than online or paper application will.
So why didn’t I follow their advice when I was there? Frankly, it’s because I often found myself wondering: What does it mean to network? It took some trial and error, but I figured out what worked for me, and here are some things you can do to get on the fast track to finding a job:
Attend conferences, school events, and other networking gatherings. These are great places to meet new people and let you do what’s really important: talk about you (and even just practice talking about you). Just be yourself and talk about what excites you the most. The people you meet and the relationships you build will lead to a job offer, I promise you.
Build a portfolio! Start during your first quarter/semester of school and save all of your projects. Papers you write, pictures you take, and videos you produce: save them all! Go online and create a portfolio of all of these things. Make sure you add the link to your resume. Don’t have any website building experience? That’s OK. There are plenty of free services online that will host and create your website for you.
Talk to friends, family, and neighbors about your job search. You never know where an opportunity will arise; it could come from the least likely of places and you’ll miss out if you don’t speak up.
Leverage social networking. Get on Facebook and Twitter (if you’re not already) or, if you host your own blog – whatever it is – let the world know you’re looking for work. In fact, once you’ve created your portfolio, share the link with everyone. Remember: showing is always better than telling.
Finally, in general, think of networking as an opportunity for you to get creative and market yourself when you are job seeking. Networking enables you to really dive in, exploit your strengths, and articulate what separates you from the rest. Most importantly: sitting at a computer limits your ability to use these skills, to let an employer see the real you and “wow” a hiring manager with your talents.
This post is about Wikileaks, without being about Wikileaks. We know the most recent Wikileaks release was an overwhelmingly large set of data, generated by a fairly low-ranking intelligence analyst, and contains potentially sensitive information. The aspects of the Wikileaks scandal that fascinate me, however, are the human and organizational factors affecting data security.
Why did Bradley Manning do it? He must have known he would be subject to a long prison sentence (at best), and made no efforts to hide his actions. Assuming he was acting rationally, the benefits he imagined from doing so outweighed the prospect of certain punishment. Manning must have evaluated the volume and nature of the data at his disposal – data owned by his organization, effectively the U.S. government – and chose to place his individual motivations above those of the organization to which he belonged.
His own Wikipedia page and various media reports describe Manning’s “disillusionment,” and some opinion pieces paint him as “disgruntled.”
Disgruntled at the age of 23?
This fact points to the causes of the leak: it’s a people problem, more than an information problem. This includes security clearances, i.e., how many eyes need to see the information, but the solution is not about security clearances. Safeguarding organizational data such as that shared in the Wikileaks event is ultimately a management issue, for the following reasons:
A change in employee behavior is a crucial signal to management. It would surprise me if Manning’s behavior changed overnight from unassuming analyst to data thief. A good manager should look for changes in employee behavior that signal a shift in attitude. Furthermore, a manager should ensure he has enough information to act on if restricting or revisiting information flows becomes necessary, particularly in the event that an employee’s risk profile changes.
Digital natives exhibit different workplace values than their older counterparts. At 23, Manning is a digital native. Individuals under the age of 30 have grown up with technology in a world where a sense of possession is poorly defined in digital terms. Digital natives have a different notion of right and wrong in sharing information than previous generations of workers, even when information is proprietary to their organizations. Generation Y is also less loyal to organizations, and expects authority figures to earn their respect, rather than commanding it automatically. (I realize the Army is a very special kind of organization; however, the military cannot claim to be modernizing for warfare in the Information Age and expect to preserve outdated management philosophies, particularly when recruiting overwhelmingly from the digital natives demographic.)
Technology itself distracts from the human issues. Security specialists discuss access protocols and authentication procedures, but focusing on such issues is like staring at the end of someone’s finger when she points to a mountain in the distance. Internal data leaks are a real threat, but they are also perpetrated by people. The Information Age is changing the relationship between people and organizations. Adding to the urgency of the problem, today’s technological capabilities allow people to share and act on information as quickly as they think to do so. When “think it – do it” is the norm, it is important for an organization’s management to communicate expectations about information use and dissemination and to assess and monitor, in an honest way, the risks associated with information flows.
The landscape of information behavior is undergoing a major shift, and technology is merely an enabler of behavior. An individual’s ability to act impulsively, and with powerful tools that can execute enormously impactful actions digitally, should prompt organizations to manage closely the human aspects of internal security threats. It takes one weak link in an organization – unmonitored, disillusioned – to commit a destructive act with sensitive data. Although individuals should be empowered to make ethical, informed decisions when acting on behalf of their organizations, management culture must continue to adapt to the new Information Age, and its digital natives.
One of my fond memories of working in Finance MIS was a short-lived tradition called “Nerd Lunch.” I and another analyst would log in to a net meeting and work through complicated SQL queries every few weeks. We would brainstorm solutions for ongoing information problems facing our department. I ask you: Has there ever been a more appropriate moniker for an event?
The analyst was my guru. With her help, I went from landing a job where I knew next to nothing about the software I would be using to finding solutions for decision makers in our organization.
I’m writing this blog post because it’s great to get excited about a job posting that sounds perfect in terms of industry, position, and advancement opportunities – but then it’s disappointing to worry about qualifying on ‘Preferred’ software experience. Worrying about software experience may even keep a job seeker from pursuing a position. What follows are tips I’ve found helpful to first get through an interview without perfect software experience, and then to get up to speed quickly in software skills once hired.
For an interview: Likely you will be facing a hiring manager when answering questions about software skills. Before the interview, it is possible you may be able to fully investigate the software – say, with a free trial for more common products. Barring that, prior to sitting down with the hiring manager, I suggest Googling the software listed in the job posting to find its specifications, as well as those of competing software products. This is a particularly helpful step with specialized software, such as enterprise management, accounting or asset management software.
Investigate the capabilities of the software to understand the functionality, and then come up with (intelligent!) questions related to the software’s application to itemized job responsibilities in the position listing. After all, once you get the job, that will be your contribution to the organization. It is most important in an interview with a hiring manager to demonstrate understanding of the role and to express critical thinking skills related to a position’s responsibilities.
Once hired, read a book: Find a beginner’s guidebook to the software if you can. Also, read it. (NOTE: No one really thinks you are a dummy when you read those Dummies books.) Rather than buying it new, I suggest checking out bookins.com, half.com, or posting an ad on Freecycle for a used copy. I’ve always found that starting with these books gives a good comfort level for tinkering in the software, at which point you are ready to sandbox.
Sandboxing: This is when you’ll start breaking existing tools in a calculated way. Set up a dev environment for this step, whatever that may be. For tools that use scripts, like VBA, or query language, like SQL, pretty much everyone learns by stealing snippets from existing tools and modifying for new applications. This is the sort of stuff you can do while waiting on a batch of project work or during down times in cyclical reporting periods. Please do not underestimate the “Help” tool in a software package; these tools tend to get more useful as your grasp on the software jargon strengthens (ironically). There’s no shame in using company resources to iterate and build on your technical skills, particularly if you are the type to check Facebook or text during working hours.
Find a guru: A guru is different than a mentor. This is a person whose geek runs deep, but who has enough patience and time to answer your technical questions. A guru will also have excellent problem-solving skills, in that she (or he) can help you find answers to existing problems by walking you through previously applied solutions in the software tool. Surprisingly, perhaps, a real guru won’t do things like grab your mouse and make a quick fix; that person will have a conversation with you, explore the scope of the issue, and explain in plain language what you need to do. You will learn to deepen the relationship with increasingly thoughtful questions about the work at hand, eventually adding value instinctively. In the long run, a guru’s approach will ideally make you a better thinker.
When this person helps you, be sure to recognize her. Buy her coffee. Send a thank-you email to her boss. Write a blog post about her. Someday, if you care to, you’ll be in the position to act as a guru.
I hope this makes learning new software (or becoming an expert in familiar software) more attractive and less painful. The software is just a tool for the tasks at hand. In the end, you are the element adding value in the position, first by applying software and later by sharing your knowledge.