Cincinnati IT Jobs

We recently had a situation where one of our candidates was working with more than one firm.  This is not too un-common; I have touched on this subject before in this post here.  The other firm did not do a very good job of presenting this person.  They probably slapped their logo on his resume and sent it off to the client along with a number of others that “looked good”.  The candidate did not hear anything from the other firm. 

We, on the other hand, took time to understand this person and used our Now you know^TM assessment to get an un-biased gauge of his skills.  We found him to be very strong in the skills that several of our clients were looking for.  We talked with him on where we would like to present him and that’s when we learned of a potential conflict.  A quick call to the client confirmed the client was working with another firm as well and if he was submitted by them, they would get the credit.  BTW, what’s his name?

Fortunately, we are members of Techserve Alliance and industry best practices in this case call for the candidate to decide who should represent him at the client.  We have a Right to represent form that we had the candidate fill out for this client.  That way there is no conflict. 

The moral of the story is this: If you are a candidate, make sure the firms you are working with are doing a good job of representing you and know where they are sending your resume.  We recommend that you work with no more than 2 firms.  If there is a conflict, then you should decide who is doing a better job of representing you.

If you are on the hiring side, and hiring for IT, then hire an IT staffing firm, not someone that does several types of jobs.  Don’t let them sell you on how deep their database is, according to the latest Techserve Alliance operating metrics report, less that 30% of the positions are filled from their own proprietary database.  (Ours is over 50% because we are focused on IT in the Cincinnati and Dayton areas).  We all have access to the same internet resources.  If all you needed was a stack of resumes that has been poorly scrutinized, most staff augmentation firms would be fine.  But you don't have time to cull through 20 resumes to find the person with the real experience.  Isn't that what you're paying that staffing firm to do?

Obamacare  is a topic that is usually not discussed in most IT (Information Technology) departments.  Unless your business is healthcare related, why would you?   I’m sure there is going to be more discussion about it in the coming year. 

Most people know that Obamacare will be fully implemented next year.  What most do not know is that this year is the look back year.  The look back year will determine the number of employees an employer has. This number will determine what is mandated by the law.  There is a lot of discussions going on right now in the executive suite about head count, specifically how to reduce it.  I was just in a meeting this morning where the topic came up.  IT departments are not immune to the discussion.  So Mr. IT Director, what are you going to do when you have to cut X number of FTE’s? 

Fortunately, we have some solutions like Talent on Demand and CIO on Demand

One of the critical roles of the Business Analyst (BA), or Enterprise Analyst (EA), in the area of Enterprise Analysis is to identify business need. There are many factors, or many ways that the BA can identify what the business needs. It can be a result of market research or an identified new opportunity brought about by actions of a vendor or competitor.   It could be derived from a strategic goal or initiative of the organization.  It could have come from a business user complaint about a current system issue and/or the subsequent Root Cause Analysis. It could also be derived from an Enterprise Analysis activity that the BA performed, such as Capability Gap Analysis, SWOT Analysis or Product Feasibility Analysis.

If this vital role is not performed than the organization in Cincinnati, Dayton or other business community would not realize the benefits of identifying some business needs that need to be addressed, possibly gaining greater competitive advantage, possibly achieving strategic goals or taking advantage of an opportunity presented by the market.

Once identified, the business need should be documented in the Business Case of a project to develop a solution for this business need. The business need defines the problem for which the business analyst is attempting to find a solution. The way the business need is defined determines which alternative solutions will be considered, which stakeholders will be consulted and which solution approaches will be evaluated. One pitfall that many business analysts fall into is trying to define the business need by the solution. They start with the solution first instead of the problem first. This reduces the solution alternatives that receive consideration and may bring a lesser valuable solution to deployment than what could have been achieved. So starting with the business need (problem) and solution scope, then developing alternative solutions will bring the most valuable solution to the organization, and the business analyst’s recommendation, to light. 

We all learn from our mistakes, what pitfalls to developing the Business Case have you encountered in your career?

Last week I began to demonstrate the value a Business Analyst (BA) brings to the table in the area of Solution Validation by talking about how they bring value by ensuring the thorough testing of the solution prior to implementation.  Let’s continue in this area with an often overlooked and underutilized task of the BA “Assessing Organizational Readiness”.

