Skip to main content

Tag: Skills

The Importance of Collaboration with Business Experts

importance1As business analysts we have a wealth of knowledge, information and experience to tap into. There are many different books on eliciting, documenting and managing requirements for a business wanting a new capability or a new product or system. There are numerous web sites that have articles and information for business analysts, plus many blogs discussing ideas and issues facing business analysts. There are many different techniques to use and methodologies to follow. And for projects where there are hundreds of requirements from many different stake holders we have Excel spreadsheets, and requirements management tools to assist with controlling and managing the requirements. So with all this to help us why do things still go wrong?

I was thinking about this the other day while riding my mountain bike through the forest. I enjoy mountain biking and I have an average bike capable of doing what I need of it. My requirements were simple when I started and have not changed much, I needed something that would go off road in a local forest area which had purpose built tracks and I was not into jumping so something basic but strong would do. I went to a local bike shop that had a range of bikes and I was then asked a lot of technical questions about the type of riding, brakes and suspension needs I had. Mountain biking is a very technical sport and although the bikes don’t look that different they range in price and specification greatly. As the store assistant was the expert I asked for his advice and then made my decision based on price and features. As usual I ended up spending a little more than I had intended.

So what has that got to do with business analysis? Well, in the bike shop the assistant was seeking requirements and was also the expert. He knew the products and could advise based on his expertise and experience. He knew the questions to ask and explained the terminology to me as he described the different bikes’ specifications. So, as business analysts we know how to elicit (ask the right questions), document (write the requirements down clearly and concisely) and manage requirements (store them and apply other attributes to them). But we are not always experts in the industry, or area of business, or product we are dealing with. So we rely on experts from the business, not only for requirements, but also for information and advice. If we have incomplete or incorrect requirements, do we as business analysts really know that this is the case, if we are not the experts in that area? And do the experts from the business really understand what the requirements are meant to convey and really understand how important they are?

In many instances we gather requirements and then get the business to review and sign off on them. But this is often after only a single pass over the requirements and may not be to an adequate level of detail. It is important that we involve business people in a more collaborative approach and expand and dig deeper into the requirements as we get closer to developing them. Having a key subject matter expert from the business working closely with the business analyst to help detail the requirements can stop issues with terminology and terms, and make the requirements more easily understood by the business. I have worked in a few different industries and have found each one has its own language full of acronyms and technical terms. It is important that this language is used in the requirements. Even if we know the subject area well, it can still be good to involve someone from the business to work with in detailing the requirements. After all they are the users not you, and the user experience and interaction with applications is so important.

I have also seen places where the business is only involved up front and then, as requirements are developed, the direction of the solution may change in isolation from the business. This may cause many problems further down the track when the business sees the solution as part of user testing or worse at implementation time. The agile way of developing does encourage greater closeness and collaboration between the business and developers. Thus, the inevitable changes can be discussed and agreed with the business as they are being developed. Even if you’re not using an agile approach, close collaboration between the business analyst and the business is very important, as is continuing that communication and collaboration through the development and testing phases.

No matter what technique or methodology is being used, the tools you have available, the industry you work in, it is more about people. Finding experienced and knowledgeable business people to work with and learn from is important. The can help with ensuring the right language is used, and agreement on requirements is reached. They also will play a part in developing the solution. Finding that expert or group of experts to help make the right decisions is truly worthwhile, even if you end up spending a little more time working on requirements.

Don’t forget to leave your comments below


Ross Wilson is a Principal Consultant with Equinox Limited in Auckland, New Zealand, specialising in business analysis, and training. He has been working in IT for 25 years and has a wealth of varied project experience in a number of different industries. For the last 14 years, he has focused on business analysis, training, project management, and team leadership. Ross can be contacted at [email protected].

Show Your Value: Get Paid on Commission

Kupe’s Korner

I recently re-read an article on CIO.com, Should IT Workers Unionize. The author put forward the notion of IT workers unionizing.  There were many comments left by readers for and against the model. The idea of BAs unionizing is a concept that I found fascinating, but one that I totally disagree with.

This article reminded me of a conversation I had with a good friend, David Walker, with Borland.  He asked me if I thought business analysts would do anything different if their salaries were truly based on performance, A.K.A. commission based.  This is the complete opposite of unionizing. At the time I did not give him an answer, but now I believe we would absolutely change the way we approach projects, determine what techniques to use, and how spend our time every day. Projects are still failing or challenged at a high percentage.  As analysts we play a critical role in the success of projects.  If we really want to improve project success, let’s get paid on the success of our projects.  Are you feeling the wave of change? 

