IT Solutions

BA: Business Alignment

Wednesday, August 25, 2010 by Aaron Whittenberger

STAR BASE Consulting is conducting a new pulse survey this month asking the question “is there really a rivalry between IT and Business or is this all just sensationalized hype?” I am very interested in seeing the results of this survey, but I believe I can predict the results. In almost every organization I have ever worked in the “Us vs. Them” culture existed. The relationship between IT and Business was more segregated, even adversarial at times, than that of a partnership.

Kupe tackles this topic this week on BA Times, where he discusses creating an environment in which the business wants to work with IT to derive technology-driven solutions. Doug Goldberg does an in-depth analysis of the subject on his blog, in which he describes approaches that a business-side analyst and an IT-side analyst to take to create a collaborative environment.

This topic is nothing new, just as the relationship between IT and Business is nothing new.

It took decades to get it where it is today. I am sure you can find bright spots in which IT and Business work together to achieve their goals, but in more organizations than not, this is not the case. Just as business processes and technology advance year by year, the relationship between IT and Business can be made better. I believe the Business Analyst is in prime position to turn the relationship around to a positive, collaborative, trusting relationship in which the two work together to achieve the strategic goals and initiatives of the organization. Why the BA? The BA is one role that works on both sides of the fence. The BA works with business stakeholders to bring out requirements for business improvement or application development solutions. The BA also works with the IT Solution Delivery Team to develop the solution that meets the business requirements. As the BA works with both teams, they are in prime position to bridge the gap between the two. So how should the BA go about bridging the gap?

Build a Relationship of Trust

One of the often overlooked roles of the Business Analyst is that of liaison between IT and the Business. In order to fulfill this role the BA must have a relationship with both sides of the organization. That relationship has to be built on trust. The business must understand that the BA is there not only to gather requirements but to understand the needs of the business and represent those needs to the IT delivery team. The IT delivery team must feel that the BA will represent the capabilities and limitations of technology to the business.

Communicate

The greatest factor that creates the “Us vs. Them” relationship is a lack of understanding. The business wonders why it takes IT so long to make a seemingly easy change. The IT application development team feels that business can not communicate effectively and does not understand the process of making application enhancements. Last month I spoke about creating a shared vision in relation to requirements and IT solutions. The BA should also create a shared vision of the needs and limitations of one organization to the other. The BA can communicate not only the requirements for IT solutions, but the stakeholder concerns surrounding those requirements. This adds context and can improve the ultimate solution developed as it increases the IT delivery team’s understanding. The BA can communicate to the business that the process of making application enhancements is more involved then changing a little piece of code and there it is. Testing, Quality Assurance, moving changes to production, Sox regulations, post-install processes and support are all time consuming tasks and increase the amount of time it takes the IT application development team to make an application enhancement. The more the business understands about these processes and the value they add to the solution, the more considerate they will be to the needs of the IT delivery team.

Build the Bridge

Through effective communication of the needs and limitations of one side of the business to the other and representing the other team to each team the BA can build a bridge of understanding between the two groups. By making each side realize that we are all in this together and desire the same outcome, you can build a relationship of trust and get rid of the “Us vs. Them” scenario and replace it with a collaborative working relationship that brings about better IT solutions to business needs.

So take the liaison role of the BA seriously and work to replace the adversarial relationship with a collaborative, understanding relationship. In this way you can show the BA value to the organization.

Why? Because that’s The Way It Is!

Friday, July 30, 2010 by Matt Warman

If you thought your job as an application development person is difficult, try being a consultant. I love my job as a consultant because I am able to affect change, that is, when people want it. The most dreaded phrase a consultant can hear is “that’s the way it is”. Those words have no rebuttal, no further review. It’s the organization’s way of saying “talk to the hand”! My job is to find gaps in code or process and bring them up to the client. Often times the client has fallen into way of doing things that are counter productive, or more likely, have not changed since the process was in place. A case in point, I was having a discussion with an architect about code review. I noticed that they had the Legacy style user, date, and change comments at the top of their classes. I made a review comment that they weren’t necessary, because Subversion tracks the changes for them. It was due to their work process that comments would be lost by Subversion on multiple merges. I mentioned that several high profile companies use Subversion and don’t seem to have a problem. The architect said that research was performed and it doesn’t, and if I have a better solution, I should do my own research before making a comment. I told him that software does indeed improve, and that if research has been done, it should be reviewed periodically to see if the issue had been fixed. I did research the issue, and Subversion did have bug but was fixed, and my client could use comments in their merged code. The key here is that the staff complains that changes don’t get done, but when they are in a position to make it better, they don’t do it. If anyone investigates a new technology or work process it should be DOCUMENTED AND REVIEWED! I don’t know if it will be investigated because it seems like a trivial issue, but the main problem is that the application development people complain that nothing changes. It’s our Culture. Culture is people, and all people, especially application development people can change culture. If there are deprecated methods and TODOs in production code, bring them up in your code review. I don’t accept “that’s the way it is” as a reason. You can’t change a decision for business reasons easily, but you can fix how things get done. If I don’t like the way that it is, I make it better.