It would be unfruitful for an enterprise application development team to take a project through the project life cycle (PLC) and implement the solution if nobody in the organization is going to use it.  I have witnessed many times a solution gets implemented and the business users don’t like the new process and often times find ways around it.  Business users try to continue on a path of “doing it the way we have been doing it for years”; which makes the job of the BA more difficult as he/she is the Agent of Change within the organization.  To get the business users out of that mindset and accept new, more efficient, ways of doing things is one of the goals of assessing organizational readiness.  This task is centered on identifying whether the organization, and the people in it, is ready to effectively use a solution ready for implementation.  The Business Analyst should identify the forces that support and oppose the proposed change to the organization.  In this way the BA can work to mitigate the opposition of the change, by identifying any training needs or other techniques that will make implementation of the solution go more smoothly and be effectively used for its intended purpose.

Some of the techniques that a BA may use to assess the organizational readiness are Data Flow diagrams and Process Models, to show the change the proposed solution will have on the organization and business users; Organizational Models to help identify stakeholders or groups of stakeholders that will be affected by the proposed IT business solution; Focus Group, Interviews and Surveys can help identify business users’ concerns about the proposed application solution; Risk Analysis helps identify all potential risks to the organization for implementing the proposed solution and develop a mitigation strategy for each risk; Force Field Analysis to identify the forces for and against the IT business solution; and SWOT Analysis to identify the organization’s Strengths, Weaknesses, Opportunities and Threats in preparing for the proposed change.

When doing these techniques to identify the organization’s readiness to accept the change required, the BA needs to be aware of the Culture of the organization and the impact the proposed solution will have on it; Operations and how the IT business solution will change how the organization accomplishes its processes; Security, physical and electronic, how the changes the solution will bring about affects the security of the organization; and Stakeholders, stakeholder groups, locations, functions, processes and concerns in relation to the enterprise application being affected.

An organization of Cincinnati, Dayton or other business community can benefit by effectively utilizing a BA for assessing the readiness of the organization to accept and effectively use an IT business solution by enabling necessary change management practices, decreasing solution implementation timelines, freeing up other project resources to move on to other responsibilities, identifying training needs and assists in identifying transition requirements necessary for solution implementation.

Do you do any type of Organizational Readiness Assessment prior to IT business solution implementation?

This week we began talking about the role of the Business Analyst (BA) and how that brings business value to the organization. This is not limited to Cincinnati and Dayton.  There are many roles and tasks that a BA performs for an organization.  Yesterday, I talked about the value of identifying all stakeholders, and thereby all requirements, for a project.  Today, I will talk a little about Stakeholder Analysis.  Now the question has been asked, how does a BA perform Stakeholder Analysis?

There are multiple ways a BA can perform Stakeholder Analysis, two of the most common are the RACI matrix and the Stakeholder Map.  The RACI matrix identifies each stakeholder’s responsibility(ies) for a given task or deliverable.  Each stakeholder will be (R)esponsible, (A)ccountable, (C)onsulted and/or (I)nformed for each task or deliverable.  You would have one and only one stakeholder responsible for a given task or deliverable, but multiple stakeholders could be held accountable, consulted during or informed as work continues.

A stakeholder map is a visual diagram of relationships of stakeholders to the solution or to one another.  The stakeholder map can be in one of many forms, including the target diagram, onion diagram, stakeholder matrix and others.  The diagram depicts interrelations and sometimes communication lines between stakeholders.

Other methods of identifying stakeholders include interviews or brainstorming with known stakeholders could identify other stakeholders, organizational charting, Process Modeling, Requirements Workshops, Risk Analysis, Use Cases/Scenarios and User Stories.

This is how the BA performs Stakeholder Analysis.  This identifies all possible stakeholders for a project at the beginning of a project; thereby reducing unnecessary rework and frees up project team members to move on to other work.  This can sometimes be traced to reduced headcount within the organization.

I have outlined the common methods used in Cincinnati and Dayton companies.  These methods are used outside our area as well.  So the question is: What other methods of Stakeholder Analysis have you used in your BA career?  How did that add value to the organization?  I invite you to respond with any comments or other ways BA's bring value to an organization.  Reason number two:  Stakeholder Analysis.

We recently closed a deal that was a real team effort.   What was really special about this team effort was that it included our client.  They worked with us in a completely collaborative manner (as partners should).   Our search was for an IT job that required knowledge of PHP and SQL.  In addition, the person had to be a cultural fit in our client’s organization.   We do not bombard our clients with resumes and hope something sticks. Having been in IT for over 30 years and interviewed thousands of people, we can do a pretty good job at narrowing the list down.

We found a couple of good candidates, one whom we have worked with before on a project who was a very senior person and the other was more of a junior person. The junior person was interviewed by the client first and the feed back was that we absolutely nailed the cultural fit, but there was some concern about the technical skills.  We are able to validate technical skills very quickly with our Know you KnowTM process, so we had to convince the client that their evaluation was off the mark. 