Let’s take a look at the sales profession for a moment. They sell products or services for a company and most of their salary is based on how well they perform against sales goals.  They miss their goal, their commission is less; they meet their goal they get their full commission, if they exceed their goal they get their full commission plus some.  So as a BA we play a key role on teams to implement projects or change for a company.  If your project fails your commission is less, if it is challenged you get most of your commission, if it is a success you get your full commission.  Man…I am getting excited just thinking about it. 

Ok, even if we don’t go the point of changing our salary structure we need to change our mindset and work like we are being paid on commission.

Here are a few characteristics of successful sales professionals that we can apply to our profession.  A successful sales person:

  • Ensures their goals are clear. Once they are set they work towards their goal every day.
  • Does what is necessary. Nothing more, nothing less.
  • Finds resources that can help them reach their goals.
  • Builds relationships to build credibility which leads to trust.

Goals: Before you start running down a path to elicit, analyze, and communicate requirements, make sure you, the project team, and business stakeholders are all on the same page regarding the scope and objectives of the project.  As the project is underway you should always look at the goals to make sure you are still headed down the right path.

Do what is necessary:  As an analyst there are many techniques at our disposal.  Just read the 300 plus page IIBA BABOK and you’ll see how many techniques we can use. Every project is different, so you need to do the work that will add value to your project.  Nothing more, nothing less.  For more information on this topic check out this webcast.

Find resources:  If you recall my last blog post, I talked about being the go-to person.  I said you need to be a consumer of information. There are so many resources (people, training classes, articles, discussion boards, etc.) available to you, and you need to find them and use them to be successful.  Here is a quote that I continually reference. 

“No one lives long enough to learn everything they need to learn starting from scratch. To be successful, we absolutely, positively have to find people who have already paid the price to learn the things that we need to learn to achieve our goals.”
-Brian Tracy, Author

In today’s environment we can’t go it alone.  Find the information and people you need to help you.  There is no shame in asking for help.

Build relationships:  Projects are all about people.  We work on projects with people and projects are created for people.  People want to work and help those they trust.  Take the time to really get to know the people you work with. 

Let’s not wait until we are paid on commission to change the way we work.  If we change our mindset now our project success rate will start to improve.  Things will be so good we’ll ask to be paid on commission!

Follow me on Twitter, http://twitter.com/Kupe

Preventing Disasters; How to Use Data to Your Advantage

The late Lew Platt, former CEO at Hewlett-Packard once stated, “If only HP knew what HP knows, we would be three times more productive.” This is a typical situation in large organizations, where far too often, disasters arise from lack of awareness. Critical information is available in the organization, but goes undetected, is not communicated or is blatantly ignored.

Take the recent mortgage meltdown, for instance. The banking industry has a wealth of data on consumers, robust credit risk models, as well as lessons learned from the past. Their analytics told them which loans were too risky according to traditional models. Yet, they decided to relax their standards, ignore the data…and the rest is history. Or, take the recent PR debacle around Southwest Airlines’ plane inspections. The FAA had inspection logs that could have told them that the planes were passing with flying colors at unprecedented rates, yet no one suggested conducting a site visit to see if the airline was actually performing those inspections. And when low-level employees reported issues to their managers, that information was not passed on. Fortunately, in that case, a tragedy was avoided.

If there is a question we should be asking in the current economic and regulatory environment, it is “Why does accountability so often fail, and what role does analytics play in preventing these disasters?” Organizations need to understand why they fail to detect early warning signs, how to filter and monitor available data to create actionable information, and how correctly applying analytics can turn data into knowledge. That knowledge can then prevent disasters and increase competitive advantage.

Why Accountability Fails

The repeated disasters that occur due mainly to failures in accountability arise for the following reasons:

  • Large, complex organizations (or environments) make it difficult to know what is happening “on the ground” and detect significant changes in the environment.
  • Very often, players in the organization (managers, employees, others) receive incentives only for presenting a positive picture and anchor on how things have worked in the past.
  • Organizations measure and monitor only past-focused, outcome measures, which only indicate a disaster once it has already occurred.
  • Many organizations lack the skills necessary to manage data, much less apply analytical techniques to make sense of that data and keep an accurate view of the current operating reality.

The Impact of Anonymity

The lack of awareness that often brings disaster stems from the anonymity that characterizes today’s organizations. A hundred years ago, most business transactions were conducted face to face. Business owners walked the shop floor. Customers who bought eggs from the village shopkeeper knew not only the shopkeeper, but also the farmer who raised the chickens. Loans where made to people the banker knew personally and regulations were made and enforced by local officials.

