Technical Consultants

At STAR BASE, we are application developers.  Normally if an application developer has an issue with how to do something in SQL, a good developer can google it and come up with a quick solution.  But when it comes to generating and using a list of sequential numbers, it appears that the most common method used could be categorized as brute force.  That is generating a table with all known integers, or at least enough to support your application, and join to it.  However, I have found a solution, that admittedly may only work with DB2, that uses recursive SQL to solve the problem. Check this out:

with sequence (seq) as (

  select 1 from sysibm/sysdummy1

  union all

  select s.seq + 1 from sequence s where s.seq < 9

)

select * from sequence

This bit of SQL will generate the following response:

1

2

3

4

5

6

7

8

9

To adjust the ending point, change 's.seq < 9' to the appropriate ending point.
To adjust the starting point, change 'select 1' to the appropriate starting point.
To adjust the increment, change 'select s.seq + 1' to the appropriate increment.

For example to generate a list from 10 to 100 by 5 you can use the following SQL:

with sequence (seq) as (

  select 10 from sysibm/sysdummy1

  union all

  select s.seq + 5 from sequence s where s.seq < 100

)

select * from sequence

This can be used to solve several problems including generating n random numbers, determining the missing numeric keys in a file, and determining the numbers in a range.  Can you modify it to work with your DB? 

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?

One of the most strategic roles of the Business Analyst (BA) is that of a Management Consultant. This role is not drawn out by the IIBA® in the Business Analysis Body of Knowledge® (BABOK®), but it would fall in the Enterprise Analysis knowledge area. Perhaps this role will be given its due recognition in the Business Analysis Body of Knowledge Guide version 3.0 now being developed.

The Business Analyst, Enterprise Analyst (EA) or Enterprise Architect (EA) as they are sometimes called in this role, is often engaged in enterprise wide or market research activities that gives the person great insight into the organization and the market(s) in which it operates. Such activities as feasibility studies, market research, product analysis, SWOT analysis, Capability Gap analysis, analyzing business issues and opportunities, root cause analysis, defining business needs, developing business cases and documenting business processes gives the analyst a deeper understanding of the business and the environment in which it operates that sometimes even the senior management of the organization does not have. This is not saying that business analysts are smarter than business management, it is saying that analysts get deeper into the details of the analysis, which can derive greater understanding of these details about the business.

The creation of internal IT Consulting groups is becoming a common place in companies; in particular a few organizations here in Cincinnati and Dayton in which I have consulted. These groups are often created to perform business analysis activities on the enterprise level; to consult the business on the capabilities and limitations of technology and to consult enterprise application development teams on business needs and requirements. Whether BAs, or the IT Consulting Group, is consulting executive management or business lines management; this is consulting business management to take advantage of business opportunities and diminish business weaknesses and issues.

The creation of an internal IT Consulting Group shows great emphasis to business analysis within the organization. Even if your organization is not large enough to justify a formal IT Consulting Group, giving emphasis to business analysis as management consultants helps the business management make more informed decisions, helps the organization better accomplish its strategic goals and initiatives and enables better change management.

How does your company utilize business analysis for strategic value?

Another area that many Cincinnati, Dayton and other organizations across the country and internationally miss is utilizing the Business Analyst (BA) role in Enterprise Analysis, in particularly in giving assistance in “Project Portfolio Management”.

The goal of the BA in this role is to ensure that the proper mix of projects get approved through the organizational project governance body that best helps the organization achieve its short-term and long-term strategic objectives.  In addition the BA should ensure that there are no conflicting requirements or objectives of the projects being approved.

I worked for an organization that had a formal IT Steering Committee that considered each and every enterprise application development project proposed.  This IT Steering Committee was made up of the business leadership from all business lines and regions of the business and the Senior IT manager responsible for application software development within the organization.  The members of this IT Steering Committee would then rank the projects that were before the committee to determine which projects would get approved; those receiving the lowest ranking would receive approval.  Many organizations may have similar processes, whether they actually take a vote or not; but this organization missed the point because there were no BAs involved in this process.  The projects were presented to the IT Steering Committee by the IT Manager.  The process would have achieved greater results if the Business Executive Sponsor presented the project to the IT Steering Committee as they are most passionate about the business need and that the project would benefit them.  The BA would sit in support of the project as they did the initial analysis that provided the business need and the solution idea for that business need.

However, in this role the Business Analyst, or Enterprise Analyst (EA), would work with the IT Steering Committee or governance body to ensure that the projects receiving approval are the optimal mix of projects and helps the organization best fulfill its strategic objectives.  This EA would present to the governing body the strategic alignment and conflicting issues of the set of projects before the governance body and make recommendations as to the projects that should receive approval based on those criteria.