Most technical interviews are very subjective and if the candidate does not give the exact answer the technical person is looking for, they question his/her abilities.  Another common problem is where stump the programmer is played.  Our assessment was this person was proficient in the skills needed.  Since the client validated the soft skills, we just needed to demonstrate that we had given them the almost perfect candidate. 

After talking with our client, about our findings, we offered to give their senior developer (who was not convinced) an assessment.  They agreed and the results could not have come out better.  Fortunately, their senior developer scored better than our junior developer candidate, but not by much.  The results also showed that in the areas where their developer was not as strong, our candidate was very strong.  Our opinion was they would compliment each other very well.   Their senior developer said, “The test is very thorough, but at the same time it mostly avoids asking some of those “obscure” questions that don’t matter very much.  I appreciate the nice balance of questions that were asked.  I will re-review the test result information that you sent us…”

This is a new client for us and we were able to bring value to them and we all worked very well as a team in a very collaborative manner.   It’s refreshing!!

Weary Cincinnati/Dayton IT job seekers hope it’s true. Politicians declare that it should be true. Parents of young graduates with Computer Science degrees need it to be true. So is it? Are businesses beginning to backsource (bring IT services that they had offshored back to the U.S.) in significant ways? What about outsourced jobs? Are those moving back in-house?

This month, STAR BASE invites you to help us answer these outsourcing and backsourcing questions by participating in our 2011 Pulse Survey. This brief and confidential survey will go a long way in helping us all better understand the outsourcing/offshoring strategies businesses like yours are embracing today.

And, if you are motivated by swag the way I am, here’s another reason to take our survey. All participants are entered into a drawing for a Powermat wireless charging station. So take a moment, take the survey and share your backsourcing story with STAR BASE.

As a Business Analyst (BA) we are often asked to help design a new user interface and the supporting application to perform a required function in the Enterprise Resource Planning (ERP) system. If you are talking about a web interface you may work with a graphic designer, or perhaps not.  You go off with your business application development design team and create a mock-up of the interface and write a design specification describing how it is to be built. Often the business is not represented on the design team. The design team may pass the mock-up and design specification by a business Subject Matter Expert (SME) before attempting to get it approved; but then they are often approved by a business manager without ever being seen by the end-users that will actually use the new application. Often, features and function are primary concerns when the design is being created. What if we change focus of our design team?

I would like to introduce two concepts to which I have been recently introduced—Personas and Usability Testing. These two concepts are the main concepts of User Experience Practices. The purpose of User Experience Practices is to change the focus of the design team from features and function to the users the new application is to serve and usability of the application. Have you ever rolled out a new application and user interface to find out that the users hated it or even worse refused to use it? Have you heard of times new applications were rolled out but they did not make the user’s job easier or save them time or have any added benefit to the organization? Designing for User Experience would have changed those outcomes. Let’s look at these two components and see how they are used.

A Persona is an artifact (written document) that consists of a narrative relating to a specific user group. It should include a picture and an abstract name that you can live with.  So don’t name your Persona Mickey Mouse, name it Stan, Ned, Alain, or Liza instead. You don’t name them after actual people in the organization but use an abstract name that represents a group of people. Say you are a BA working with a design team that has been charged with designing a new Order Entry system. So what user groups (customers) is your new application going to serve—Order Entry/Customer Service clerks. Yes, the company has six manufacturing locations with at least two Order Entry clerks in each location; the larger facilities have as many as eight Order Entry clerks. So what Personas do you have—one local Order Entry Clerk, let’s name her Emily and she represents eight order entry clerks. In some instances you may find it necessary to have two Personas to represent this one group. The remote site Order Entry clerks will be represented by one or more personas. Who else—what about Sales Representatives that can enter orders as well. The Company has 16 Sales Representatives; 13 of which enter orders on a weekly basis, one who will enter an order or two every month and two who never enter orders. Sounds like three more personas, maybe more. Not considering reports that Sales or Upper Management will want out of the system, as these are often pulled out of the database after the Order has been entered; what about Inventory Management/Purchasing. If an Order Entry clerk enters an order that uses any extraordinary large amount of a raw material if Purchasing is not aware of it until tomorrow’s report comes out, in a day or two the manufacturing plant may be out of that raw material. Therefore, my Order Entry system must send an “alert” message to Purchasing for extremely large orders so that they can account for that material used and keep the manufacturing plant working. How about external customers who have to get the order to our company, they have to call the Customer Service Representative (CSR), how long do they have to stay on the phone with the CSR to get the order in. What if the customer sends their order in via EDI; so an IT persona is needed. Fax, email, XML file—all acceptable ways of receiving a customer’s order; these are often handled by a CSR or IT, but we may want to build an automatic process to enter these customer orders. These methods of order entry need to be specified on the external customer, CSR and IT personas.