The more complex an organization becomes, the less transparency there is, and the more difficult it becomes to make good decisions. Consumers and producers don’t know one another. Decision makers and implementers don’t have direct lines of communication. By the time information reaches a decision-maker at the top, it is usually highly filtered, and often inaccurate. The information and implications have been spun so as not to upset management or cast dispersion on employees, and therefore fail to present the reality of the situation.

These conditions not only impair the organization’s ability to understand what is currently going on, but also remove any ability to detect change in the environment. Outside information can effectively be closed out in extreme examples. The U.S. automakers in the 1970s, who looked out the executive suite window into their parking lot and saw only U.S.-made cars, determined that Japan was not a threat. Meanwhile, dealers in California had significant early signals in their sales numbers that Japan was indeed a threat to the U.S. auto industry.

Incentives for Bad Behavior

An even more insidious problem is that disasters often arise because organizations have actually encouraged behaviors that lead to them. The filtering of information cited above is actually a very mild form of this. Employees and managers are rewarded for highlighting what they’ve done well, so why would they ever identify something that is going wrong on their watch?

We tend to blame those who bring bad news, whether they deserve it or not. Consider any major whistle-blower of the past. The amount of scrutiny, negative media attention and damage to their career is enough to dissuade most people from taking a stance. And yet those same people brought to light, and often prevented, significant disasters in the making.

So many organizations reward those who bring in good short-term results, prove out the organization’s current business model and don’t ruffle too many feathers. In return, we get exotic financial instruments in an attempt to make quarterly revenue, low standards on food or workplace safety and fudging on project and financial status reports. The contrarian voices pointing out the impending disaster go unheard and unheeded, and changes come too late to matter.

Driving While Watching the Rear View Mirror

The vast majority of the data that organizations look at represent outcomes that are past-focused. The traditional financial statements show the outcomes of business activities (revenues, expenses, assets, liabilities, etc.) while nothing in those statements measures the underlying activity that produces those outcomes. Hence, nothing gives any indication of the current health of the organization.

Kaplan and Norton sought to remedy this with their Balanced Score Card approach. By focusing on the drivers of those outcomes, the organization should be able to monitor leading indicators to ensure the continued health of the enterprise. Relatively few organizations have fully adopted such an approach, and even those few have struggled to implement it fully. Too often, managers do not fully understand how to impact the metrics on the scorecard. And as time moves on, the scorecard can fail to keep up with changing realities, suggesting relationships between activity and outcome that no longer exist.

Numeracy?

“Numeracy” is the ability to reason with numbers. John Allen Paulos, Professor of Mathematics at Temple University, made this concept famous with his book Innumeracy, in which he bemoans how little skill our society has in dealing with mathematics, given how dependent upon it we have become. Organizations today struggle to maintain a workforce that has the skills to manage the data their operations generate. Once the data have been wrangled, the analytical reasoning skills required to make sense of that data are lacking.

Analytics provides powerful tools for dealing with massive quantities of data, and more importantly, for understanding how important relationships in our operating environment may be changing. But without a strongly numerate workforce, organizations cannot apply these techniques on their own and have a very limited ability to interpret the output of such techniques. A lack of good intuition and reasoning with numbers means that many warning signals go undetected.

What Drives Organizational Outcomes?

Organizations that want to prevent disasters and increase competitive advantage first need to define what constitutes critical information – in other words, what really matters to the organization. Prior assumptions have no place in that determination. Let’s say, for example, a company is proposing to increase its customer repeat rate by increasing satisfaction with its service. But does that relationship between customer repeat rate and satisfaction with the service really exist? And to what degree? Amazon.com, for example, does not simply assume that a person who buys a popular fiction book will want to see a list of other popular fiction books. Rather, it analyzes customer behavior. Thus, someone who is ordering Eat, Pray, Love might see an Italian cookbook, a Yoga DVD and a travel guide for Bali as recommendations because other people who bought that fiction book also bought those other items.

The steps to decide what matters are:

  1. Decide what the organization wants to accomplish.
  2. Identify the activities (customer behaviors and management techniques) that appear to produce that outcome.
  3. Test and retest those relationships, collecting data from operations to measure the link between activity and outcome.

Once an organization has identified what constitutes its key activities, how can it find the information it needs to monitor them?