Seven Deadly Sins of Consulting, Part 2.

Monday, July 26, 2010 by Jeff Welsh

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!

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

Monday, July 12, 2010 by Aaron Whittenberger

A few months ago I wrote on the benefits of developing a Business Case and how it should be used during the IT Governance and SDLC (Waterfall) process. My main point was that the Business Case document needs to be revisited at different points in the SDLC by the IT Governance body to continue to give its blessing to the project. At any point, yes even after development, the IT Governance body can hold up the “halt” sign on the project when factors or the environment has changed to make the project solution of little to no value. However, this can not be done when the IT Governance body reviews the project and the Business Case only at project inception. Constant review of the business case also assists in initiating the risk mitigation plan when factors or the environment changes that makes such mitigation necessary.

Today I look at the Business Case from a different perspective, that of Project Management. I have been involved in organizations that did the Enterprise Analysis activities that identified a business need and built the business case for a solution. The business case was brought before, and received the blessing, of the IT Governance body and a new project was born. It was then turned over to a Project Services team whose first task was to create a Project Charter.

I found it amazing that the similarities, in format and content, between the Business Case document and the Project Charter document were far greater than the differences. Some sections were reordered and some content was moved from one section to another, but essentially it would be easy to swap the names on the documents and most people wouldn’t even notice. Other than the intended purpose and audiences of the documents, they were essentially the same document. This naturally leads to the question: Do You Need Both Documents, or is it a great waste of time?

Yes, the Project Charter defined a few details in greater detail than the Business Case, but also realize it was written at least a week later, when more factors were known. Also, such content as risks and mitigation plans were then transposed, and further defined, into the project’s design documents. So why can’t the Business Case be used as the Project Charter?

In most cases, I would submit that the Business Case should be used as the Project Charter. Remember the Business Case has received the blessings of the IT Governance body and should therefore direct the scope of the project. Going back to the IT Governance body for approval of a Project Charter mostly restating the contents of an already approved Business Case would definitely be overkill and put undo burden upon the IT Governance body.

One case where Project Charter(s) are necessary after the approval of a Business Case, is when that Business Case is to be split into multiple projects to bring about the Business Case solution. In this scenario you would want a Project Charter for each project to define what part of the Business Case scope that particular project was initiated to handle.

In rare, very complex, business problems with complex business solutions you may find need for both a Business Case document and Project Charter document(s). In most cases, even in large companies, using the Business Case to define the scope and reach of a project is sufficient to get the job done.

Roaming the UK

Monday, June 21, 2010 by Matt Warman

In my recent post, I talked about my new phone for my upcoming trip to London. I am excited about my new phone, but not the cost. My carrier charges .35$ per outgoing SMS, .20$ per incoming SMS, and 15$ per MB for data. Since my phone is always “listening” on the Internet, it would cost a lot to actually use my phone in London. I can put my phone in “airplane” mode and use the camera, games, and music capabilities, but why have smartphone and not use its features? Fortunately, the solution is relatively simple. I can unlock my phone and use a pre-paid SIM card while in the UK. For my application development friends who are not phone savvy, let me explain. US phones are “locked” for US usage only. All carriers also make some phone features unavailable to the customer. In some cases, you are charged an additional fee for a feature your phone could perform for free! In this case however, I am unlocking my phone so I can use it on other networks. You may have heard of the term “Jail Breaked”. This refers to a phone that has been hacked to allow all features on your phone to be used. Some phone manufacturers and carriers don’t like this, and can make your phone unusable, or “Brick” your phone. Unlocking through your carrier is perfectly fine though. Once your phone is unlocked, the second part is to get a SIM card in the country you are traveling to.The SIM card is how the network recognizes you. If you opened your phone and swapped your SIM card with a friend, you would get all of his calls, and he would get yours! You can pick up a prepaid SIM card with a data plan for about 10 pounds (approx. 15$) a week. That’s a hefty monthly bill for a local customer, but it is much cheaper than the roaming plan. Remember, your phone number is different with a different SIM card! I can use my phone features to post messages and images on Facebook, for example, like I was at home. I can communicate with people at home without paying hundreds! I will let you know how this works out when I return.