The Persona Map—now that you have written all your personas, we need to focus on the important people that our new interface and application will be used to support. So take a very large cardboard poster and draw a target (bulls-eye). In the very center will be our Primary Persona. The one most affected by our new interface, probably the CSR/Order Entry clerks; but you can only have one, so we select Emily. In the inner ring of the target you can place two to three Secondary Personas. In our example, this most likely will be other local CSRs and remote CSRs.   In the outer ring of the target you can place three to four Tributary Personas. For our example, possibly Sales Representatives Personas and possibly IT personas. Now this Persona Map should be hung in the room where the design team will work, or if necessary duplicated and given to every design team member. Now we have changed the focus of the design team from features and function to the people who will use the new interface and application.

This is the first step of designing for User Experience. In my next post we shall explore the second step—Usability Testing. Even without knowing about Usability Testing, can you see the power that Personas can have?

My esteemed colleague, Kupe Kupersmith, wrote an article for BA Times last week stating that “Agile is a Fad”. Now I know that will get a few of my other friends’ up in arms ready to defend their approach to IT project work. I can see the smoke coming out of their ears now. However, if you read Kupe’s article he says that “the word agile is a fad, the agile movement is definitely a trend.” I think it is safe to say that Agile is the hottest trend in IT project work these days. Many companies have switched over to Agile over these past few years and many more companies are considering the move. It has prompted many training courses by education providers. So let’s take a deep, hard look at the Agile “movement” and see if it is a fad, or is it here to stay? Is Agile really any better than Waterfall? What is the next best thing that will come down the pike?

Agile came upon the IT application development and software requirements arenas like a wave, gaining support as it moved. As education providers developed courses to teach IT application development teams to “go agile”, it gained momentum. All this happened in these past few years in very much Fad style. A fad starts very abruptly and gains momentum as it moves, forceful and overpowering; like a wave. Will Agile be here with the wave reverses course and heads back out to sea? This is where the fad loses its zest, when people realize that this is no better than what we had before, or it is swept over by the bigger and stronger wave of the next best fad to come down the pike. The wave reverses course and heads back out to see and disappears as fast as it appeared.  

Is Agile better than what we had before (Waterfall)? I won’t even go there because depending on who you ask, you will get a different answer. You could ask 100 people and probably get somewhere near 50 yes’ and 50 no’s.   That is built quite a bit on personal opinion. The one thing I notice with Agile as it is used today is that it is misapplied by many companies. They talk agile and think that they are using agile, but in reality they have adopted some of the components of agile, such as sprints, scrums and the daily stand-up meeting, but they miss the boat on delivering a piece of working software at the end of each sprint. When your five minute daily stand-up meeting becomes 15 or 20 minutes, all you really have accomplished is keeping your application development team from doing actual work. There are other places that say they are agile, but their sprint is six months long. According to the principles of Agile a sprint should be a couple of weeks to a couple of months long, with a preference to shorter timescale. So a six month sprint is not agile.

The biggest downfall to the Agile principles that I have seen in my experience is the need for comprehensive engagement of the Product Owner. In my experience, Business managers have a business to run and helping IT develop software is not in their job description, they don’t want to talk to the geeks. However, the smart Business managers know that if you don’t talk to the geeks, hard telling what you are going to get out of them. They need more direction than one sit down meeting saying “here is what I need”; and we will not go into the language barrier. If you can’t make IT understand what problem you are trying to solve, then you probably will not get the best IT business solution out of them.

So, is Agile just a Fad? Through all its misapplications and shortcomings, I don’t see agile going away anytime soon. It will not whisk away with the outgoing tide. Is Agile the “Be All of All”? There are some things that you just cannot develop with an agile approach. Some companies have developed a hybrid of the agile and waterfall approaches, so Agile is not the answer to all of IT’s business solutions problems. What will the next great approach be that comes down the pike? My crystal ball is not working today, but it is sure to hit the IT project management world just the way Agile did a few years back. Will IT management be ready for it? Only time will tell.

I am often asked for advice on BA Career paths, Certifications, What technique to use, templates, tools, and so on.. It seems to me that everyone is looking for that “One size fits all” solution on how to perform the role of the BA. The one path up the BA Career Ladder, the one way to go about getting your certification, should I learn DOORS, RequisitePro or Composer?