Find the points in the value chain where the key actions have to occur to deliver the intended outcomes.

  1. Collect critical information at, or as close to, those points as possible. The closer an organization can get to the key points of value delivery, the more accurate the information it can collect.
  2. Continuously look for the most direct and unfiltered route to obtain the richest, most consistent information on each key point of the value chain.
  3. Keep testing each assumption by asking the question, “What surprising event could I see early enough to take corrective action?”

Stop Trying to Prove Yourself Right

Several traditional ways of doing business blind organizations to warning signs of potential disasters. First among these is looking for data that confirms that all is well. Although extremely counterintuitive, it is critical to look for evidence that things are not all right. Ask the question, “if something were going to cause failure, what would it be and how can it be measured?” If it can be measured, then it can be corrected early and failure can be avoided. Rather than indicating what has gone right in the past, these measures contain warnings of what could go wrong in the future.

To see the early warning signs, follow this process:

  1. Ask what assumptions are being made in the process of executing strategy to deliver value. For example, if the goal is to increase the efficiency of inspections, is there an assumption that inspectors will become more efficient while still adhering to the same high quality standards? Or, in a call center, is there an assumption that reps can decrease call handle time and still provide superior service?
  2. These assumptions are alert points where failure might occur. Don’t wait for the final outcome, but track, measure and monitor each assumption to make sure it is playing out successfully. This process is well known to project managers. They don’t just design Work Breakdown Structures and Critical Paths and then wait around for the end date to see if the project was successful. As soon as a task begins to exceed its scope, the impact is assessed all the way down the line.
  3. Keep testing each assumption by asking the question, “What surprising event could I see early enough to take corrective action?”

Organizations that do this well are not operating with a negative, doom-and-gloom perspective. Rather, they want their positive outcomes so badly that they look for data that might be telling them something is going wrong so they can correct it before it is too late. They are willing to “Fail Fast” and “Fail Forward,” keeping the failure small to ensure large successes.

People Power the Process

Creating knowledge from data to prevent disasters depends on both technology and human skill. Computers are powerful tools that can help collect, store, aggregate, summarize and process data, but the human brain is needed to analyze the data and turn it into actionable information. It’s this human factor where the biggest gap exists in most organizations. Finding people who can perform the required analysis is becoming increasingly difficult. A spreadsheet is just a pile of data until someone applies critical thinking, adding subjective experience and industry knowledge to derive insights into what the numbers really mean.

Organizations must invest in developing these skills in their workforce. Here’s how:

  1. Provide employees with the training, job assignment, education and mentoring opportunities needed to develop their analytical skills, industry expertise and decision-making acumen.
  2. Subject decision-making to evidence-based approaches, providing feedback to improve future decisions.
  3. Ensure employees have the tools they need to manage the volumes of data they are expected to digest and act upon.

Blame Is Not an Option

In his book The Fifth Discipline, Peter Senge said that a “learning organization” depends on a blame-free culture. In other words, when a problem arises, people need to refocus from laying blame or escaping blame and start fixing the problem.

In today’s data-rich world, preventing disasters large and small requires monitoring and filtering through the large volumes of information that stream into organizations every day to find early warning signs of imminent failure. Intellectually, just about everyone will agree that it makes sense to look for what could go wrong. Emotionally, however, it’s another matter. It is both counterintuitive and intimidating to ask managers to search out constantly how the organization is failing. Establishing a blame-free culture is the final frontier to create a new awareness and encourage people to test assumptions, make better use of analytics and communicate information without fear.


Charles Caldwell is Practice Lead, Analytics, with Management Concepts. Headquartered in Vienna, VA, and founded in 1973, Management Concepts is a global provider of training, consulting and publications in leadership and management development. For further information, visit www.managementconcepts.com or call 703 790-9595.

More Bad-Ass BA Techniques

Guidelines for Interviewing Candidate BAs

You have just been told by your manager that you will be interviewing a candidate for a mid-level business analyst position on your team. “We can’t hire full-time employees right now, but we can bring on contractors for this project. Make sure they have the skills we need, okay?” is the only direction you receive in the email other than the candidate’s resume.

Among us are few who have been taught how to conduct an interview, and I’m not talking about the “don’t ask these questions, ever!” memo from Human Resources. Just how do we determine whether a candidate, who has dressed properly for the interview, and seems like a nice person, could be a great contributor to our team?

I look for fundamental traits and indicators. Many people will use the term “soft skills” to describe these traits. I hate the term “soft skills” because it implies that the difficult skills are the domain-level technical skills, while the problem-solving and human interaction skills are “easy.” In my humble (ha!) opinion/experience, the problem-solving and human interaction skills and fundamental traits are the most difficult attributes to find in a candidate, and the most difficult to teach to an already hired employee.