Know Your Role

Thursday, May 20, 2010 by Matt Warman

I am finding out things at my current client that everyone, including application development people knows; having a process is only half the battle. I have been to organizations where business workflow processes were not in place, and the productivity gains were huge when implemented. But over time, those processes stop getting followed. There are many reasons for this; the IT culture rejects the change, the processes don’t get reviewed in a timely basis and become a burden, and the players forget their role.
My client has a decent development workflow in place. Analyst get requirements from the business units, architects turn the business requirements into technical requirements, and application development people execute the requirements. Managers should manage the process, making sure that the resources are available when needed. I always wondered why top technical guys get passed over for management in favor of PHB (Pointy Haired Bosses), and now I know. It’s that PHBs know their role. Managers are managing the PROCESS, not the solution. Often, technically savvy managers want to work the issue. Software development is a very fluid process, and what works now, may not work three years from now. If you are manager for more than six months, you probably don’t know the correct solution. Regardless, your role is to make sure application development staff are available for the solution designed by the architects. Managers have a right to review the design during the design phase, but once finalized, let the architects and application development people do their jobs.
The same is true for consultants. Yes, they are using older technology, and yes it’s a pain to use, and yes it needs to be updated. Your job is to help resolve those issues within the framework of their organization. Unless you are brought in as a CIO consultant, the choice is probably not yours to make. It may be that the business has urgent needs that supersede modernization. They may not have the technical people to maintain the new code. The organization could be planning to replace the system with a prepackaged application like SAP. Or it could be that the technical staff knows their role, and is waiting patiently for their opportunity to upgrade.

Use Cases with UI and Details

Monday, May 17, 2010 by Aaron Whittenberger

How many times have you developed Use Cases for a project, gone over them with the stakeholder, reviewed the functional requirements of the system, developed and delivered your IT business solution to have the stakeholder want to make changes to it immediately? Is this a symptom that the stakeholder did not understand the Use Case?

More then likely what the stakeholder did not understand is what the user interface (UI) would look like or how it would act. So then we as Business Analysts (BA) turn to Microsoft Visio, PowerPoint or some other tool to create a mockup or prototype of the UI. We share that with the stakeholder, but he/she is still left without the whole picture.

So now we as BAs turn to Microsoft Word, PowerPoint or some other tool to put some details behind the Use Cases and UI. We share that with the stakeholder and get their approval to build the solution. So back to Microsoft Word we go and write a high-level and eventually a detail design to give to the developers to build what we have laid out to the stakeholder. Now all of sudden you three to six documents that you must track and keep in synch; a change to one document may mean a change to another.

Masayuki Otoshi gives a solution to this dilemma in a BA Times article as storyboarding; a way to put Use Case, UI and detail specifications in one document. The article shows an example of user login webpage. It gives examples of the main stream, providing a correct user name and password and an exception stream, providing an incorrect user name and password.

On the surface storyboarding to provide UI and detail information to the stakeholder sounds like a good idea. The simplicity of the example falls short to show the usefulness of this tool. I deal mainly with complete Enterprise Resource Planning (ERP) systems and eCommerce website interfaces to the back-end order fulfillment system. Using storyboards to show the stakeholder(s) what the eCommerce webpages or the ERP desktop screens will look like before they are built allows the stakeholders to make changes to the look and feel of the system before development dollars are spent to build it. Giving the stakeholder(s) a more complete picture of the proposed system look and functionality during analysis and design phase of the project should reduce the amount of rework requested.

Storyboarding has been used in the Agile system development methodology for awhile. It has not caught favor in the SDLC or Waterfall methodology as of yet; but the need to draw a more complete picture to the stakeholder(s) of a proposed IT business solution as early as possible in the project cycle may give storyboarding the light of day.

I do see the usefulness of storyboarding for the SDLC as well as the Agile methodology. I look back on past projects where I could have used storyboarding, if nothing else, to decrease the project schedule.