One thing that I have learned in my many years of doing BA work is that there is no “One size fits all” way of delivering the BA role. Your BA approach will be different depending on the type of project you are involved in. It will differ for a COTS project vs. Capability Gap Analysis. Your approach and tasks that you perform will be different if you are doing enhancements to an ERP system vs. a Vendor Assessment. The techniques you use would be different as well as the templates you may use.

Robin Grace handled the template issue in her article on BA Times entitled “It’s Time for Template Zombies to Die”. Often BAs looking for a template to use will get one from a friend that works for a much larger firm, or a new hire BA brings one with them from a larger firm. The smaller firm uses the template as is, even though there are sections that do not pertain to the type of BA work that the firm does. It may be at times Management will ask “It took you three days to write a two-page document?” Sometimes the response is to make the document 10 pages, and all you have done is added a lot of fluff with no meat. Often, that fluff ends up in the template for the document. Instead of adding fluff, remind Management, “it is more than just writing a document; there is quite a bit of analysis done to make that document right”.  Often people go by what they see and forget about the work done behind the scenes to get to the deliverable. When you do come across a template to use remember this is just a guideline, it can be changed to fit your current situation. Feel free to remove, add or reword sections of the template to make it usable for your task.

I have written many times about the BA Career path. In my last article, I surmised that there are as many paths up the BA Career Ladder as there are people willing to forge them. Getting career advice from those that have gone before you is great and can help you forge ahead, but it does not mean there is one and only one way to climb the career ladder. Advice is helpful, but you are still in charge of your career.  

So in any given situation, instead of looking for the “correct” way to handle the situation, do what any good BA would do. Identify and consider all possible solutions, expand your knowledge so you can assess all possible solutions, identify the risks of each solution and select the best possible solution given the knowledge you have at the time. Remember, the “One size fits all” solution does not exist.

Still a very timely topic of discussion, from the person who wishes to transition into a Business Analysis career who wants to know what skills they must have to be a successful BA, to the new BA who wants to know what skills they need to add to their repertoire, to the Senior BA who wants to know where to go next in their career; everyone wants to know how to improve their skills to get to that next level of their career.

Two of my colleagues take on this subject, Kupe in BA Times discusses soft skills vs. hard skills. He notes the importance of soft skills in being a successful BA. Kupe is not suggesting hard skills are not important, he notes that hard skills is what is going to get you noticed, stand out in a crowd, but it is the soft skills that will land you on that next level and keep you there. After all, nobody wants to work with a jerk.

Laura discusses whether Project Management is the next step in the career of a Senior BA at Bridging-the-Gap. She discusses how this use to be the case years ago but is no longer the only option. In fact, we now see the reverse happening where Project Management professionals transition into Business Analysis careers. For those who have reached the pinnacle of their BA career, besides Project Management, they could move into BA Management, creating a BA Office within their organization, Enterprise Analysis, Management Strategic Consulting, Business Consulting, Business Subject Matter Expert or external IT and Business Management Consulting. There are as many paths as there are people willing to forge them.

Elizabeth Larson will be taking on a similar topic at the Southwest Ohio Business Development Conference in April. She will discuss whether Business Analyst and Project Manager should be one or two roles within the organization. At this very same conference I will be presenting the topic “Improving Your BA Skills: From Self-Assessment to Self-Improvement”. This is where I will discuss the many ways you can gain new and improve current BA skills.   This is a conference not to be missed if you are in the Cincinnati area on April 29, 2011.

This topic has been around for many years and as you can see is still a very hot topic today, getting a lot of press. There is no one way to build your career, forge your own path. Remember you are in charge of your career. Unemployment, downsizing or IT outsourcing may derail your plans for a time, but don’t allow that to stop you permanently. For some general guidelines, as Kupe suggests, develop the hard skills necessary to accomplish the tasks of a BA and get you noticed. Then develop the soft skills that will land you on that next plateau of your career. Remember, that your current job is not your career, it is just your current position in your career; you decide where to go next.  Let your passions guide you. If Project Management doesn’t excite you, good; now you have other options to continue your career.

One of my fellow Techserve Alliance members sent out an article that I thought was pretty interesting.  You can view the original article here.  It reinforced the idea that local talent is important.  STAR BASE, Inc. has always focused on Cincinnati and Dayton IT talent, so I felt validated.  Some of you may think I’m crazy for talking about a Talent Battle while unemployment is still so high.  I don’t think so, because some IT talent is already hard to find.  Here are some key points from the article in winning the up coming Talent Battle.