Candidates are usually interviewed for their knowledge of a business domain, like, finance applications, or medical service auditing. There are plenty of people with the subject matter expertise who can interview a professional level candidate to determine if they have the right knowledge. Few people have been trained to interview a business analyst candidate for the critical thinking and communication skills that are indicators for success.

Here is my list of questions for a professional level candidate, an intern candidate (no previous professional experience) and a list of traits that I have found most successful BAs to possess. I hope this will be helpful for your next encounter with a candidate.

General Interview Guidelines for a BA

These suggestions are in no specific order.

  • Use the Dilbert cartoon: http://www.csus.edu/indiv/l/legorretal/160_Spring_2006_05_
    Dilbert_on_requirements_gathering.jpg

    Ask the candidate to explain why it is funny, and ask for an example of how they resolved a difficult requirements elicitation situation.
  • Ask the candidate to describe what information goes into a Business Case, and how does that information relate to a Requirements document.
  • Ask the candidate to explain the difference between the role of the BA and the role of the PM, and how they have managed when they had to play both roles on a project.
  • Ask the candidate how they go about obtaining success criteria for requirements, and for bonus points, how they determine what metrics to associate with those success criteria.
  • Ask the candidate to describe their group facilitation skills.
  • Ask the candidate to describe the difference between functional and non-functional requirements.
  • Ask the candidate to describe the difference between a requirement and specification.
  • Ask the candidate to describe the most interesting problem they ever built a model for, and what the model showed.
  • Ask the candidate if they are an “ask for forgiveness or wait for permission” type of person, and why.
  • Ask the candidate what they enjoy about being a business analyst.

Interview Questions for the BA Intern Position

People who interview for an intern position are not expected to have previous professional-level experience. Keep in mind that while you, the hiring group, are hoping for high-quality and low-cost labor, the candidate is evaluating you as a potential mentor.

  • Do you know what a business analyst is, and what a business analyst does?
  • How does being “in between” the business and technical world sound to you?
  • Do you write? Poems? Short stories? Keep a journal or a blog?
  • Tell me about a situation where you and some friends were trying to solve a problem. I’m looking for a situation in which some people wanted to go about dealing with the situation one way, and you or someone else had a different idea.
  • planning a team effort for a school project
  • planning a social gathering, party, sports event
  • Tell me about a project that you worked on that you enjoyed a lot. Would you give me the big picture first then tell me about one detail-level part of the project.
  • Is there a technical device that you really enjoy using? How would you describe that device, and what it is good for to, let’s say, your great uncle who won’t use an automated bank teller?
  • How do you feel about asking questions in a group situation? 
  • When you have been in a group, and people are arguing, how do you feel? Do you try to resolve the conflict? What if you are responsible for the group coming to an agreement?
  • Have you used flowcharts or process maps in your school work? How do you decide when to use words to describe something and when to use graphics/pictures?
  • In school you found yourself with multiple “priority one” tasks. How did you decide what to work on? How did you decide how to manage your time and energy?
  • Sometimes you have to make decisions in the absence of guidance. Are you more comfortable taking the initiative or do you prefer to wait until guidance is available? Tell me about a situation where you had to make that choice.
  • How would you describe your leadership style?
    • authoritarian
    • participative 
    • delegative
    • I don’t consider myself a leader

Traits of Successful Business Analysts

  • Has a strong interest in problem identification and problem resolution
  • Able to determine when solutions are being presented as problems, and can drill down to the underlying problem
  • Able to comprehend both big picture and detail-level information, and know when to work at which level
  • Able to abstract a big-picture from detailed information
  • Able to translate between business and technical ways of talking about something
  • Able to function with both fuzzy and crisp representations and know when to use which
  • Able to ask the dumb questions
  • Able to appreciate the need for process even when it will mean possibly missing a deadline
  • Able to mediate or temporize when serious conflict arises 
  • Able to remain collected and productive during conflict 
  • Able to generate alternative solutions for consideration to facilitate the decision making process, even if the analyst has a strongly preferred solution
  • Able to play the role of advocate for a weakly-represented group or alternative that needs more consideration
  • A high degree of honesty and integrity
  • Able to engender trust and confidence from all the various parties involved
  • Maintains a sense of detachment from the influence of power mongers
  • Sensitive to politics and power structures
  • Tolerant of ambiguous situations 
  • Respectful of each individual
  • Has a warped sense of humor
  • Predisposed to work collaboratively while still being able to work independently
  • Able to modify own leadership style so that it is appropriate for the project and the parties involved
  • Able to take initiative appropriately (do the right thing in the right situation), that is, decide whether to ask permission or to act and then seek forgiveness