I do raise one word of caution…remember your audience. All too often I have seen IT business solutions project teams try to combine multiple documents to serve several purposes. Giving the stakeholder(s) the level of detail that developers need to develop the solution may cause confusion with the stakeholder. So do not try to combine everything into one document. Even your wording should be different for stakeholder documents and technical documents. So try storyboarding if appropriate to the project. Someday we just may find it as mainstream as requirements documents and Use Cases are today.

IT Governance Needs to Change to Gain a Competitive Advantage

Friday, May 7, 2010 by Aaron Whittenberger

Futurists have been fore-telling the look of the business enterprise and the IT Department for years. The latest version from the Corporate Executive Board state that we are in for rapid, radical change. It fore-tells that the IT Department in 5 years will bear little resemblance to the IT Department of today. As business users become more tech savvy, the business units will absorb a lot of today’s IT functions. Along with continued IT outsourcing, they predict that only 25% of today's IT professionals will still be in IT in 5 years.

The CTO blog does not forecast such a dismal future for the IT professional, but it also acknowledges the need for better alignment with business strategic goals and faster IT solutions delivery.

Whereas, I will not completely buy in to the idea that 75% of today’s IT professionals will not be working in IT in 5 years or that change will be so rapid or radical. It is increasingly apparent that change in IT solution delivery is necessary, and that is where I suggest that business organizations start; in particular IT Governance.

I hope to see today’s IT Governance Committee, which approve and prioritize IT business solutions projects, replaced with a Business Improvement Project Review Board who approve and prioritize all business improvement projects. This new Governance Body will consider all business improvement projects; those with business solutions and those with IT solutions. As I mentioned a few weeks ago this new board needs to better track all projects and continue to give its support to all projects at every stage of the project. Once the cost of the project outweigh the benefits, or other external forces make continuance of the project unwise, the project can be stopped and decrease the expense to the organization.

Along with that we will see the idea of a Project Management Office (PMO) replaced with a Business Improvement Office (BIO). The BIO will be staffed with people with business backgrounds and those with IT backgrounds; however, cross-training and best practices will require all members of the BIO to look for the best solution, considering both business and IT solutions, to meet the needs of the business. The BIO will take over the project management, business analysis and quality assurance aspects of a project.

Continued competitive pressures will force the BIO to change its practices in order to achieve faster solution delivery. Some will embrace the Agile methodology; others will develop some hybrid methodology taking parts from both the Agile and Waterfall methodologies. However they achieve it, continued pressures for competitive advantage will require continual improvement in the methodology to push for faster and faster delivery while not sacrificing quality.

Many references now forecast a change to IT Departments and IT staffing as we know it today. It will be interesting to see the changes as they come about and see which forecast was most correct.

Death by A Thousand Cuts

Wednesday, May 5, 2010 by Matt Warman

My client has great code promotion rules. All code that changes gets system tested or it doesn’t get promoted. Code doesn’t change unless it has a bug tracking ticket. You say Matt, that’s great! Why is this a problem? The problem resides in the fact that everyone in IT is stretched to the limit, and deadlines are tight. Application development people are getting the code working with little refactoring, architects struggling to get the analysis piece out and little time for code review, and not enough testers. This situation makes it difficult for performance. As part of the performance team, I can review all of the code, and make some changes, but the problem is that if the code is not a part of the release, it will be impossible to get promoted due to time/resource constraints.
For example, a process was taking a long time to complete because of improper error handling, but the call is not necessary. The proper fix is to remove the call, but the fix going in only resolves the exception. Why? The low priority of the code, coupled with the testing constraints and lack of testers makes these changes common. Some application development people may say, "Well, the code is fixed". True the performance issue is resolved, but there is an unneeded call. If the attitude from application development people is "I would fix it, but it’s too much trouble to test", unneeded code can add up quickly. Extra code is in all projects, but if changes like this or, removing a variable passed to a method, or even changing code to remove unused variables don’t get fixed, the "extras" add up. Not one of these changes significantly affects performance, but all of them will. The solution is to work with management and your application development people to limit "extra" code. This can be done by reviewing and fixing code in your maintenance or enhancement project. Have a "refactoring time" built in to the project plan. The time put in up front will bring great dividends both in performance and future coding effort.

Got Tools? Use Them!

Friday, April 30, 2010 by Matt Warman

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!

Building the Business Case for New Tools