1. Eliminate Past Biases.  Many companies don’t consider candidates who they have interviewed but declined previously. There is often a strong bias against them, as in, “We interviewed that guy in January, and he wasn’t any good …” Given that most companies don’t have highly refined selection processes; this is an error in strategy.  Most companies’ selection process is very subjective.  For companies to win, they will need to revisit local talent who they may have interviewed previously for other roles.
2. Don’t Overweight Experience and Technical Skills.  Most companies routinely overweight years of experience and technical skills through the interview process.  A question that needs to be asked is, “Is it possible for someone with five years of experience to outperform someone with ten years of experience? How is that possible?” Smart IT service providers will help their customers select on the portfolio of attributes that drive success in a job, being careful to not overweight less-predictive candidate attributes such as years of experience. Doing so will increase the candidate pool that is available locally.
3. Map your Internal Talent.  Now more than ever, developing internal talent is a smart strategy, as it also correlates to reduced attrition. So for those jobs that can be sourced internally, organizations will be well served by doing so, provided it supports the local search strategy.
4. Measure the Opportunity Cost of Key Vacancies.  Understand the business case for paying relocation. There could be a good argument for what jobs might warrant a rich pot of relocation dollars. This will put you ahead of the game.
5. Focus on the Local. Now would be a good time to look at your suppliers and choose ones that are local and focus on the local.  (I think I may know of one…)
6. Outsmart Your Competitors.  Smart companies will quickly recognize that improving the value package offered to employees to attract and keep more local talent carries far greater ROI than buying someone out of their underwater mortgage, or letting a key role in the organization sit vacant.
 7. Keep Your Best:  As always, the best local talent to attract and recruit are the strong performers who are already working for your company. But most companies have cut bonuses, reduced merit increases, and kept job promotions to a minimum in order to control costs during recent challenging economic times.

Now is a good time to think about your Talent Strategy.  Don’t get caught short in the up coming Talent Battle.

 

In an earlier blog post, I wrote about the dangers of working in IT. It is very important for application development people and really anyone who has a desk job to get regular exercise. My shocking moment was when I went to London with my son, and I saw myself walking across Abbey Road. There I am, and my “overhang”! To put more fuel on my weight fire, my boss is doing P90X. He has dropped several pant sizes and is looking good. To figure out how I was to lose weight, I did what all good application development people do, I observe what works for others. I recently read (and saw his picture) that Drew Carey lost 90 pounds in 8 months. His secret for his weight loss was getting on the treadmill for at least 30 minutes everyday, and eating broccoli. I looked at people who run regularly, and they are skinny! So I decided to run and eat broccoli. My diet currently consists of an apple in the morning, turkey for lunch, a banana in the afternoon, a protein shake after my run, broccoli, a small dinner, and maybe some skinny cow ice cream. This may be too much for some, but try these simple things to start: drink water instead of soda pop. Swap out a candy bar with a piece of fruit. As for the running, I go six times a week. I created a “course” at an executive park by my house. My first time, I barely got through a half mile. It doesn't really matter how far you go, just set a goal for yourself. Every day I wanted to go further, and eventually my course became three quarter of a mile. I found this Android app that is my favorite and most useful piece of software I have used. It's called Cardio Trainer. It uses GPS and Google Maps to track your running. It keeps track of you distance, time, and calories burned. I save my workouts, and now I have a history of my runs! In six weeks I am up to 16.5 miles a week while running three 5Ks in my training. I have lost at least 12 pounds (I am sure I have added muscle to my legs). My “overhang” has dramatically decreased, I have more energy, I sleep better, and I feel happier. The point of my story is that we application development folk need to get up and do something. If you have bad knees, try swimming. Find something that will make you active. Set a reachable goal, achieve it and set another one. I want you guys to hang around and read my stuff!

This month I have been exploring the IT and Business working relationship.  It is a hot topic these days getting a lot of press.  STAR BASE Consulting is conducting a pulse survey asking what is the relationship like in your organization.  BA Times notes that your “Customers Don’t Want to Work with You!”  A couple of weeks ago, I looked at the relationship and how BAs could reduce the rivalry, if there is one.  Last week I took the relationship to the Organizational level and described how the Organization can build a unified, collaborative team.

