IT Solutions Cincinnati

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?

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. 

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

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

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

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

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

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

See Part One here.  These deadly sins are not limited to IT Consulting in Cincinnati, but everywhere.  I wish that someone would have shared the list below with me earlier in my career.  It might have saved me a few grey hairs and sleepless nights.  I have to admit, I have been guilty of a couple of these in the past, but that’s why it’s called experience.

5. Blame it on Rio.  And I am not talking about the movie, I am talking about pushing the mistake/error onto something else like, the Operating System, another consultant or worse, one of the client’s employees.  While the problem could very well be any of those things, your job as a professional consultant is to find solutions and to set an example in leadership and even diplomacy.  While you may see glaring errors or mistakes and perhaps your way would have been the better way to do something it is best to keep the criticism and commentary to yourself. (See #3 in Part One)

6. Bubble gum and baling wire.  Many times consultants are brought in to fix something.  The last thing you want to do is to take a shortcut that you aren't sure will last. Band-Aids are fine if you know you are coming back to make a more permanent fix. But eventually, those shortcuts will fail and will need further attention and the time to failure is an unknown. It could be the minute you drive away or months later. This is not the type of chance you want to take. It frustrates the client, and it makes you look bad.  You also don’t want to make the client totally dependent on you.  A client told me once that Peter (not the real name) is very talented; the problem is he is the only one that knows how it works and can manage it.

7. Showing up, Gotta Go. (AKA I gotta hangnail).  Once you’re on a gig, most clients want to see you on some sort of regular basis and some might have a “core hours” expectation.  It’s important for both the client and the consultant to know what each should expect.  I once heard a client make a comment about another consultant that went something like this: “Larry(not the real name) runs out of here all the time and uses sickleave for a hang nail!” 

Here is another list that has some similar ideas here.  I’m sure there are others.  So go forth and sin no more!
 

I have a new client in Cincinnati. New clients are always interesting because you never know what issues and opportunities you will find. My client seems to have their act together. My application development friends will appreciate their setup; Maven 2 projects with built-in JUnit tests, a code coverage dashboard that show code complexity, code coverage, and Find Bugs reports. Things seem great, them why do they need a performance engineer?

The reason is common; who defines the duties of ITsets the rules. IT and the business need to be aligned to work on the common goals and increase productivity. If IT is too dominant, there is too much focus on technology and the business doesn’t get the tools they need to be productive. If the business unit is dominant, only projects that have a tangible return get done. In this case the business is more dominant, so projects like refactoring code, or cleaning up errors found by software like Find Bugs has a much lower priority. They do happen only if performance is an issue to the business. The performance team is set up like a clean up crew that comes in after the fact, to make things work better. There are coding style forms and best practices, but is up to the each developer to follow them. Since the focus is getting the project done on time, the developers are concerned on getting code that works,not what works best. The performance team is used to fix the worst performance offenders.To be fair, I have been at clients where IT treats the business units as a nuisance. The best tools are there, but little support for the business.
What’s the solution? IT needs select a technology that best suits the solving of business problems. The business should prioritize their issues, but work with IT to plan for fix releases. IT must utilize the tools that they have and encourage the usage of them. If you have the tools, use them!