Cecilie Hoffman

is a Senior Principal IT Business Analyst with the Business Analysis Center of Excellence, Symantec Corporation. Cecilie’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She writes a blog on her personal passion, motorcycle riding at http://www.balsamfir.com/motoblog/motojournal.html. She can be reached at [email protected].

Personal Identification: The Soft Skills PRECEDE the Hard Skills, for BAs

Doggone and dadblast it, what is going on! Didn’t I just say the opposite last month? How is your tolerance for ambiguity holding up? Are you on top of the BABOK 1.6 BA Fundamentals? If you are aspiring to the top of your profession, and have the courage to self-identify, dive right in!

I begin by quoting the entirety of BABOK Chapter 8 here (don’t panic, it fits in the blog):

Chapter 8: Underlying Fundamentals
8.1 Introduction

8.2 Basic Skills
8.2.1 Analysis Skills

.1 Structured Analysis Techniques
.2 Issue Management
.3 Communication Skills
.4 Learning Skills
.5 Usability

8.2.2 Business/Domain Knowledge
.1 Products
.2 Processes
.3 Markets
.4 Systems
.5 Sources of Knowledge

8.2.3 IT Knowledge
.1 Paradigms
.2 Methodologies

8.3 Advanced Skills
8.3.1 Meeting Management
8.3.2 Presentation Skills
8.3.3 Decision-making Skills
8.3.4 Facilitation Skills
8.3.5 Communication Skills
8.3.6 Conflict Resolution
8.3.7 Negotiation Skills
8.3.8 Relationship Skills
8.3.9 Questioning Skills
8.3.10 Systems Thinking
8.3.11 Escalation Skills
8.3.12 Logic
8.3.13 Cultural Awareness

8.4 Leadership Skills
8.4.1 Coaching Skills
8.4.2 Facilitating Long-term Goal Setting
8.4.3 Motivational skills
8.4.4 Appraisal Skills
8.4.5 Interviewing Skills
8.4.6 Role Definition
8.4.7 Behavioral Coaching
8.4.8 Delegation skills
8.4.9 Succession Planning
8.4.10 IT Architectural Skills

8.5 Peripheral Skills
8.5.1 Sales

8.6 References

Interestingly enough, it is only the Basic Skills that have any detail at all, and those not much. What does this mean? The Basic Skills are the things that we learn just by doing IT requirements work. So many BAs cut their teeth on IT, that this is “self-evident” to many of us. The KEY skill is that we LEARN.

Self-test number 1:
Did you love school, or at least did you love reading and learning? Can you see the relationship between a three-year IT project and a three-year PhD program? WHY is it important to involve stakeholders (bet you don’t know)?

Next are the Advanced Skills. These are the sorts of things that BAs learn when (typically) we have been in a job long enough to have institutional knowledge and process experience, plus enough maturity to get along. In effect we get “promoted” to working with more people. We may not be good at it at first, but we’re here because we know so much and can share it. This thrusts us beyond analysis of processes affecting teams, into the processes of team analysis. We can lead the team to meetings, but can we make them think?

Self-test number 2:
How balanced were your SAT scores? Are you as comfortable with words as you are with complex IT and financial concepts? Would you rather listen, except when it is vital to talk?

Then comes Leadership Skills. This is Advanced Skills on steroids, in the sense that NOW you can really make it work, not just oversee uninspired meetings and team sessions.

Self-test number 3:
Do people just fall all over themselves to be with you and get your approval and do what you say because you are just plain charismatic and, frankly, too sexy for your project? If not, have you held at least one sales job for more than two years? If not, try it and find out if you want to lead.

Yes, this is the punchline. Leadership IS influence, regardless of style, or outcome. Sales IS the profession of learning to influence, for good or for evil (both kinds of leaders are out there – which will YOU be?).

SO, as you look for “people skills”, don’t forget that a successful sale means a happy customer, whether the customer is a stakeholder, an executive, a system user, a boss, or an IT team member.

Happy customers are getting what they want – good systems; no one loves a salesman who sells a lemon. If you have happy customers, you are on your way to the top of the profession.

Here is the problem we have posed: BUT, loyal reader, I am out of time this month.

© 2008 Marcos Ferrer