Friday, March 26, 2010 by Aaron Whittenberger

A couple of weeks ago I wrote about the need to develop a Business Case document. Soon thereafter I find this one-page Business Case document. The first question that comes to mind is “how can you put all that needs to be in the Business Case document in one page?” Believe it or not, they did it. Of course, a lot of things were abbreviated. You have to question the usefulness of such a document.

Of course, a one-page document is not what we experience in our IT Business Solutions projects today. Instead, we have what Chris Gurney wrote for BA Times as the “Big Freakin’ Requirements Document”. Chris outlines the various reasons that our requirements document has to be so freakin’ long:

To Communicate to all audiences
To Validate that Needs are Met
To Ensure Everything’s within in Scope
To Manage Changes to Requirements
To Meet Regulatory and Corporate Obligations
To Define Requirements Collaboratively

It has become common place in over the years to try to accommodate everyone with one document. So language is included for executive staff. Then we translate the requirements to a more detailed level for developers and testers. We turn on “Track Changes” feature to retain the history of changes to the document; which then leads to descendent versions of the document.

What Chris is trying to point out in the article is that a Word document is no longer sufficient for collaborative development of requirements for our IT business solutions projects. What you can expect to see is many vendors rush to provide software solutions to these shortcoming

s. Currently, there are some solutions out there to address these issues. I will not promote any current software solutions here, but you can expect to see more solutions from new vendors in this area. You will also see great improvements in features in the solutions that are already on the market. When business organizations migrate in groves to these solutions and away from Microsoft Word as the standard for “document” development then you will see this market grow rapidly. Large organizations with large IT staffs and geographically dispersed enterprise application development teams should be first to make the move. I think you will see Business Analysts within those organizations leading the charge, but with all “organizational shift” changes, convincing those that hold the purse strings of the value and need for new tools will be their greatest challenge.

Building the Business Case for the Business Case

Thursday, March 11, 2010 by Aaron Whittenberger

In a BATimes article John Moore visits the need and proper use of a Business Case document to increase the success of IT business solution projects. He demonstrates a failed project due to a competitor who released a competitive product in the market before our organization’s project completed. The business manager showing the project failed because it did not deliver the projected ROI. The IT project team noted that they delivered the project on-schedule, on-time and on-budget. Was that risk that a competitor could beat us to the marketplace identified at project initiation or during the life of the project? Were the proper stakeholders identified and included in the project communication plan?

John makes note how the Business Case document should be revisited several times during the project life cycle. Doing so may have caught the changing environment and allowed the organization to mitigate the risk from the competitor.

John makes very valid points that I believe show an improper IT solution Project Delivery System. Laura Brandenburg notes in her blog that the Business Case document is often created under another name, or as I have noticed in many organizations the Business Case document is created, then it is used to develop the Project Charter and Project Design documents. These documents should not only be created but needs to visited by an IT Governance body during multiple steps in the IT solution Project Life Cycle; not just at project initiation. At each point it makes a “go/no go” decision as to whether to continue the project. This is where many organizations fail to follow through.

Take the simplified high-level Project Life Cycle that includes 5 phases: Initiation, Analysis, Design, Development and Implementation/Closure. Most organizations will make the “go/no go” decision on an IT business solution project either prior to the Initiation phase that kicks off the project or at the end of the phase, depending on how the organization defines its Project Delivery System. In most organizations that is the only time that the IT Governance body will rule on the value of the project.

If the IT business solution project had to go before the IT Governance body at the end of the Analysis, Design and Development phases as well as the Initiation phase then the organization has greatly increased its ability to mitigate risk in the project, especially from external forces.

As the project goes through each phase of the Project Life Cycle, the benefits, costs, requirements and risks are further defined. In John’s example, if our competitor launched their product while we were still in Design then our IT solution project went before the IT Governance body for its next “go/no go” decision. The IT Governance Body, being aware of the competitor’s product launch, can now say that the project benefits are no longer valid. The risk mitigation plan can be executed, which may include dropping the project all together. This reduces the cost to the organization as those resources can now move on to a more valid IT solution project.

So not only is it important to make sure that you build a Business Case document, by whatever name you may call it, but be sure it is visited several times during the project life cycle, by others outside of the project team, to ensure that the assumptions (benefits, costs, risks) therein contained remain valid. This along with making sure the proper stakeholders are involved greatly increases ensuring that the IT solution project maintains its value to the organization.

