IT Consultant

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

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

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

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

One of the 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?

We have been discussing the value a Business Analyst (BA) brings to the table in the area of Solution Validation.  Another often overlooked and underperformed task of Solution Validation is “Assessing the Solution Performance”.  Cincinnati and Dayton organizations do not take advantage of the benefits that can be received by performing a Solution Performance Assessment.

This task is performed after the IT business solution is deployed and working.  It can be done very shortly after implementation or over a period of time following deployment.  You cannot assess performance if the solution is not in use by the business.

First the BA must determine the criteria by which the solution will be measured; these are often called “key performance indicators” (KPI).  To determine correct performance criteria the BA must understand the intended value that the IT business solution was designed to deliver to the organization.  Understanding this value the BA may determine criteria by which the solution may be measured to determine if the business is receiving the anticipated value from the solution.

Some of these solution performance metrics may be quantitative, measure of time, volume, revenue, errors or other hard numbers; or qualitative, user satisfaction and use, recommendations, concerns or other subjective opinions of the stakeholders using the solution.  When a new enhancement to the Order Entry system in deployed, but you soon find that the Customer Service Representatives or Order Entry Clerks have developed a manual workaround that circumvents the enhancement, then your qualitative analysis would show a negative response from the stakeholders.  Such response should be investigated by the BA or Subject Matter Expert (SME) to determine the root cause of the business user’s dissatisfaction with the solution.  This may lead to enhancement, reversal or replacement of the IT business solution.

Collecting solution performance metrics are not only negative, but the BA should also collect positive metrics to assist in determining if the solution is delivering the expected benefit to the company.  This can assist in early detection of a “bad” solution, proving the success of an IT business solution and can lead into other business capability gap analysis.

Does your Cincinnati or Dayton company collect solution performance metrics following project implementation?  What other ways have you found to validate the performance of an IT business solution after deployment?

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.

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

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

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

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

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

In a previous article, at beginning of the year, I discussed the “Top 10 Business Analysis Trends for 2011” as described by ESI International, a business analysis education provider and an IIBA® Endorsed Education Provider (EEP). Looking back upon the year, I see how very close they were on the emergence of these trends. One in particular, number 7, “Resurgence of Centers of Excellence” strikes me.  It hits home because this also seems to be on the  rise in the Cincinnati and Dayton markets.
 

Kupe also wrote on this subject this week at BA Times. He describes it as a topic of a discussion panel at the Building Business Capabilities conference earlier this month. The eight comments posted to Kupe’s article show a few people that have been involved in implementing Business Analysis Centers of Excellence (BACoE).  

So now you ask yourself “Should we setup a BACoE for our company?” You can answer that question by rephrasing it “Will our company benefit from a BACoE?” Setting up a BACoE for the purpose of saying that you have one, is not good enough. How will the organization benefit from having a BACoE? What is the purpose of the BACoE? So find the value add to the organization that a BACoE can provide and you will find the purpose and benefit of having a BACoE and that will make it worth implementing.

One thing to realize when implementing a BACoE is that it is a process that takes time. It isn’t a something that you setup and it is done. It will take continual improvement of your documentation4, processes, tools and training material keeps your BACoE delivering the best possible value to the organization. I have described this process of continual improvement before. So don’t implement the BACoE and never revisit it, not only continually use the material of the BACoE, but continually improve that material. Keep your BACoE as innovative and up-to-date as possible. That is how you will best serve your organization.

Would your organization benefit from a BACoE?  Your friends at STAR BASE Inc. would love to explore that possibility with you.

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?