With this additional information the governance body can make a more informed decision to ensure the portfolio of projects that receive approval are best aligned with the strategic objectives of the organization and reduce the conflicting interests, requirements, issues and scope between the project.  This will help ensure that the organization meets its strategic objectives from year to year.

Does your company utilize the BA role to assist the IT business solution governance body in approving enterprise application development projects?

One of the tasks of a Business Analyst (BA) is Solution Validation, as it is defined in the BABOK®.  This is usually carried out by supporting the testing phase of the project once the entire solution or one or more features of the solution has completed development.  This would depend if you are using the Waterfall or Agile approach to application software development.

The BA should not be executing the testing of the solution, but be supporting the testing effort.  However, in reality in many Cincinnati and Dayton organizations, and organizations across the globe; with limited resources the BA is sometimes put in the role of actually performing the testing effort.  Whether they actually execute the testing or support the testing effort their main objective in this phase of the project is to validate the solution.  The BA accomplishes this goal by identifying acceptance and evaluation criteria, track and investigate issues that come out of the testing effort and performing root cause analysis on defects identified in the testing effort.

Take a step back from the testing phase of the project and realize that while the project was in the development phase, or slightly before, the BA should be engaged and preparing for the testing phase of the application software development project by preparing the test scripts.  In preparing the test scripts the BA should ensure that all the business and non-functional requirements of the solution get tested.  This process assists in providing requirements traceability from beginning to end; from stakeholder to solution.

In being engaged in this manner in the testing phase of the project, the BA can help ensure that the IT business solution meets the business need on an ongoing basis. This happens by reducing re-work, reducing the number of projects necessary, freeing up project resources and increasing the probability of project success as defined by the business stakeholders and project sponsor.

How does your organization utilize business analysts during the testing phase of the project?  Does your organization utilize the Waterfall or Agile approach for application software development projects?  Does your organization reap the benefits listed above of engaging the business analyst in solution validation? Please leave your comments to tell me how Cincinnati, Dayton or other business community organizations utilize the BA in the testing phase of the project.

One of the most important duties of the BA role within an organization is to be the “bridge” or “translator” between the business side and technical side of the business.  It takes excellent interpersonal skills, especially communication skills to perform this role; and the BA is the role within the organization that is in prime position to accomplish this goal.

Organizations whether in Cincinnati, Dayton or other business community, have different internal structures and utilize BAs differently.  Whether the BA reports to the business side or the technical side of the organization, their duty to foster understanding is the same.  Some organizations have BAs that work on the business side of the organization, these BAs are often called Enterprise Analysts or Enterprise Architects; and BAs that work with the technical teams of the organization, these BAs are often called Systems Analyst or Business Systems Analysts.  Often the stakeholders on both sides of the fence work with their BAs and the BAs on the business side and technical side work with each other to drive change within the organization. 

Issues arise when the enterprise application development team does not understand the requirements and their importance and priorities.  Issues also arise when business stakeholders do not understand what the IT business solution that the technical team intends to deliver.  The BA is charged to work through these issues and foster understanding of each stakeholder’s goals, requirements and solution needs.  The BA can best accomplish this goal by developing a shared dialog and vocabulary between the stakeholders.  Each side needs to understand, at least in part, the other sides’ terminology and acronyms.  Shared terminology can go a long way to foster understanding.

By building the bridge of communication and understanding between the different teams within the organization the BA can help reduce project timelines, reduce project communication (overhead) needs, better utilize project resources and possibly gain greater project portfolio management.   So a BA needs to always be improving their communication and negotiating skills to better facilitate understanding within the organization.

Any application development team member, whether in Cincinnati, Dayton or other business community, knows that a software development project goes through many phases, known as the Project Life Cycle (PLC), and through many tasks within those phases.  These include: develop business case, develop project charter, develop project scope, develop solution scope, elicit business and non-functional requirements from stakeholders, requirements management and communication, risk assessment, develop project schedule, develop work breakdown structure, analyze current-state systems, develop future-state models, develop use cases, develop user stories, develop data models, development functional design, develop technical design, develop solution, handle development issues, test solution, facilitate user acceptance testing, implement solution, post-implementation support, handle production issues caused by solution, turn over solution to IT support team. (Quite a list, huh?)  Your list may be slightly different than mine, but I believe the essence of a project has been captured.

