Getting to expert: software learning skills

Picture of whole pie
Getting up to speed on 'Preferred' software experience can be as easy as pie (mmm...pie)

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.

Photo by Caitlinator. Used in accordance with a Creative Commons 2.0 license.

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.

Business vs IT

                After reading the last few posts by nickmalone and Jordan I started to think back about the companies that I have either observed or been employed by and I realized one thing.  There’s a large disconnect between the technical people and the business people.  Now I realize that some of you already know this but hear me out.  I think this causes more problems than many realize.  NickMalone’s post is a great example of what can happen when that gap isn’t addressed, and Jordan’s advice of value added statements is a great way to start fixing the problem.

                As many of you know, I have my Bachelors in Information Systems, which is more of a pure Information Technology degree as it had very few business classes.  I was very happy just learning about how to program and network computers.  The more I learned about networking specifically the more I thought I knew about succeeding in the business environment.  The last quarter of my Bachelor’s degree I took an Advanced Oracle Database class.  That class introduced me to a whole new thought process behind IT, that of IT is there to solve business problems.  Before that I hadn’t really but how IT related to business.  Now some of you may be saying, of course IT is there to solve business problems, what else would it be doing.  But I want you to think about any current or past IT project that you may be on.  What was the purpose?  There are always cut answers of improving user experience or improving the way the business functions but what really was the main goal behind the project.  What was it going to do to help that particular company succeed? 

                That is what I believe is the main point/goal  behind Nick and Jordan’s last posts and what I believe is the fundamental problem in IT departments.  To many IT professionals can make computers do amazing things but they have forgotten that IT is there to help businesses succeed, not the other way around.  I am sure there are cases where it is different but even for companies that specialize in IT consulting or Software design, every IT system should have a purpose and should be directly correlated to a business function.  Once that business goal or function is made aware and focused on I believe that IT projects will be smoother and stop having the Business needs vs. Personal needs issues that NickMalone talked about.

                Now I don’t mean to sound like this is all a problem with bottom-level IT people.  When was the last time you heard about an Executive of a company want to implement some new technology that they read or heard about?  Maybe they heard about want to implement a type of Social Network on their intranet and tell their direct reports to start making a business case for it.  Here again is another face of the same problem.  You shouldn’t make business cases for technology.  You should make “Technology Cases” for business problems.  It might be a slight adjustment but think about how many times technology gets implemented without proper planning so it fails.  If executives, managers and underlings alike were to start the planning and implementation phases of every project linking everything back to specific business problems, businesses would spend less and be more productive overall.

                Now I realize that I don’t have the years of experience of others who are reading this blog so I ask for your thoughts.  When was the last time you started a project that failed?  Did you know the main purpose behind the project?  Was that purpose if you did know it?  Have you seen a difference between projects that directly relate back to business goals and ones that are unclear of business goals?  Now this doesn’t address fully the change management side of things but I but I believe that if employees truly understood how these specific technology implementations helped not only them but the business as a whole you would have less push back, and believe me, being in Security, I know about users pushing back on new technology implementations, but that is a whole different post.

This feedback goes to 11

Guitar AmplifierI used to believe a person could learn more about management from a bad boss than from a good boss: it is easier to articulate what is missing from a working relationship than to notice the efforts of a good manager. Now, I think the truth is that a person always has expectations for a working relationship. The gap between expectation and reality is where learning, through constructive feedback, takes place.

When I left the workplace to attend graduate school full-time, I had a great boss. He was a great boss because he was a master of feedback: timely, thoughtful, economical, progressive feedback. Feedback is a personal information exchange we engage in throughout the working day; because of this, I would argue that maintaining a healthy feedback routine (outlined below) with other individuals is the foundation of a good working relationship.

Good feedback is timely. Work is a series of unending interruptions. It is natural to feel pestered by an employee or team member asking for feedback, but it is also important to support the priorities of the organization. Often, if I procrastinate on giving feedback, it has to do with not managing my own time well, or – this is worse – feeling I do not know the subject matter well enough to give meaningful feedback. In the latter case, my feedback should be: “I’m not the right person for an answer;” a polite “no” can also be appropriate feedback.

Good feedback is thoughtful. If I am the right person to give feedback, then it is my responsibility to really examine the item or issue in front of me. My former boss was good about this: his feedback contained questions that demonstrated he had thought about the item. Alternatively, if he had not set aside sufficient time to look at the item, he would set a time when we could sit down together. Courtesy creates goodwill.

Good feedback is economical. I mean this in two ways. First, feedback needs to be exactly as long as it needs to be. A good feedback routine gives each party a chance to clarify points, if needed, but it is a matter of personal discipline to make sure all points are salient. The second element of economical feedback means that it should be intended to maximize future efforts: it is better to determine at 10% completion that a project adds negligible value than to let sunk costs pile up. Employees and project teams will experience more satisfaction when they know all efforts are regularly analyzed to ensure added value.

Good feedback is progressive. There should be a common thread linking all feedback sessions, particularly between a manager and his employee. If a manager is unable to both criticize shortcomings of a project and praise improvements over time, he is either criticizing too much (which can paralyze an employee’s continued improvement) or leaving out recognition of improvement. As an added benefit, progressive feedback all but guarantees that an employee will know where she stands at regularly-scheduled formal reviews.