Business Analysis: Building the Bridge

Wednesday, March 3, 2010 by Aaron Whittenberger

A common reference I hear in business today is that the Business Analyst (BA) is the bridge between the business and information technology staffs within the organization. This infers that the knowledge of getting from one to the other, or interacting with either is contained within the BA alone. The BA should not be the bridge, but the bridge builder. If the knowledge is contained only within the BA, if the BA should leave the organization, then the bridge is gone. If the BA is the bridge builder, then if he/she should leave, the knowledge remains within the Organization.

As an IT Strategy Consultant developing IT solutions here in Cincinnati and Southwest Ohio, I go from organization to organization and see that turnover within the BA ranks inevitably causes a great learning curve; either to recover the knowledge that has just walked out the door or bringing the new BA up to speed and making them an effective contributor to the organization.

What all these organizations lack is an Enterprise Architecture, a fundamental artifact of the Business Analysis profession. This and other artifacts are the foundation of creating a Business Analysis Center of Excellence. There is a maturity path that all organizations take from having a community of BAs that serve the organization with no continuity or conformity of service through a mature level in which that continuity and conformity of service is establish; into a BA Center of Excellence, where all BAs within the organization have a common standards of practice, tools and resources from which to draw knowledge.

Where is your Organization on the maturity path to a BA Center of Excellence?

What makes a good BA?

Friday, February 26, 2010 by Aaron Whittenberger

I have spent a lot of time talking about the duties of the Business Analyst (BA); now let’s talk about the characteristics that make up a good BA. I find it interesting that Kupe wrote on this very subject this week, I guess great minds do think alike. As Kupe notes, the IIBA call these underlying competencies and define these as “the skills, knowledge and personal characteristics that support the effective performance of business analysis”.

The BA performs an important role in the application development process and is tasked with the duty of ensuring that the IT business solution meets the needs of the business. The BA develops and maintains the business and functional requirements that the IT business solution must contain in order to be deemed successful.

So we know the role and duties of the BA during a business application development project, so what “skills, knowledge and personal characteristics” does a person need to have to perform these duties. As the duties of the BA entail eliciting requirements from stakeholders and working with an application development team, you can imagine that communication is at the heart of the competencies of a BA. Good written and oral communication is necessary in order to be able to perform these duties. Good communication is not only departing information, but taking in information, or listening. This is often the skill that is over looked when we talk about skills or create a competency model.

Notice that when discussing competencies, that we not only are talking about “skills”, like Decision Making, Creative Thinking, Learning and Problem Solving; but we are also considering “knowledge” and “personal characteristics”. As the BA has to work with both the business and information technology staff, they need knowledge of the organization, industry and technology. What kind of personal characteristics would you want in a person that serves such an important role? I am sure ethics and trustworthiness would make the top that list.

So if you’re a BA looking to advance your career, there are some competencies to work on. If you’re an organization or manager looking to hire a BA, look not only at their skills and past performance, but develop some probing questions that will give you a look into their “underlying competencies”.

Where Does the BA Fit into My Small Organization?

Monday, February 22, 2010 by Aaron Whittenberger

In my previous two-part posts I discussed where the BA fits into the organizational structure. Even Jeff Welsh notes how application software development has changed over the years and requires a team approach for successful implementation of IT business solutions.

But you are sitting there saying we are a small to medium size business (SMB), my entire IT staff is 10 or less, I do not have a Business Process Orgranization (BPO) or Project Management Office (PMO); where should the BA fit into my organization?

SMBs need to utilize the BA role within their project delivery methodology. If the role is not being fulfilled then there is higher risk of failure of the project in that it does not meet the needs of the business. I have worked on many small-to-medium IT staffs and can attest to the fact that when resources are few that people wear many hats. There were projects where I served as the project manager, business analyst, developer and trainer. On smaller staffs, where only one or two of the people will be doing the duties of the BA, it is even more important to make sure that those people are easily accessible by the business units that they support. Have them sit in the vicinity of those business units instead of in the IT Department. I still feel that the BA is an IT function and should report to IT management as opposed to business management, but making the BA readily available and accessible to the business adds value to their role and gains buy-in from the business people to assist the BA with their duties.

So when making the organizational chart keep the BA in the IT Department; but when divvying up office space, make room for the BA near the business unit(s) that they are to support.

Where Does the BA Fit into Your Organization? Part two

Friday, February 19, 2010 by Aaron Whittenberger