You say Organizational Structure, Seating Charts, Enterprise Analysts (EA) and Business Analysts (BA) are all find and dandy, but what about me and my small IT shop?  I don’t have enough people to split into EAs and BAs.  How do you split one person?  Small-to-Medium Sized Businesses (SMBs) usually have an IT shop of 10 people or less.  Maybe at most 2 of them will be BAs.  I even had one CIO recently tell me that in his small shop he doesn’t really have full-time BAs, but five Programmer/Analysts that do their own analysis.  So we will assume these are the hybrid Developer/Business Analyst role within the organization.  So in this kind of structure, how can we improve the IT and Business working relationship?

In SMBs, where resources are scarce, it is not uncommon for people to perform multiple roles or “wear many hats” within the organization.  In today’s economy, where IT spending and salaries have stalled but the workload has not: IT is getting even more squeezed.  In this situation, when the SMB cannot make one of its BAs the strategic role (EA), or perhaps the organization does not need full-time enterprise analysis activities going on, it becomes even more crucial for the BAs to assist in building a unified, collaborative working relationship between IT and the business.  So let’s look at some of the key points I have discussed in the past two weeks.

Seating Chart - Two Desks

When looking at this seating chart you realize that there is only one person, so you only need one desk, correct?  Allowing the BA to have a desk in the IT Department and one in the business unit of the organization allows them to build a working relationship with each team.  By spending part of the day or week with each team, the BA can understand the challenges each team faces.  Even if the BA can spend only part of his/her time sitting with the business unit that they are suppose to support, it helps build awareness of the daily challenges that the business people face on a daily bases.  This helps the BA identify business needs to improve business processes and make the business run smoother.  This also makes the BA approachable by the business people to assist to work on problems and will help get buy-in from the business people when the BA has analysis tasks that require business input.

Communication is Key

Communication is a key skill for a BA, but becomes even more important in this situation.  The trap that the BA must avoid is the business feeling that the BA is approachable only when he/she is sitting at the desk in the business area.  Or that the BA is available for IT project work only when he/she is sitting at the desk with the IT business solutions development team.  The BA must communicate to both teams that he/she is available whenever they need assistance; it is their goal to assist.  The BA also must represent the needs, desires and limitations of each team to the other.  Make the IT application development team understand the business requirements and why these requirements are needed.  Make the business understand the time involved to make “a simple change” to an enterprise application.  By representing each team to the other, and making each understand the work at hand, whether that is requirements or solution testing, they are creating a shared vision across the organization.

Build the Bridge

Through effective communication of the needs and limitations of one team of the business to the other and representing the each team to the other the BA can build a bridge of understanding between the two groups.  By making each side realize that we are all in this together and desire the same outcome, you can build a relationship of trust and get rid of the “Us vs. Them” scenario and replace it with a collaborative working relationship that brings about better IT solutions to business needs.

Whether in a large organization or SMB, business must go to IT for technology solutions.  Even in an IT Outsourcing situation, there are on-site IT people to directly talk with the business people.  In SMBs, where resources are less and people “wear many hats”, the BA role of liaison becomes more important to overall IT business solutions success.
 

• the job titles on your work history do not reflect your experience in business analysis (they include other titles such as programmer, software developer, financial analyst, etc.) and/or;
• you spent many years doing business analysis work for one company (perhaps even with the title of BA), but never obtained post secondary education, and is finding it difficult to get your resume noticed by other companies.

If you thought your job as an application development person is difficult, try being a consultant. I love my job as a consultant because I am able to affect change, that is, when people want it. The most dreaded phrase a consultant can hear is “that’s the way it is”. Those words have no rebuttal, no further review. It’s the organization’s way of saying “talk to the hand”! My job is to find gaps in code or process and bring them up to the client. Often times the client has fallen into way of doing things that are counter productive, or more likely, have not changed since the process was in place. A case in point, I was having a discussion with an architect about code review. I noticed that they had the Legacy style user, date, and change comments at the top of their classes. I made a review comment that they weren’t necessary, because Subversion tracks the changes for them. It was due to their work process that comments would be lost by Subversion on multiple merges. I mentioned that several high profile companies use Subversion and don’t seem to have a problem. The architect said that research was performed and it doesn’t, and if I have a better solution, I should do my own research before making a comment. I told him that software does indeed improve, and that if research has been done, it should be reviewed periodically to see if the issue had been fixed. I did research the issue, and Subversion did have bug but was fixed, and my client could use comments in their merged code. The key here is that the staff complains that changes don’t get done, but when they are in a position to make it better, they don’t do it. If anyone investigates a new technology or work process it should be DOCUMENTED AND REVIEWED! I don’t know if it will be investigated because it seems like a trivial issue, but the main problem is that the application development people complain that nothing changes. It’s our Culture. Culture is people, and all people, especially application development people can change culture. If there are deprecated methods and TODOs in production code, bring them up in your code review. I don’t accept “that’s the way it is” as a reason. You can’t change a decision for business reasons easily, but you can fix how things get done. If I don’t like the way that it is, I make it better.