No one executes good feedback perfectly all of the time (certainly not me). And everyone experiences an occasional Terrible, Horrible, No Good, Very Bad Day that will derail the best intentions. In the long term, however, simply being mindful about the feedback one gives and receives goes a long way to improve working relationships.

Photo by Andres Rueda. Available under a Creative Commons 2.0 Generic license.

A reflection on the power of UX

“The user is not like you.”

This is an essential mantra when designing user experience (UX) for technology-based tools, marketing strategies, and information retrieval systems. As students of information management, my iSchool cohort members and I have had to unlearn our own instincts for the purpose of better listening to users. Unless we do so, any new system or tool we design may not add sufficient value for the intended users.

In an important contribution to thinking about UX strategy, Samantha Starmer (a lecturer at the UW iSchool and senior manager at REI for information architecture and customer experience) has Tweetedblogged, and presented about offering a holistic user experience. Since an enterprise may reach users through online, mobile, and in-person delivery systems, Ms. Starmer urges designers to think about all of the touch points in user experience. From my own experience, and from what I have so far learned about content strategy and UX, the standard processes for configuring a comprehensive UX strategy include:

  • Understanding the enterprise business model and customer service objectives;
  • Discovering how users find and interact with existing services (each platform is different!);
  • Formulating and delivering a consistent message and level of service for each platform;
  • Analyzing transaction data to grasp weak points in each delivery model.

Coupling good UX with a strong service model can lead to an undeniably powerful experience: I was fascinated by a friend’s blog post to this effect. My friend, Mary, works at a community library to assist job seekers in the Boston area. She spends a great deal of time helping people with online job applications, most often for entry-level positions. Many of the people Mary assists are not native English speakers and few have advanced computer skills. One of her recent blog entries told the story of an online application that was more user-friendly than any she had previously encountered (I would encourage reading the entire post here).

In purely heuristic terms, Mary liked the plain language of the application questions. In addition, she appreciated the feedback from the system, informing the job applicant how much further he had to go with the questions. Small details – an encouraging system-generated message, a friendly take on the drudgery that is an online form – inspired Mary to deem the experience “thoughtful, humane, [and] generous.” These are impressive adjectives. They are also a compelling reminder that designing and implementing UX strategies successfully can garner the trust, and even loyalty, of target users.

Given that UX can have such a powerful effect on a user’s perception of an enterprise, I began to wonder whether there are situations in which offering a “humane” experience is more important than others, depending on the enterprise or user task  at hand. Although a seamless, well-executed UX strategy should be the goal of every user interaction tool, the reality is that most service delivery teams are forced to prioritize projects and enhancements based on limited resources.

How should an organization’s management determine its hierarchy of UX needs? And are there customer service situations where UX is more critical than others (such as complaints in service errors or product recalls)? Is UX more critical to certain organizational missions (e.g., disaster relief, child welfare organizations)? I welcome any insights on these questions – or any other thoughts on UX – in the comments.

On Adding Value in an Organization

There are obvious ways to add value to an organization: productivity by salespeople is generally measured by number of units sold, or levels of service contracted with clients. These quantities show a direct impact in organizational revenue.

The greatest challenge to a new Information Manager (IM) is demonstrating the added value of his work; an IM is a cost to an organization, not a revenue center. Adding to the difficulty, an IM has a wide range of constituents within an organization – such as finance, marketing, and lines of business – meaning he must translate his value add in a variety of operational environments.

For these reasons, it is essential that an IM compose a value-add statement for each project or process improvement. A concise value-add statement with the following points will help to focus a project or process improvement effort from start to finish:

The Impact. Give ‘before’ and ‘after’ statements for the project. The ‘before’ state should be plainly articulated and based in facts. It should also be no longer than one sentence. The ‘after’ statement represents the ideal outcome.

Information Need. Based on the ‘before’ statement, the IM should indicate whether the information is known to exist. Issues with existing information, such as redundancies or gaps, should also be noted here.

Stakeholders. There are two important aspects to this point. First, identifying the right stakeholders will ensure buy-in and participation from the project team. Second, limiting the scope of work and executing rapid iterations of the solution will be easier if stakeholders include only relevant and affected parties.

Revenue or Cost Result. Cutting costs generally means eliminating redundancies. Really exciting projects – the challenging ones requiring an IM to delve into and learn a line of business – should enhance or protect revenue streams. An IM who is able to quantify the financial impact of a project will be better prepared to assist a line of business in process enhancements.

The outline above seems overly simple, but there are several advantages to putting this short document in order. First, the IM may look to the value add statement for guidance when a project threatens to grow to an unmanageable scope. This is essential when working at an organization without established development or process improvement methodologies (such as Agile or Six Sigma). In addition, the exercise of articulating a project in the above terms will assist in communicating casually with senior managers and potential stakeholders for future projects (“What are you currently working on?” asked in the elevator). Finally – what is good for the organization and the project is also good for an IM’s professional development. Annual reviews are an ideal opportunity to review past value-add statements; these documents can also be helpful for updating one’s resume.

If there are any points for a value-add statement I have forgotten above, please let me know in the comments.