Business Application Development

Most application software development team members are aware of and work within the framework of Project Scope, but few are aware of the importance of Solution Scope. Project Scope is usually defined by the Project Manager and defines the boundaries of the IT business solution project. It defines what areas will be in scope and what is out of scope for the project. Project Scope may also document the assumptions and constraints noted for the project. For example, an organization, with manufacturing facilities in Cincinnati and Dayton, is considering an enhancement to its customer invoicing application; the project scope could state that “this enhancement is to change the cosmetic look of customer invoices produced by the customer invoicing system”. It could state that this enhancement will affect only one, or a set, of customers and not other customers. The project scope statement should also declare what is out of scope for the project. Such as, “this project will not consider Order Entry and other Customer Service or customer complaint systems, as well it will not consider Accounts Receivable and other financial systems”.

The Solution Scope defines the new capability that the IT business solution will contain. The purpose of the solution scope is to conceptualize the recommended solution in enough detail to enable stakeholders to understand which new business capabilities an IT business solution will deliver, or in other words Create Shared Vision. By creating shared vision concerning the IT business solution at this point in the project you can decrease focus of the project to that solution scope, reduce scope creep, that can reduce project timelines and free up project resources sooner, increase stakeholder satisfaction at the end of the project. This increases the probability that the project will be deemed a success.

Take our example above, the solution scope will state exactly what is changing about the cosmetic look of invoices, such as “the company logo at top of the invoice will change to the newly adopted logo, the bill-to customer name and address will print to the right of the ship-to customer name and address on the invoice as well as the date printed will change to Day, Month, Year format (i.e. 15 August 2011) from its current Month, Day, Year format (i.e. August 15, 2011)”. Just as Project Scope declared what was out of scope for the project, the solution scope declares what is out of scope in relation to the IT business solution. “This enhancement will not change any calculations as to price or discounts that customer receives. This enhancement does not change how data is displayed on the invoice or how it is retrieved from the database except for the changes defined in this enhancement, meaning that item descriptions, quantities, unit of measures displayed will not change.”

So engage the Business Analyst early in and throughout the project to define and manage solution scope to keep the focus of the project, This helps the organization gain the many benefits stated above.

One of the primary responsibilities of some Business Analysts (BA), or Enterprise Analysts (EA), is to justify projects that the organization should undertake. The BA does this by creating a Business Case for the project and this task falls under the BA knowledge area of Enterprise Analysis. 

Many Business Analysts miss the ball in the Business Case by making the justification for the project or IT business solution very subjective. Many Business Cases start off with what the IT business solution should be. To understand what should be in a Business Case and how to develop one, we must first understand the purpose of the Business Case.

The Business Case is a formal written document to assist executive decision-makers in making the decision on whether to invest in a particular project or IT business solution investment. Knowing this purpose of the Business Case brings to light two important aspects of the Business Case: 1) it is for executive decision-makers and 2) it is to assist in their decision to invest. This means that two very important sections of the Business Case need special attention: 1) the Executive Summary and 2) the money section.

I have personally seen that executive decision-makers look at these two sections only.  Executives want to know 1) what is this about and 2) what is the cost and cost-justification. The Executive Summary should summarize the rest of the business case in a very concise and complete way for quick consumption by executives. The long, detailed version will be used by Managers, the Project Manager and other application software development team members. The second important section of the Business Case is the money. Notice, I not only said “what is the cost” but also “and cost justification”. The cost justification is what is usually left out of the Business Case; most Business Cases, even today, contain no ROI or cost justification analysis. The money section should contain not only the cost of proceeding with this project but it should contain a cost justification for undertaking the project. Projects can be justified by either a cost-benefit analysis, average rate of return, return on investment, internal rate of return or some other method of financial analysis.

Organizations may gain great benefits from engaging the Business Analyst in creating the Business Case including more informed decisions, project mix more strategically aligned and greater business understanding.

We will discuss the other sections of a Business Case and the process that the development of a Business Case should go through as this “The Value of a BA” series continues. Rich Larson of Watermark Learning presented a session on “Creating Bullet-Proof Business Cases” last spring at the Southwest Ohio Business Analysis Development Conference here in Cincinnati for Cincinnati, Dayton and other business analysis professionals in the region. Rich’s presentation, the BABOK® and other BA resources will be used to justify the concepts presented. I hope you continue to read and enjoy the series.

All enterprise application development team members know that an IT business solution project goes through a Project Life Cycle (PLC) from initiation through deployment and closure. It is also well known that the Project Manager plans the project during initiation to prepare to bring the project to a successful completion by ensuring that all application software development resources are available to the project when they are needed.
 

However, many people believe that the Business Analyst’s (BA) role on the project is to capture the business requirements for the IT business solution. Business analysis professionals know that there are Project Planning tasks for the BA to perform on the project.
 

The Business Analyst should be assigned to the project during the initiation phase about the same time as the Project Manager, assuming this is a different BA than developed the Business Case for the project.  If not, then the Business Analyst is already assigned and working on the project when the Project Manager gets assigned and should move from developing the Business Case to Planning the Business Analysis activities for the project.
 

Project Planning, or more commonly called Business Analysis Planning and Monitoring, includes planning the Business Analysis approach, conducting a stakeholder analysis, planning the Business Analysis activities, planning Business Analysis communication, developing a work breakdown structure (WBS) if necessary and planning the Requirements Management process to be used on the project.
 

Cincinnati and Dayton companies, as well as those across the globe, can benefit by engaging the Business Analyst during the Project Planning and gain reduced project timelines, better resource utilization, freeing up project resources sooner, less re-work and increased probability of project success.

Does your company engage the BA for Business Analysis Planning and Monitoring?

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?

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

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

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

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

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

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

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?

One measure of how effective a BA performs their duties is how well they Create Shared Vision.  The BA must create shared vision not only about the solution, but also the requirements of the project.  The BA must communicate requirements to all stakeholders which means communicating across business lines, to parties that may not have any interest in one or more of those requirements; and to the technical team who will build the solution.  In order to build the solution effectively they must understand the requirements.  They must understand not only the actual requirement but its priority and its essence.  By essence I mean they must understand the requirement, where it came from, its importance to the project and the attributes of the requirement.  This is how the BA creates shared vision concerning requirements.  By creating share vision concerning the solution and the requirements the BA helps the business application development team work like a well-oiled team that delivers excellent IT business solutions.

This is how Cincinnati, Dayton and companies across the globe can effectively utilize the BA role.  The better the IT business solutions delivered by the enterprise application development teams the better the bottom line of the company may look.  This can reduce headcount, not only of the Information Technology staff but of business personnel as well.  This can reduce project timelines and reduce the number of projects necessary.

How have you created shared vision and saved your company money?  For more on this concept, go here.

Attention Cincinnati and Dayton IT professionals:  The IBM Tech Trends Report is in.  You can view a copy here.  Over 4000 IT professionals from 26 countries participated in this survey.  It should be no surprise that the top application development areas are in business analytics, cloud computing, mobile and social business. 

Specific skills needed by application developers were java, .net, xml, php and html5.  Not any real surprises here either.  Fortunately, STAR BASE is a leading Cincinnati IT consulting company and can provide IT staffing for any of those areas and skill sets.  

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?

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.

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.

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?
 

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.