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 most strategic roles of the Business Analyst (BA) is that of a Management Consultant. This role is not drawn out by the IIBA® in the Business Analysis Body of Knowledge® (BABOK®), but it would fall in the Enterprise Analysis knowledge area. Perhaps this role will be given its due recognition in the Business Analysis Body of Knowledge Guide version 3.0 now being developed.
The Business Analyst, Enterprise Analyst (EA) or Enterprise Architect (EA) as they are sometimes called in this role, is often engaged in enterprise wide or market research activities that gives the person great insight into the organization and the market(s) in which it operates. Such activities as feasibility studies, market research, product analysis, SWOT analysis, Capability Gap analysis, analyzing business issues and opportunities, root cause analysis, defining business needs, developing business cases and documenting business processes gives the analyst a deeper understanding of the business and the environment in which it operates that sometimes even the senior management of the organization does not have. This is not saying that business analysts are smarter than business management, it is saying that analysts get deeper into the details of the analysis, which can derive greater understanding of these details about the business.
The creation of internal IT Consulting groups is becoming a common place in companies; in particular a few organizations here in Cincinnati and Dayton in which I have consulted. These groups are often created to perform business analysis activities on the enterprise level; to consult the business on the capabilities and limitations of technology and to consult enterprise application development teams on business needs and requirements. Whether BAs, or the IT Consulting Group, is consulting executive management or business lines management; this is consulting business management to take advantage of business opportunities and diminish business weaknesses and issues.
The creation of an internal IT Consulting Group shows great emphasis to business analysis within the organization. Even if your organization is not large enough to justify a formal IT Consulting Group, giving emphasis to business analysis as management consultants helps the business management make more informed decisions, helps the organization better accomplish its strategic goals and initiatives and enables better change management.
How does your company utilize business analysis for strategic value?
One of the strategic roles that the Business Analyst (BA); Enterprise Analyst (EA) or Enterprise Architect (EA), can perform for the organization is the maintenance of an internal knowledge base, often called an internal Business Analysis Body of Knowledge. This would be a centralized, electronic repository of artifacts concerning the organization and the environment in which it operates. This is not a task defined in the IIBA® BABOK®, however would fall under the knowledge area of Enterprise Analysis.
This repository should describe not only the organization but the environment in which it operates. It should include an Enterprise Architecture; divided into Business Architecture, Information Architecture, Application Architecture, Technology Architecture and Security Architecture. Along with that it should include BA training and information material to quickly ramp up newly hired Business Analysts. Also, some type of mechanism to ensure you are capturing the business knowledge of Business Analysts who are leaving the organization, so that valuable business knowledge does not walk out the door.
When a Cincinnati, Dayton or other community business has a BA community that is actively maintaining a centralized, electronic internal body of knowledge; that organization is well on a maturity path from a BA Practice to a Business Analysis Center of Excellence (BACoE).
By maintaining this body of knowledge within the organization, the Cincinnati, Dayton or organizations across the country and globe can help deliver business analysis services across the organization at the same level of service, move its business analysts among the business lines and business units within the organization with ease and little ramp-up time, make better business decisions based on an enterprise-wide knowledge base, enable business management consulting within the organization. These business decisions can have significant impact on the company’s bottom line.
Does your organization have an internal business analysis body of knowledge?
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.
Attention Cincinnati and Dayton IT professionals: The IBM Tech Trends Report is in. You can view a copy here. Over 4000 IT professionals from 26 countries participated in this survey. It should be no surprise that the top application development areas are in business analytics, cloud computing, mobile and social business.
Specific skills needed by application developers were java, .net, xml, php and html5. Not any real surprises here either. Fortunately, STAR BASE is a leading Cincinnati IT consulting company and can provide IT staffing for any of those areas and skill sets.
Still a very timely topic of discussion, from the person who wishes to transition into a Business Analysis career who wants to know what skills they must have to be a successful BA, to the new BA who wants to know what skills they need to add to their repertoire, to the Senior BA who wants to know where to go next in their career; everyone wants to know how to improve their skills to get to that next level of their career.
Two of my colleagues take on this subject, Kupe in BA Times discusses soft skills vs. hard skills. He notes the importance of soft skills in being a successful BA. Kupe is not suggesting hard skills are not important, he notes that hard skills is what is going to get you noticed, stand out in a crowd, but it is the soft skills that will land you on that next level and keep you there. After all, nobody wants to work with a jerk.
Laura discusses whether Project Management is the next step in the career of a Senior BA at Bridging-the-Gap. She discusses how this use to be the case years ago but is no longer the only option. In fact, we now see the reverse happening where Project Management professionals transition into Business Analysis careers. For those who have reached the pinnacle of their BA career, besides Project Management, they could move into BA Management, creating a BA Office within their organization, Enterprise Analysis, Management Strategic Consulting, Business Consulting, Business Subject Matter Expert or external IT and Business Management Consulting. There are as many paths as there are people willing to forge them.
Elizabeth Larson will be taking on a similar topic at the Southwest Ohio Business Development Conference in April. She will discuss whether Business Analyst and Project Manager should be one or two roles within the organization. At this very same conference I will be presenting the topic “Improving Your BA Skills: From Self-Assessment to Self-Improvement”. This is where I will discuss the many ways you can gain new and improve current BA skills. This is a conference not to be missed if you are in the Cincinnati area on April 29, 2011.
This topic has been around for many years and as you can see is still a very hot topic today, getting a lot of press. There is no one way to build your career, forge your own path. Remember you are in charge of your career. Unemployment, downsizing or IT outsourcing may derail your plans for a time, but don’t allow that to stop you permanently. For some general guidelines, as Kupe suggests, develop the hard skills necessary to accomplish the tasks of a BA and get you noticed. Then develop the soft skills that will land you on that next plateau of your career. Remember, that your current job is not your career, it is just your current position in your career; you decide where to go next. Let your passions guide you. If Project Management doesn’t excite you, good; now you have other options to continue your career.
s To Look For When Hiring Consultants” listed several qualities that would be very difficult to “look for” prior to hiring the consultant. It would be very difficult to pose questions during an interview to gage the Consultant’s A Penchant for Facts, Sift and Filter Out, Think Ahead, Precision, Self Discipline or Honest to a Fault. Also if you do not need the consultant to fulfill a leadership role within the organization or IT business solutions team then Leadership is not a quality to look for in applicants. My colleague, Jeff Welsh, wrote a two piece blog on the "Seven Deadly Sins of Consulting", in which he notes the seven things that a Consultant should never do when engaged at a client. A lot of them are common sense things and some of them come from experience. After reading all these blogs, I have compiled a list of qualities to look for in applicants for a BA role within your organization. Questions can be formed during an interview to help gage the applicant’s ability in these areas.
1. Depth and breadth of experience and knowledge
A review of the resume/CV will show the applicant’s prior work experience. The more senior, critical or strategic activities you wish the consultant to perform, the greater work experience and knowledge you will want the consultant to have. Also, ensure the consultant’s work experience is relevant to the tasks you will ask the consultant to perform. Such as, if you are implementing a new ERP package, find a consultant that has done ERP implementation projects.
2. Dedication to profession and work
The BA Consultant should have great dedication to the BA profession and to his/her own work. A consultant that stays abreast of BA resources, keeps up-to-date on training and/or has achieved BA certification is showing dedication to the profession. Every business person should take great pride in their work and deliverables. The BA Consultant is no different.
3. Excellent communication skills and interpersonal savvy
Effective communication is essential for Consultants. Oral and written communication skills are a necessity. Communication to the client should be relevant and timely. Miscommunication and Under communication to the client tend to shorten your stay at the client. One of the posts noted above stated “Honest to a Fault”. Sometimes, blunt honesty backfires and cause greater issues. Finesse and tact should always be practiced when handling sensitive issues.
4. Customer focused
All Consultants, including BA Consultants, should always be focused on delivering value to the customer. During the interview probe the Consultant’s commitment to the customer.
5. Results oriented
The BA Consultant should be dedicated to delivering results. If the applicant’s resume/CV does not show their achievements and results then probe the Consultant’s dedication to adding value and delivering results in a timely manner during the interview.
6. Can see the “big picture” and work in the details
Having the “big picture” view, knowing how your activities fit into that picture, and then being able to work in the details of your activities is truly an art. Consultants are often asked to perform the tedious tasks, such as research and document activities that require hours of repeating processes. It is not glorifying or high-profile work, but necessary to be completed. Being able to go beyond customer expectations doing these kinds of tasks is a way to prove your value to the client. While working in the details, not taking your eyes off the big picture and ensuring that decisions are made that keep the big picture in tact is also an art.
7. Team player
Personality conflicts are always detrimental to the team unity. Bringing on Consultants that do not work well with the team causes people management issues and divert resources to handle those personality conflicts rather than more productive activities. Derogatory comments about other consultants, or worse the client’s employees, is a fast track to causing team conflict. As Jeff puts it “don’t be a prima donna”.
8. Creative thinking
Sometimes solutions to complex business problems require the ability to leap beyond conventional thinking. They require creative solutions that require creative and conceptual thinking. Situational questions can devolve the Consultant’s ability to “think out of the box”.
9. Personal organization
Being personally organized helps deliver results sooner. Having to continually search for documentation or other items can be a great waste of time. Being able to remember meeting appointments and being on time to meetings show a good degree of personal organization.
10. Dependable
Being where you are suppose to be at the time you’re suppose to be there is a great attribute for Consultants. Being punctual really is greatly appreciated by the client, so when you are going to be late to work or an appointment communicate the delay. That too is appreciated.
So if you are responsible to bring in consultants to help your IT business solutions staff you have some guidelines to look for when determining who to bring in to complete your IT staffing. If you are a BA Consultant make sure you exceed customer expectations in the areas above and you will have a satisfied customer.
I know some of my application development colleagues my say “heard it”, but a virtual desktop is cool! We are currently running Windows XP as our company standard. We moved our 9 physical servers running Windows 2000 on ancient (and failing hardware) about 2 years ago. Most of our clients are currently on XP, but some are looking into moving to Windows 7, and one is going to Vista. When my application development friends stop laughing, they are doing this because they have certified their testing with Vista, and they will have to re-certify with Windows 7. They want to move to Vista now, and move again in a year or two.
We can just follow the Windows upgrade path, but given the success of virtualizing our servers, my boss gave me the green light to review our desktop strategy. Some application development and management people would say why? Well it gives us flexibility in what we can do. If we just move to Windows 7, and our clients are still on XP, then we are too ahead of the curve in terms of support. We do have some XP only development tools, so why not just keep them on their OS? With a virtualized desktop, we can run any OS we want. If our clients want us to run specialized software, we can set up an OS just for that client. The other big change is that we are using Ubuntu 10.4 as our host operating System. This is to reduce the memory requirements, but it has other great side effects. Our consultants can learn (at least the basics) of a new OS! If they are under constraints, they can fire up their Windows VM and get to work, or they can do the basic stuff (surfing, checking email) on Ubuntu. In time they can learn how to install packages and other tasks without disrupting productivity. The can even use Windows 7 and learn it too. The best side effect (for management anyway) is that we can still get a lot of mileage out of our 5-7 year old laptops. Our laptops have 2 gigs of RAM, so even if we went pure Windows 7, we would have a performance hit, especially when you fire up an IDE like Eclipse! The more I play with Ubuntu, the more I like it. I will probably use it as my main OS, but others can use XP, Vista, Windows7, or whatever we can virtualize. Choice is a great thing!
This month I have been exploring the IT and Business working relationship. It is a hot topic these days getting a lot of press. STAR BASE Consulting is conducting a pulse survey asking what is the relationship like in your organization. BA Times notes that your “Customers Don’t Want to Work with You!” A couple of weeks ago, I looked at the relationship and how BAs could reduce the rivalry, if there is one. Last week I took the relationship to the Organizational level and described how the Organization can build a unified, collaborative team.
You say Organizational Structure, Seating Charts, Enterprise Analysts (EA) and Business Analysts (BA) are all find and dandy, but what about me and my small IT shop? I don’t have enough people to split into EAs and BAs. How do you split one person? Small-to-Medium Sized Businesses (SMBs) usually have an IT shop of 10 people or less. Maybe at most 2 of them will be BAs. I even had one CIO recently tell me that in his small shop he doesn’t really have full-time BAs, but five Programmer/Analysts that do their own analysis. So we will assume these are the hybrid Developer/Business Analyst role within the organization. So in this kind of structure, how can we improve the IT and Business working relationship?
In SMBs, where resources are scarce, it is not uncommon for people to perform multiple roles or “wear many hats” within the organization. In today’s economy, where IT spending and salaries have stalled but the workload has not: IT is getting even more squeezed. In this situation, when the SMB cannot make one of its BAs the strategic role (EA), or perhaps the organization does not need full-time enterprise analysis activities going on, it becomes even more crucial for the BAs to assist in building a unified, collaborative working relationship between IT and the business. So let’s look at some of the key points I have discussed in the past two weeks.
Seating Chart - Two Desks
When looking at this seating chart you realize that there is only one person, so you only need one desk, correct? Allowing the BA to have a desk in the IT Department and one in the business unit of the organization allows them to build a working relationship with each team. By spending part of the day or week with each team, the BA can understand the challenges each team faces. Even if the BA can spend only part of his/her time sitting with the business unit that they are suppose to support, it helps build awareness of the daily challenges that the business people face on a daily bases. This helps the BA identify business needs to improve business processes and make the business run smoother. This also makes the BA approachable by the business people to assist to work on problems and will help get buy-in from the business people when the BA has analysis tasks that require business input.
Communication is Key
Communication is a key skill for a BA, but becomes even more important in this situation. The trap that the BA must avoid is the business feeling that the BA is approachable only when he/she is sitting at the desk in the business area. Or that the BA is available for IT project work only when he/she is sitting at the desk with the IT business solutions development team. The BA must communicate to both teams that he/she is available whenever they need assistance; it is their goal to assist. The BA also must represent the needs, desires and limitations of each team to the other. Make the IT application development team understand the business requirements and why these requirements are needed. Make the business understand the time involved to make “a simple change” to an enterprise application. By representing each team to the other, and making each understand the work at hand, whether that is requirements or solution testing, they are creating a shared vision across the organization.
Build the Bridge
Through effective communication of the needs and limitations of one team of the business to the other and representing the each team to the other the BA can build a bridge of understanding between the two groups. By making each side realize that we are all in this together and desire the same outcome, you can build a relationship of trust and get rid of the “Us vs. Them” scenario and replace it with a collaborative working relationship that brings about better IT solutions to business needs.
Whether in a large organization or SMB, business must go to IT for technology solutions. Even in an IT Outsourcing situation, there are on-site IT people to directly talk with the business people. In SMBs, where resources are less and people “wear many hats”, the BA role of liaison becomes more important to overall IT business solutions success.
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.
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.
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!
You have probably heard your parents or grand-parents talk about when they were younger and how they had to walk to school, up hill both ways. When they shared this story with you it was to prepare you for times when things weren’t so easy and to provide you with their knowledge and advice from their hard earned experience. 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.
1. Bill for time not worked. This will be the quickest way to end up out of a consulting gig. Make sure you bill the client only for the time you actually work. This can be tricky if your clients are friends. When you go to a job like this, you know there will be a period of time spent socializing, especially when you first arrive. Don't bill for this time. Start the billing period when you start working. Sometimes clients will have celebrations during the day. If you don’t want to appear anti-social, by not going, just don’t bill. If there are any questions, ask the account manager to find out. If you are the account manager, ask your client manager at one of your one to one meetings if it’s ok to bill. Some client’s have a culture where that is part of the expectation.
2. Negotiate rates and make deals with the client. If you work for a consulting firm, you know there are channels for clients to go though to make requests.. Most firms have some sort of account manager to handle those issues. Direct the client to the account manager. I had one consultant that actually went so far as to look in the client’s AP system to see how much we were getting paid and then wanted to negotiate a higher rate with the client. This particular action did not end well for the consultant and he has not been able to be considered for other assignments in this client even when his skill set was ideal. Never, ever work out a side deal or moonlight with a client this can comprise your integrity and jeopardize the trust between you, the consulting company and inevitably the client.
3. Act like a prima donna. Yes, you’re good, that’s why you have been hired. I actually heard a consultant tell the client that their employees were stupid. Hello? You are there to serve those employees. You don’t know what kind of constraints they have had to work with. Hind sight is always 20-20. Its always far better to politely make suggestions. You may find out your brilliant idea was considered previously and there was a very valid reason for it not being implemented. It’s much better to NOT have egg on your face or your foot in your mouth.
4. Miscommunicate or undercommunicate when engaged at a client I believe that the client should know what is going on with their project. Many times I have had to be the bearer of bad news. I also like weekly status reports to let the client know what I have worked on and what I’m planning on doing. If at all possible I like to let them know a percent complete. Years ago, I heard another consultant tell the client he was “unit testing”. The client assumed that meant he had all the functionality done and was testing. The reality was he had about 10% of the functionality done and was testing just that one small piece. When the truth came out, it was not pretty.
Tomorrow I will finish off the last 3 sins.
To be continued……
There are many skills needed as an application development person to be successful, but none more important than communication. In fact, that is point of our job, to be able to communicate to our peers, partners, and customers. I believe that most organizations make money in spite of the immense lack of communication. Most of the application development people I know complain more about the policies and procedures than about anything else (although it’s always something!). Aren’t policies and procedures communication? Certainly, but it’s the internal communication that enables and drives the external communication. Everything we do has an impact on our ability to communicate. Say the wrong thing to a journalist, and you will be removed. Miss that deadline, forget about the promotion. Governance is important for the security of communication, but when do these rules get reviewed? Ask any software development person or manager why, and the answer usually is “that’s how we do things here”. The real answer is that someone set that restriction to an event that happened long ago, and nobody is willing to change things. If communication is the life blood of an organization, why would we restrict the life blood arbitrarily? If this sounds like your organization, maybe you need to review how you are handling your communications. If you need help, STAR BASE Consulting has years of experience triaging your life blood, and making it flow easier, better, and stronger.
Coders - DO NOT REPEAT YOURSELVES. Put your code in reusable general purpose functions, and then reuse them. Refactor your work if you need to add a parameter. If you find yourself writing a bit of code (e.g. getting a configuration value) more than once, put that code in a function, and call it next time rather than writing the code again. The goal is not to reduce the amount of code you write, though sometimes that is a result of DRY coding. The goal is to improve the maintainability of the code. If at some point down the road you need to change the way you retrieve a configuration variable, you don't have to go change the code in a million places, you simply change it in the one function whose job it is to retrieve the value.
The age of IT specialization has been replaced by an emphasis on skills that can translate across the enterprise. According to Forrester, this shift can be traced to a number of emerging trends:
* Maturing technologies such as software-as-a-service and business intelligence are changing IT skills requirements;
* The growing array of outsourcing options have altered in-house staffing priorities, with more specialized skills increasingly likely to be outsourced; and
* The continued search for cost-reduction opportunities has changed how IT decisions are made.
With those trends in mind, here is Forrester’s list of the 13 Most Important IT Roles, based on the percentage of IT executives who believe each role is growing in importance.
#1 – Business Analyst – 70%
Talk about holding all the cards: Not only do these IT pros know the business, they also have their fingers on all the insight. As the saying goes, knowledge is power.
#2 and #3 – Architecture and IT Strategy/Planning – 66%
As IT has evolved into an increasingly important part of business, both of these roles have become critical in ensuring that every department has the infrastructure and tools that it needs.
#4 – Project Management – 65%
What business doesn’t need people who can mange multiple personalities, master numerous business processes, understand different aspects of the business and make sure things get done?
#5 – Security – 62%
With the onslaught of breaches and identity theft that constantly filters through the headlines, not to mention the growing mandates for better access controls, is there really an explanation needed here?
#6 – Service Management – 60%
The whole thing about the customer applies here to, as managing IT from the customer’s perspective has become de rigueur.
#7 – Client Relationship Management – 56%
We’re in the age of customer service, and anyone who’s mastered the art of managing CRM environments is worth their weight in gold.
#8 and #9 – Business Continuity and IT Financial Management – 55%
With companies paranoid about their systems surviving natural and man-made disasters, and cost-effective IT spending more important that ever, it’s no wonder these roles are on the rise.
#10 – Portfolio Management – 50%
This is a growing area driven by the desire to demystify the measurement of the impact of IT investments.
#11 – Asset Management – 34%
Like other spin-offs from more general business roles, this is another specialized function better outsourced.
#12 – IT Research – 30%
Research? That’s what consultants are for.
#13 – Human Resources (within IT) – 20%
HR for IT is an increasingly unnecessary luxury in an increasingly self-service environment.
Take a closer look at that list and you will notice Business Analysis has been ranked #1, #2, #3 and #10.
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.
A contributing factor to that increase may be a new trend in the IT Outsourcing called “Homeshoring” or “Onshoring”. This is an alternative to offshoring your IT outsourcing by placing it in low-cost, non-urban U.S. areas. Monty Hamilton, CEO of Rural Sourcing Inc., recently spoke at the 2010 Outsourcing World Summit, where the idea of homeshoring was well received.
As salaries in India increase because of past American offshoring IT strategies, rural America becomes more competitive. This along with the other benefits, such as culture and the favorable time zone, may spark an increase in the coming years to homeshoring.
Mr. Hamilton notes that Small to Mid-sized Businesses (SMB) are first to realize the benefits of homeshoring. He also makes note that a few jobs may still be lower cost as offshore, such as moving stack A to stack B. However, when it comes to IT staffing, enterprise application development and IT strategy consulting, homeshoring is the growing trend.
This post may shock you... the Java Rocker is going to talk about legacy iSeries and AS/400! Before you panic, and call it the end of the world, let me continue. This post is about running all of the cool new Web 2.0 things on your IBM hardware. Really! Even in Cincinnati! Many people, (myself included) thought the old IBM hardware was only for RPG and COBOL (shudders). It turns out that IBM has been adding functionality to run Linux on the box. That means Wikis, Ecommerce, blogs, and web applications are now there for iSeries-AS/400 people. The catch is that your iSeries needs to be up to date, which sadly for most organizations is not. My IT consulting colleagues at STAR BASE are good with taking your tired old hardware and doing the maintenance necessary for the modernization piece. They get your hardware and software cleaned up and ready, so I can help you with all of the cool new application development projects that I have been talking about.
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?
Powered by Compendium