The Project Manager is responsible for the project and all these tasks, but to have one person be completely responsible for every piece of an application development project would be overwhelming and considerably increase project schedules.  This person would not only have to perform the management tasks but also communicate progress, schedule, risks, issues and more to project stakeholders. This can be very time consuming.  By placing a second person on the project to off load responsibility for some of these tasks (AKA Business Analyst), you can considerably reduce project timelines and more likely to produce better IT business solutions.  You can also possibly better utilize project resources by more effective management.  The Project Manager and Business Analyst are accountable to work together for project success.  By making the Business Analyst accountable for project completion and the solution meets the business need and making the Project Manager accountable that the project completes on time and on budget you considerably increase probability that everybody concerned will deem the project a success.

Can you pick out the Project Management and Business Analysis tasks out of the list of tasks above?

I have been asked from time to time what a Business Analyst (BA) does, or what is the value of a BA to the organization? That is question is not limited to Cincinnati and Dayton Companies, so let’s explore further. Not just to dictate all the many tasks or ways a BA serves their organization, but make note of the role within the organization and how an organization may get value add from that role. Many people know of the work of a BA within projects, the tactical role, but aren’t as aware of the work of a BA in preparing for projects and their Enterprise Analysis role, the strategic role. So we will start with some of the more known and common duties of the BA and progress to the less common roles.

It is common knowledge that approximately two-thirds of all projects fail. The most common cause of this issue has been attributed to incorrect or incomplete requirements. However, in some cases, the cause can be traced back further to incorrect or incomplete stakeholder identification. Sometimes requirements are not included because the stakeholder that would benefit from that feature or aspect of the solution, or has the business need, is not included in the project scheme of stakeholders. So identifying all the stakeholders of a particular solution proposal or business need can significantly increase project success.

Take the example of a manufacturer who is implementing a new Order Entry system. They may identify Order Entry, Customer Service, Manufacturing, Shipping and Accounts Receivables as all stakeholders for the project. However, if you miss the Customer Complaint, assuming shipping and Receiving departments as stakeholders then you do not have a full picture of the impact of a new Order Entry system on the organization. Data can be made available to the customer complaint system, but if that is not identified at the origination of the implementation project then it would have to implemented at a later date on another project; and the original implementation project may make a decision that would make the availability of data to the customer complaint system more difficult and add cost to that implementation.

So identifying all stakeholders for a project, and thereby identifying all requirements for a project is one role of a BA within an organization. This reduces the number of projects, follow-up work and re-work necessary on projects. This not only frees up the BA, but other project team members as well, to move on to more important projects.

Each day I will be sharing more about the value of a BA.  If you have something that you want to share, please post your response.   Today's BA value proposition is: Identify Stakeholders. 

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!!

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.

If you really think about what the Business Analyst (BA) is asked to do on a day in and day out basis, we truly are as Sanjay Dugar puts it--“A Leader Without the Title”. The Project Manager (PM) is asked to see that the project completes on time and on budget. The Business Analyst is asked to see that the project completes and that the solution meets the business requirements. The PM creates the project schedule and the whole team knows that they are in charge. The Lead BA may create a Business Analysis Work Breakdown Structure (WBS), if necessary, and defines the business requirements for the project. This ‘relationship’ becomes very interesting, perhaps messy would be a better word, if the PM tries to short cut tasks, such as testing or analysis, to keep a project on schedule and/or on budget. After all he/she is the “Manager”, he/she is in charge. What is the “Analyst” to do?

Quite often in their daily work the BA is placed in a position where they must influence a person or group of people without being given the proper authority to do so. So how does the BA go about doing this? This is where the BAs listening, negotiation, conflict resolution and Interpersonal Savvy skills will serve them. Remember, You don’t have to be a ‘person of influence’ to be influential. 

When placed in this situation, where you must now influence a person or group of people, and you are not the “leader” of the group, or you must lead a group down a path to understanding your desired outcome, put a few tools in your toolkit that will help in this situation:

1. Understand the situation, or both sides of the story
2. State the facts Ma’am, just the facts
3. Be flexible, adapt to change
4. Don’t use office politics…first
5. Create shared vision

Understand the situation, or both sides of the story. Remember that there are always two sides to the story. Before you go and try to change the story, be sure you understand both sides of the story, not only the point of the story but the reasoning behind it. A good analogy would be “don’t tear down the fence until you know what it was built to keep in, or out”. After tearing down the fence would not be a good time to find out you have a raging stampede heading for you. Not only listen to the other side of the argument, but understand the point and the reasoning behind that point. Then you can make an informed decision on the path to take from there.

