Business Technology Consulting

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?

Last time we took a look at the first of two main concepts that of User Experiences Practices—Personas. I hope you are able to see the power that Personas can have for an enterprise application development team. Let’s now take a look at the second concept—Usability testing.

As I noted often an application with a new user interface, or changes to user interfaces are often put into place without the end users ever seeing the interface, or changes to the interface. This can lead to the users not liking or using the interface.   This outcome can be changed by conducting some Usability Testing during the design of the interface or changes to an interface.

Usability Testing is done by selecting three to five persons from the user community, usually from the primary or secondary user group of the user interface, and have them test a mockup of the interface. No more than five users are necessary for usability testing as you will receive decreasing benefits from additional users. Also, you may have to run more than one round of usability testing. Take the results of the first round that suggest changes are needed, make those changes to the mockup and run another round of usability testing with different three to five users.

The idea of Usability Testing is to create an interface that is intuitive for the users to use. So you will create a mockup of the interface, it does not have to be functional a paper mockup will do. Just so the users get an idea of what the interface will look like. You will also create user scenarios to have user perform tasks using the interface. Show them the interface and ask them to do the tasks. Do not give them hints or tell them how to do the tasks, you wish to see how intuitive the use of the interface is. If they take a long time to figure out how to do the task or have questions on how to use the interface then the interface needs designed to be easier for the user to use.

Using the two concepts of User Experience Practices will help your application development teams design more user friendly interfaces. Are you ready to design for user experience?

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.

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.

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.

ESI International, a premiere education provider in the fields of Business Analysis and Project Management; and an Endorsed Education Provider (EEP) of the IIBA® held an educational webinar in which they laid out the “Top 10 Business Analysis Trends for 2011”. Presenting these top 10 trends was Glenn R Brule, CBAP, CSM, Executive Director of Global Client Solutions for ESI International. ESI’s Top 10 Trends for Business Analysis are:

1.      Business Architecture will be the primary focus of business analysts

2.      Business Analysis will guide the surge in cloud computing  

3.      Requirements management and development (RMD) will lead in delivering smart business perspective  

4.      Business Process Modeling Notation (BPMN) will solidify its reputation as the industry standard

5.      Agile success will go to those willing to break with tradition  

6.      BAs will be recognized as the critical change management proponent to avoid troubled projects  

7.      Resurgence of Centers of Excellence

8.      RMD will be essential to regaining market share

9.      RMD will continue to struggle to define itself

10. RMD will require better balanced competencies

These trends show a bright 2011 for the Business Analysis profession. As businesses strive to remain competitive, increase efficiencies and regain market share in the improving US and world markets Business Analysts will be critical in examining the inner workings of organizations, model those processes and help businesses resolve roadblocks to its strategic initiatives. I believe we shall see increased emphasis put on process modeling and other “hard” skills over the soft skills previously sought in BAs. I am not sure we will see a great resurgence of BA Centers of Excellence but BAs will be required to find a structured yet flexible approach to requirements management and development that help organizations find those increased efficiencies.

Those of you who follow my ramblings know that I have been a strong proponent for Enterprise Analysis and the strategic value of the Business Analyst within the organization.  My views can be ascertained from my previous articles:

BA: Business Alignment for the Organization

Business Case vs. Project Charter; Do You Need Both?

Business Analysis has far reaching impact on the Organization

IT Governance Needs to Change to Gain a Competitive Advantage

Making the Business Case for an Internal BABOK

Building the Business Case for the Business Case

Business Analysis: Building the Bridge

BA; The Architect

Yet, as the International Institute of Business Analysis (IIBA^®) grows in recognition, I find that many organizations, especially SMBs, do not utilize the BA role for strategic value.  Most organizations have BAs and use them in their traditional tactical role on projects in requirements gathering and solution validation; but very few organizations utilize the BA role for Enterprise Analysis.

As the framers of the Business Analysis Body of Knowledge^® (BABOK^®) sit down to write version 3.0 of the BABOK^® Guide and continue to work on the Enterprise Analysis extension to the BABOK^® Guide, I hope that they put particular emphasis on this very important BA role.  Perhaps companies will take note and start to utilize their BAs to help the organization achieve its strategic goals.

The BABOK^® Guide does mention tasks that a BA may perform under Enterprise Analysis, including but not limited to Capability Gap Analysis, Market Research and Feasibility Studies.  However, it falls short of describing how the BA should perform their strategic duties.  The BA having performed the Enterprise Analysis task(s) builds a business case, resulting in a Business Case document, for a solution to resolve a business need of the organization identified during the Enterprise Analysis activity.  This business case is presented by the Project Sponsor to the project review board (governance body) for approval to proceed with the project.  The Enterprise Analyst (EA), having performed the up-front analysis that resulted in the business case, should sit in support of the business case and the Project Sponsor.  He/she should be available at the presentation to answer any questions the governance body may have concerning the business case.

The EA also works with the governance body to ensure that every business case brought up for approval has traceability back to the organization’s strategic goals and objectives and that the most optimal mix of projects get approved that best contributes to the organization’s strategic goals.  This would be a portfolio of projects that do not conflict with each other and advances the organization the best in achieving its strategic goals.

When we see organizations utilize the EA role more effectively perhaps we will see better project success rates in the Standish Group’s CHAOS Report.
 

For those of you who have wondered where I have been, I am happy to say that I was in the Bahamas.  I took a long deserved vacation with the family to the Bahamas.  The cruise and the trip were excellent.  Now I come from the 80 degree sunny weather of the Bahamas and Florida to the 20 degree snowy weather of Cincinnati, it just doesn’t seem fair.  No, I was not in the Bahamas for a month or two months, but getting caught up with everything takes time.

