IT Infrastructure Management

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

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

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

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?

One of the strategic roles that the Business Analyst (BA); Enterprise Analyst (EA) or Enterprise Architect (EA), can perform for the organization is the maintenance of an internal knowledge base, often called an internal Business Analysis Body of Knowledge.  This would be a centralized, electronic repository of artifacts concerning the organization and the environment in which it operates.  This is not a task defined in the IIBA® BABOK®, however would fall under the knowledge area of Enterprise Analysis.

This repository should describe not only the organization but the environment in which it operates. It should include an Enterprise Architecture; divided into Business Architecture, Information Architecture, Application Architecture, Technology Architecture and Security Architecture.  Along with that it should include BA training and information material to quickly ramp up newly hired Business Analysts.  Also, some type of mechanism to ensure you are capturing the business knowledge of Business Analysts who are leaving the organization, so that valuable business knowledge does not walk out the door.

When a Cincinnati, Dayton or other community business has a BA community that is actively maintaining a centralized, electronic internal body of knowledge; that organization is well on a maturity path from a BA Practice to a Business Analysis Center of Excellence (BACoE).

By maintaining this body of knowledge within the organization, the Cincinnati, Dayton or organizations across the country and globe can help deliver business analysis services across the organization at the same level of service, move its business analysts among the business lines and business units within the organization with ease and little ramp-up time, make better business decisions based on an enterprise-wide knowledge base, enable business management consulting within the organization.  These business decisions can have significant impact on the company’s bottom line.

Does your organization have an internal business analysis body of knowledge?

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.

There is no doubt that a considerable amount of resources of an organization is spent on requirement definition and documentation no matter where the maturity of the Business Analysis practice within the organization.  The business has a considerable interest in requirements that lead to IT business solutions and it can define the direction and prosperity of the entire organization.

By maintaining requirements for re-use the Business Analyst (BA) can considerably reduce the resources spent on requirements definition and documentation.  In this way the BA identifies long-termed used requirements of the organization that may be used by multiple systems, or continually come up for solutions on multiple projects.  These may include requirements that the organization must meet on an ongoing basis, as well as requirements that are implemented as part of an IT business solution.

Whether these requirements are maintained in a repository or not; they must be identified, clearly defined and available to all BAs within the organization.  When a requirement must be changed, the change must be communicated to the BA community and understood by the business community concerned.

Maintenance of requirements for re-use can facilitate impact analysis of new, proposed changes to the business, reduce analysis time and effort, assist in the maintenance of previously implemented IT business solutions and support other business initiatives; including training, corporate governance and standards compliance.

Cincinnati and Dayton companies; and companies across the globe need to mature their BA practice within the organization toward effective maintenance management of business requirements, including requirements for re-use.  This will give these organizations the benefits stated above and continue the BA practice on the path toward a Business Analysis Center of Excellence (BACoE).

Do you have an effective requirements management process?  Do you use a software requirements repository tool to accomplish this?

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.

Many people, and organizations, consider requirements elicitation as the only task that the Business Analyst (BA) performs.  That couldn’t be further from the truth, and those organizations are missing out on the benefits of all the other tasks that a BA is the optimal role within the organization to perform.  This is not limited to Cincinnati and Dayton area companies, it happens all over.

We have already discussed one task of a BA, Stakeholder Analysis and Management. By identifying all possible stakeholders for a particular solution, the BA helps ensure inclusion of all requirements for the solution in the project.  This leads right into today’s topic: Getting Requirements Right!

Getting requirements right means getting them right the first time, at the beginning of project work; before the project gets into the development stage of the Project Life Cycle (PLC).  This reduces re-work and frees up project team members to move on to other projects.  This can lead to reduced headcount and increased project success rates within the organization.  This can also lead to fewer projects within the organization as getting all requirements included in a project and getting those requirements right can mean that follow-up projects to remove a solution feature because it interferes with another system that was not considered during the initial project will not be necessary.  Also, a follow-up project to add a solution feature that was missed in the initial project can be avoided.

Getting requirements right the first time affects an organization’s bottom line, and that can be a considerable effect.  Many consider this the primary role of the BA and their main purpose for being.  As for the tactical role of a BA that is correct. So Get the Requirements Right the first time!

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

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

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

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

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

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

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.

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.