In my last post, I joined the discussion of “where does the BA fit into the organization?” I concentrated on the first line BA that should develop the enterprise architecture and help cultivate the business requirements for business process improvements. This BA would be part of a combined Business and IT staffed Business Process Organization (BPO). The purpose of the BPO is to analyze business issues and make the business case as to which IT business solutions projects should be undertaken.

Once a project is approved by the governance body it is turned over to the Project Management Office (PMO) to guide the project to completion. The PMO will be staffed with project managers (PMs) and business analysts (BAs) that will guide the project the rest of the way through the project life cycle. You may be asking why you would need BAs as part of the PMO, or project leadership team; after all the PM is responsible to see the project is completed on-time, on-budget and on-schedule. Yes, but the BA would be responsible to see that the project is completed and the IT business solution meets the business requirements. A business application development project will need functional and technical specifications that the BA should help develop.

The third role of the BA, I alluded to in my first post on this subject, is that of the Test or Quality Assurance Analyst. One role of the BA is to support the system, quality assurance and/or user acceptance testing phase of the project life cycle.

So the answer to the question ‘where does the BA fit …?” is in many positions within the organization. It depends on which BA role you wish to discuss, and whether the organization is large enough to have a BPO and/or PMO.

Any thoughts on the subject?

Where Does the BA Fit into Your Organization?

Monday, February 15, 2010 by Aaron Whittenberger

I attended the CIO Speaker series sponsored by the Cincinnati Chapter of the IIBA^®. The January meeting showcased the CIO and Deputy CIO of FirstGroup America. It was not part of their presentation, but a question was asked of them “should the BA report to IT or to the Business?” This alludes to the bigger question “where does the BA fit into the organization?”

This is the question that many organizations are still trying to answer today. Many organizations are just realizing the benefits of the BA role. One thing to realize, is those of us in the BA arena today are in the forefront of an infantile and growing profession. The International Institute of Business Analysis (IIBA)^®, the professions governing body, was formed in 2004; incorporated in 2006. There are 827 certified professionals (CBAP)^® in the world. Compared to the Project Management Institute (PMI)^®, which was incorporated in 1969, offer five certification programs and has nearly 300,000 certified professionals. You may say that your company has had BAs for the last 5 or 10 years. Then I say your company is one of the forward-thinking organizations that has recognized the benefits that the BA role provides in developing IT business solutions.

Now I believe this discussion will go on for years; but as this is my blog, here I get to put my two cents in. First, let’s define the role of the BA in which we discuss. Many organizations have a quality assurance team, department or processes within the IT application development team. As these people support system or user acceptance testing procedures, these people are Business Analyst. For this discussion, I refer to the Business Analyst that works on the front end of the project life cycle. Who develops the Enterprise Architecture, gathers business requirements for business process improvements and makes the business case for IT business solutions projects to make those improvements.

As the role of the BA is to develop requirements and make the business case for IT application development projects, this is an IT function; therefore the BA is an IT position and should report to the IT management as opposed to the Business management. Although the duties that the BA performs may put him/her in front of external customers of the company, their goal is not to perform the business of the company but to recommend IT business solution projects to improve business processes within organization; this is an IT function.

If your organization is large enough to use terms such as Business Process Organization (BPO) and Project Management Office (PMO); then you should find the BA at the heart of the BPO. The purpose of the BPO is to analyze and recommend improvements to business processes. So now you say that in most organizations the BPO is a business team; I would reply that it should be a combination business and IT team. The improvement to business processes may require a business solution, such as upgrade or replace business machinery or training; or an IT solution, such as application enhancement, system training or system upgrade. Therefore, the BPO should be made up of business positions and IT positions working together to determine the best solution to business issues.

One thing that I would change in many organizations is that I believe the BA should sit more in the vicinity of the business unit(s) that they support as opposed to sit in the IT Department. BAs will be much more effective when they fully understand the business processes in place, issues that business workers face and the daily going-ons within the business unit(s). Also, easy approachability to the BA for the business gains buy-in to the duties and recommendations of the BA.

So there is my opinion on the subject, what is yours?

Technology at the forefront in Haiti

Friday, January 22, 2010 by Aaron Whittenberger