Recently, I have been pondering the question “Has IT become irresponsive to business requests?”  As I go from organization to organization I look at the time it takes from request to solution implementation and I am dumbfounded.  For those of us who have been in application development services for awhile remember that what use to take a day now takes a week, or longer.  Yes, we have things like Sarbanes-Oxley (SOX) and other regulations to thank for this; but also I see that organizations themselves put so much process into their developing of IT business solutions, that the time to fill a business request gets longer and longer.  Let’s take a look back to see how this happened.

In the beginning there was chaos.  The business manager, needing a widget, made a request to the IT manager, the IT manager handed down the request to the developer, who spoke this language called “techie”.  In three days, the business manager needing his widget, went to the IT manager and asked “Hey, where is my widget?”  The IT manager replied, “I will find out for you”.  He went to the developer and asked ‘Where is the widget?”, and the developer handed him a midget.  The IT manager said “I am not sure this is what he wanted”.  The IT manager returned to the business manager with the midget.  The business manager said “That is not what I asked for, can’t you understand plain ‘biz talk’?”  He further inquired, “Why couldn’t you tell me when it would be done and stop the developer when he started building the wrong thing?”  The IT manager said “I need help!” and chaos ensued.

Then The Project Manager (PM) stood up and said I can help.  I can put together a project schedule and draw pretty pictures for you that will tell you exactly when that IT business solution will be done.  The IT manager said “I like pretty pictures, yes do that”.  So the business manager made a request to the IT manager for a fidget.  The IT manager handed down the request to the PM.  The PM made a project schedule, carefully drafted a project scope, wrote a communication plan and a risk mitigation plan and made deadlines and milestones.  He then showed all his work to the IT manager who looked at it in awe.  Then the PM handed all his work to the developer who stripped out just the parts he needed to create the widget.  In seven days, the business manager needing his fidget, went to the IT manager and asked “Hey, where is my fidget?”  The IT manager showed the business manager all that the PM created and the business manager looked at it in confusion.  The IT manager said, this says your fidget will be done in two days.  The business manager said, at least now you can tell me when it will be done, but what is taking so long?  So now they have structure to the chaos.  In two days the IT manager delivered the widget to the business manager and the business manager said “that is not a fidget, what is wrong with you?”  The IT manager said I do not understand what you want.

So the Business Analyst (BA) stood up and said I can help.  He said your application development team speaks “techie” and the business people talk “biz talk”.  I speak both languages and can translate what the business is asking for into “techie” for the development team.  The IT manager said “Yes, do that”.  So the business manager requested a zidget from the IT manager.  The IT manager handed the request down to the BA and the PM.  The BA went and talked to the business manager and said “tell me about this zidget you want”.  He made long lists of requirements and definitions of what a zidget is.  Meanwhile, the PM made his project schedule, full of scope, plans and drawings.  The BA went to the PM and handed him all the requirements and said this is what the business means by a zidget.  The PM handed all that the BA and the PM had created to the developer who stripped out just the parts he needed to create this zydget.  In ten days, the business manager needing his zidget, went to the IT manager and asked “Where is my zidget?”  The IT manager showed the business manager all that the PM and BA had created, who looked at it in great confusion, and stated “Is that what I asked for?”  The IT manager said “Yes it is, and it will be ready in two days”.  The developer showed the finished zydget to the BA, who stated “this is not quite right, make a little change here”.  So the developer did as the BA said.  In two days the IT manager delivered the zidget to the business manager, who declared “Look you got it right!”

The above story does not really account for the time and effort that Quality Control and Production Change Control put into the process.  So it is easy to see why a day has become a week, or longer; and make it appear as if IT has become irresponsive to business requests.  However, in most organizations the above is the normal process, we call project life cycle (PLC), to get an enterprise application development change made.   Most organizations have emergency procedures that circumvent the normal procedures to get a change made quickly.  More and more I see those emergency procedures being used.  What does this cause, new production change control processes and validation, which usually translates into more people.  So what can be done to improve this process?  Go back to Chaos?
 

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.

 

I know some of my application development colleagues my say “heard it”, but a virtual desktop is cool! We are currently running Windows XP as our company standard. We moved our 9 physical servers running Windows 2000 on ancient (and failing hardware) about 2 years ago. Most of our clients are currently on XP, but some are looking into moving to Windows 7, and one is going to Vista. When my application development friends stop laughing, they are doing this because they have certified their testing with Vista, and they will have to re-certify with Windows 7. They want to move to Vista now, and move again in a year or two.
We can just follow the Windows upgrade path, but given the success of virtualizing our servers, my boss gave me the green light to review our desktop strategy. Some application development and management people would say why? Well it gives us flexibility in what we can do. If we just move to Windows 7, and our clients are still on XP, then we are too ahead of the curve in terms of support. We do have some XP only development tools, so why not just keep them on their OS? With a virtualized desktop, we can run any OS we want. If our clients want us to run specialized software, we can set up an OS just for that client. The other big change is that we are using Ubuntu 10.4 as our host operating System. This is to reduce the memory requirements, but it has other great side effects. Our consultants can learn (at least the basics) of a new OS! If they are under constraints, they can fire up their Windows VM and get to work, or they can do the basic stuff (surfing, checking email) on Ubuntu. In time they can learn how to install packages and other tasks without disrupting productivity. The can even use Windows 7 and learn it too. The best side effect (for management anyway) is that we can still get a lot of mileage out of our 5-7 year old laptops. Our laptops have 2 gigs of RAM, so even if we went pure Windows 7, we would have a performance hit, especially when you fire up an IDE like Eclipse! The more I play with Ubuntu, the more I like it. I will probably use it as my main OS, but others can use XP, Vista, Windows7, or whatever we can virtualize. Choice is a great thing!

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.

• 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.