State the facts Ma’am, just the facts. When persuading people, make your point, back up that point with hard facts from authorative sources and draw the picture of how the facts back up your point. I had the opportunity to help a person get better at this. His theory was he like to surprise people with “the big bang”, so he would hold on to the point and lead up to it. By the time he got to “the big bang” the audience had to draw their own picture from the facts to the point. If you leave people to get from point A to point B on their own, some will make it some won’t, and some may finally get there after a number of detours. When it comes to persuading, state your point first, then back it up with cold hard facts. Give the audience the destination first so they can more easily connect the dots. When backing up your point, take the emotion out of the way, use facts. Take the emotion out of your argument, but don’t take away your passion.

Be flexible, adapt to change. Sometimes yielding to the other side is the proper thing to do in light of the facts. You may back up your point with corporate policy, standard operating procedure (SOP), or that’s the way we have always done it; but once you have allowed the other point of view to be heard and the reasoning behind it you may note that this does go against SOP, but it has potential for a positive outcome by reducing the project timeline without increasing the risk of the project. When attempting to persuade, be sure that you are flexible enough that you may be persuaded. Having two parties that can not be persuaded, you can not create a win-win situation. Remember, the party has to win is the organization.

Don’t use office politics….first. We have often heard about the office end-run or going over the head of a person to get what you want. When the time comes such tactics may be necessary, but do not use these as first course of action. You will loose respect of team members and stakeholders if you become known as playing the office politics game. If the conflict is with one other individual, take the case of the PM wanting to short-cut analysis in order to save time and budget, then take the case to that individual first. As stated above, not only understand their point but the reasoning behind their point. If you do not agree, then make your case. Make them understand your point and back up your point with facts. It may take several back and forth’s to accomplish full disclosure of both sides of the story. However, do not let this deteriorate into an adversarial situation. At some point, it may be necessary for you to open this issue with your Manager to handle with the PM’s Manager.

Create shared vision. When persuading use your words, your passion and any necessary audio/visual props to draw a picture for the audience of the desired outcome that you are working toward. Draw the picture in everybody’s mind so clear that they see it as well as you do.  Creating shared vision when influencing others is a powerful tool and the clearer they see the picture, the more persuasive you become.

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.

The big news out of JavaOne this year was that JavaFX script was not going to be used in the next version of JavaFX, but rather baked into the Java APIs. For application development people, this means that you can just use JavaFX directly in your project, without a separate compiler. I am guessing that this will make data binding easier, and help the adoption rate of Swing application development people. JavaFX 2.0 probably won't be out until next summer. For those of you that already have used and enjoyed JavaFX Script, fear not. The code has been forked and been given a new name: Visage. What's interesting with Visage is that the mission is not only to keep the language alive, but to fix the issues and make it a first class language. Discussions on Visage are going on right now. If you ever wanted to get in on the ground floor of a language, now is definitely the time. Your suggestions and efforts can directly shape a language! I hope to see you on the discussion boards.

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.
 

On of the big things all application development people know (and I guess business development people know as well), is how their department is treated by management. This battle has been raging since companies decided to have an IT department. The perfect company would have an IT department that supports the business goals and objectives, and can scale and change quickly. I can hear some application development folks laughter already. It can happen. Management needs to let the IT department make the decisions on the software, hardware and infrastructure. IT must understand the business needs, and managements' objectives. The business needs to articulate their needs, and help IT understand the business concerns. In balance, all departments fulfill their roles and the business grows. I have seen some companies that at least understand this principle, and try to implement it, but most companies have one side dominating the other. I will highlight the major factors for the Great IT Battle.

Management treats IT as a cost center – That is correct only if you are an accounting firm. IT brings great value to any organization by streamlining your business processes, which gives you your competitive advantage. I think that more than justifies the cost.

Business “owns” the IT department – This is very common where the business was mature before IT was around. Management came from the business, and doesn't understand that IT is a separate department. IT cannot scale and maintain their infrastructure, so once every 5 – 7 years there is a project like the Big Dig. If you like complex, over budget projects, continue in this manner.

IT “owns” the business - This is  common with organizations that see growth when they added IT. Usually this is caused by management thinking that IT solves all of the problems. IT supports the business. You still need a business plan and a vision.

Political battles between the three – This is the crux of the issue. Management usually comes from the business side, so when in a political battle, IT loses. Unless management views IT as the “magic bullet”, then IT wins. All political battles boil down to my next point:

Risk aversion - an executive at one of my clients pointed this out to me. All of the executives are the winners of many years of political battles. Any decision made is with the idea that they are near retirement, and will not make any drastic change that could hurt their position.

There are a lot of other factors that nuance these scenarios, so your view to the struggle is unique. We at STAR BASE would like to know where you are in this struggle by taking a brief (17 questions on 1 page) survey. STAR BASE can help your organization call a truce to the Great IT wars.

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!