See Part One here.  These deadly sins are not limited to IT Consulting in Cincinnati, but everywhere.  I wish that someone would have shared the list below with me earlier in my career.  It might have saved me a few grey hairs and sleepless nights.  I have to admit, I have been guilty of a couple of these in the past, but that’s why it’s called experience.

5. Blame it on Rio.  And I am not talking about the movie, I am talking about pushing the mistake/error onto something else like, the Operating System, another consultant or worse, one of the client’s employees.  While the problem could very well be any of those things, your job as a professional consultant is to find solutions and to set an example in leadership and even diplomacy.  While you may see glaring errors or mistakes and perhaps your way would have been the better way to do something it is best to keep the criticism and commentary to yourself. (See #3 in Part One)

6. Bubble gum and baling wire.  Many times consultants are brought in to fix something.  The last thing you want to do is to take a shortcut that you aren't sure will last. Band-Aids are fine if you know you are coming back to make a more permanent fix. But eventually, those shortcuts will fail and will need further attention and the time to failure is an unknown. It could be the minute you drive away or months later. This is not the type of chance you want to take. It frustrates the client, and it makes you look bad.  You also don’t want to make the client totally dependent on you.  A client told me once that Peter (not the real name) is very talented; the problem is he is the only one that knows how it works and can manage it.

7. Showing up, Gotta Go. (AKA I gotta hangnail).  Once you’re on a gig, most clients want to see you on some sort of regular basis and some might have a “core hours” expectation.  It’s important for both the client and the consultant to know what each should expect.  I once heard a client make a comment about another consultant that went something like this: “Larry(not the real name) runs out of here all the time and uses sickleave for a hang nail!” 

Here is another list that has some similar ideas here.  I’m sure there are others.  So go forth and sin no more!
 

You have probably heard your parents or grand-parents talk about when they were younger and how they had to walk to school, up hill both ways.  When they shared this story with you it was to prepare you for times when things weren’t so easy and to provide you with their knowledge and advice from their hard earned experience. I wish that someone would have shared the list below with me earlier in my career.  It might have saved me a few grey hairs and sleepless nights.  I have to admit, I have been guilty of a couple of these in the past, but that’s why it’s called experience.

1. Bill for time not worked.  This will be the quickest way to end up out of a consulting gig. Make sure you bill the client only for the time you actually work. This can be tricky if your clients are friends. When you go to a job like this, you know there will be a period of time spent socializing, especially when you first arrive. Don't bill for this time. Start the billing period when you start working.  Sometimes clients will have celebrations during the day.  If you don’t want to appear anti-social, by not going, just don’t bill.  If there are any questions, ask the account manager to find out. If you are the account manager, ask your client manager at one of your one to one meetings if it’s ok to bill.  Some client’s have a culture where that is part of the expectation.

2. Negotiate rates and make deals with the client.  If you work for a consulting firm, you know there are channels for clients to go though to make requests..  Most firms have some sort of account manager to handle those issues.  Direct the client to the account manager.  I had one consultant that actually went so far as to look in the client’s AP system to see how much we were getting paid and then wanted to negotiate a higher rate with the client.  This particular action did not end well for the consultant and he has not been able to be considered for other assignments in this client even when his skill set was ideal.  Never, ever work out a side deal or moonlight with a client this can comprise your integrity and jeopardize the trust between  you, the consulting company and inevitably the client.

3. Act like a prima donna.  Yes, you’re good, that’s why you have been hired. I actually heard a consultant tell the client that their employees were stupid.  Hello? You are there to serve those employees.  You don’t know what kind of constraints they have had to work with.  Hind sight is always 20-20.  Its always far better to politely make suggestions. You may find out your brilliant idea was considered previously and there was a very valid reason for it not being implemented.  It’s much better to NOT have egg on your face or your foot in your mouth.

4. Miscommunicate or undercommunicate when engaged at a client I believe that the client should know what is going on with their project.  Many times I have had to be the bearer of bad news.  I also like weekly status reports to let the client know what I have worked on and what I’m planning on doing.  If at all possible I like to let them know a percent complete.  Years ago, I heard another consultant tell the client he was “unit testing”.  The client assumed that meant he had all the functionality done and was testing.  The reality was he had about 10% of the functionality done and was testing just that one small piece.  When the truth came out, it was not pretty.

Tomorrow I will finish off the last 3 sins.
To be continued……