As you watch the enormous humanitarian relief effort going on in Haiti on the evening news this week, following the devastating 7.0 earthquake that hit that country on January 12th, you can probably imagine the technology and IT infrastructure that the U.S. Department of Defense and other agencies has put into place to assist in that relief effort. Read more about it here. The Haiti government turned over the operation of the one runway airport at Port-au-Prince, the nation’s capital, to the U.S. military. An acknowledgement of the U.S. military’s prowess in logistics and technology. For a few days as the relief effort ramped up news reports of delays at the airport were heard, but as that relief effort got organized those reports of delays ceased even with the amount of aide and volunteers flowing into the country were increasing.

What is not reported on the evening news is how an army of geek volunteers from the private sector is supporting that relief effort. Leading the way are organizations like CrisisCommons, Ushaahidi, the International Community of Crisis Mappers and InSTEDD, according to an InformationWeek artical. Application software development gets into the mix, undertaking such tasks as developing ways to help locate U.S. citizens and provide information online about Haiti and how to donate money, developing a timeline of events and a wiki of information online, a GPS-compatible street map of Haiti, an English to Creole dictionary for IPhones and Android mobile devices, and a system to use Twitter messages to ask for or offer assistance to those in need. "We've been working a lot at Sunlight Labs to get application software developers to organize and work together in volunteer communities. Developers may not be competent with a saw, but are starting to realize they have a skill they can contribute," says Clay Johnston, director of Sunlight Labs. "The tools are available, and methodologies like agile project management have been popularized that can facilitate this."

In light of the reports of the failings of the coordination of relief efforts following Hurricane Katrina and the reports of the relief effort in Haiti, it is clear that it is IT solutions that have been put into place to better support humanitarian relief efforts worldwide and that technological advances has clearly moved into the 21st century in support of those efforts.

Is IT Qualified To Satisfy The Business?

Monday, November 9, 2009 by Aaron Whittenberger

“IT executives increasingly implement marketing initiatives to improve the communications with their business customers. But these efforts often focus solely on the brand aspects of the services under the IT’s control without understanding the business’ perception of IT. To maximize the success, IT must add business satisfaction assessments to its tool kit. Understanding business satisfaction requires qualitative and quantitative data that capture customer expectations and perceptions through different types of interactions such as interviews, panels, focus groups, complaint systems, and surveys. This report provides best-practice recommendations, survey templates, and questions to guide IT executives through the deployment of a business satisfaction assessment. It applies Forrester’s deep expertise in external customer satisfaction to the interface between business customers and their internal IT suppliers.” says a new Forrester report.

I have served on countless business application development teams within several organizations in the Southwest Ohio and Cincinnati Information Technology community, one thing I can say is that most IT organizations do not gauge business satisfaction with IT business solutions. I have served in only a couple of organizations where the business serves on the IT governance committee. An organization does not have to be “big” to have an IT governance committee. No matter what the size of the organization decisions are made as to priorities in IT work. IT governance does not have to be a long drawn out process or take great time commitment from the business or IT executives, but business involvement in IT governance goes a long way in gaining business buy-in as you roll out the IT business solutions to the business.

Involvement in IT governance is just one way that many organizations in the Greater Cincinnati area can improve the IT-business relationship. The Forrester report goes into ways to solicit and gauge business satisfaction with IT business solutions. Doing so should affect decisions concerning not only IT business solution delivery but also IT Infrastructure and IT outsourcing initiatives.

IT Outsourcing in for some big changes

Tuesday, October 6, 2009 by Aaron Whittenberger

A new report from Gartner Research Firm

IT Outsourcing is not going away anytime soon, but a new report from Gartner Research states that the market is in for some big changes. The report predicts that one in four business-process outsourcing firms will disappear within the next three years.

The article in InformationWeek gives advice to CIOs who wish to initiate a new IT Outsourcing contract on warning signs to look for in your prospective BPO partner that would indicate this firm may not be able to fulfill any new contract:

1.    Are they losing money?
2.    Are they winning new business?
3.    The loss of marquee clients.
4.    Poor capitalization is impeding growth.
5.    Toxic exposure to tainted financial firms.
6.    Lock down your exit strategies.

In another article in EconomicTimes I read that IBM will goble up half of India’s IT outsourcing business in 2010.

This is not to suggest that the offshore IT outsourcing business is coming home. IBM’s business is international. With IBM awarding one-half to 1 billion dollar contracts, many India firms will not be able to compete in delivering hardware, software, IT consulting services and integrated business solutions. IBM is one reason that 25% of IT BPO firms will meet their demise within the next three years.